Longevity of microcontroller devices?

[srb1954]

Not if those mask programmed ROMs were made by Mostek.

These were used in some Tek and HP gear from the '70s and they suffered from data corruption over time. This was a common enough occurrence to be given a special description:  "ROM-rot"

I don't recall who made them but a couple years ago I fixed two different early 90s arcade games that had defective mask ROMs.

I didn't know about reliability issues with some manufacturers of mask ROMs.

Just to clarify: my comment regarding mask ROM, was about microcontrollers, with internal ROM, rather than discrete ROM ICs. I'm not aware of any issue with mask ROM microcontrollers, but it would be interesting to know if it's a common problem, with some brands/manufacturers.

The faulty Mostek ROMs probably pre-date the wide spread use of single chip microcontrollers. They were used with early microprocessor systems based on separate processor and memory chips.

I am not aware of any brands of microcontroller that have systemic ROM failure problems so I assume that manufacturing processes had improved by the time mask-programmed single chip microcontrollers became commonplace.

[james_s]

It's a small sample, but I built a handful of projects with flash based AT90S2313 microcontrollers starting a little over 20 years ago, many are still in service and none have ever failed.

[DaveC1964]

The concern is embedded devices that use MCU. Since I have no control over them it will just be what the creator made.  They are in things you don't even expect.

I mean, your favorite wooden chair might just snap one day. I think you might be placing an irrational amount of focus on microcontrollers specifically. Quite often the capacitors and mechanical parts get worn out and fail first

The wooden chair can be fixed, capacitors can be replaced.  Corrupted code in a device using a MCU? Nope, unless I have access to the original code and a way to program it.

[james_s]

The wooden chair can be fixed, capacitors can be replaced.  Corrupted code in a device using a MCU? Nope, unless I have access to the original code and a way to program it.

Depending on your woodworking skills, it can take considerable effort to fabricate a new piece, you can't always just glue it back together. A microcontroller does present challenges, but in most consumer devices it wouldn't be THAT hard to write some code that implements the same functionality. There are actually greater challenges than microcontrollers and firmware. For example things like horizontal output transistors in CRT monitors, they are special high current, high voltage BJTs that are not really used in anything modern so they are hard to get now. Germanium transistors and diodes are not made anymore and in many cases are not easily substituted with more modern parts. Displays are often customized to an application or use a specific interface that may not be made forever. Lots of specialized ICs go out of production with no direct replacement available. Speaking of displays, CRTs are no longer being made or rebuilt anywhere, so for applications that require them there is no direct replacement. It's just the price of progress, most modern devices are complex enough that they rely on parts that are not always possible to obtain forever.

Bottom line is nothing lasts forever, as technology progresses we sometimes lose the ability to do things we did in the past, because those things require on a whole support chain that no longer exists.

[SiliconWizard]

Yeah. As most of us have already said, the probability of internal flash memory of MCUs failing, as long as they are used in reasonable conditions, is certainly VERY low within "a few years", which seemed to be the OP's concern, and the probability of something else failing in the system is likely much higher.

That said, as james noted, nothing lasts forever indeed, and if you're considering designing something that should last for a very long time (at least several decades), you should obviously consider approaches that are very different from what you'd do for a device that is only meant to last for a couple years. That could include selecting parts that have a much longer MTBF, or implementing some form of redundancy. For code memory, that may imply storing the code in two or more areas in Flash (or some other NVM), check for integrity with some CRC for instance on a regular basis, and switch to the area that is still OK. That may be done with a single Flash chip (or internal Flash), or several separate ICs for even lower probability that all redundant areas are borked. Basic redundancy.

[james_s]

If you want something microcontroller based to last for many years and be repairable, code it in C and make the code available somewhere, then someone can easily repair it down the road, even if they need to use an entirely different microcontroller.

[Berni]

Yeah but nobody gives out the source code to there product. If anything they even lock the MCU to prevent reading the firmware back out of a known good chip.

But yeah it is a common ritual for people to pull ROMs and EPROMs out of old test equipment, arcade machines etc... and stick them into a programmer to read out the contents before they might potentially rot away. Often the original manufacturer is no longer is business or if they are they likely lost the ROM images. For example Nintendo was caught on these mini NES console for using pirated NES game images from the internet, because they still contained the header and metadata information that cartridge dumping tools and emulators use. They couldn't be bothered to dig up the original ROM files and go trough the trouble of reading them of the whatever ancient data storage medium they are kept on. (Also they likely just ripped off a existing emulator and those read these pirated ROM formats anyway)

But as others have pointed out, nothing works forever and MCU memory is a pretty rare failure. Especially since electronics tend to become obsolete every so often, so its unlikely for things to stay in operation for +30 years. Its not like MCU flash all just suddenly dies after 30 years, its just what the manufacturer guarantees, most of them will likely be going strong after +50 years still, at that point you are likely going to be dead yourself before the MCU dies, so its someone else's problem anyway.

[SilverSolder]

[...]  Nintendo was caught on these mini NES console for using pirated NES game images from the internet, because they still contained the header and metadata information that cartridge dumping tools and emulators use. [...]

That one made me chuckle...  the legitimate companies ripping off pirates?   

[SiliconWizard]

Yeah but nobody gives out the source code to there product.

Yes (unless the code is open-source of course). And that is understandable too. Now it all boils down to "repairability", and companies won't bother much (at least most of them) as long as there is neither market drive or some regulation.

Even though the idea is getting more popular, I do reckon that a large majority of consumers still don't care about repairability much - they'll favor the price tag, that is, the initial cost. So I guess, at least in the short to mid-term, it can only be enforced through regulations, and not from market drive. There is some attempt at regulating this in the EU, but at the moment, as I see it, it's more like a "cosmetic" directive than something really helping repairability in the end.

Solution though, once companies are working towards this goal, is pretty simple. If they use closed source, they just need to make firmware updates/replacements available with easy to use tools. It could use encryption so that reverse engineering would be made tough. Sorted. Now for the case the company goes out of business - then unfortunately it would definitely be a matter of regulation, and not individual will. If companies going bankrupt were forced to publicly release the source code/repair manuals/etc of their products, then it would solve the issue. The legal implications may be complex though.

[james_s]

Yeah but nobody gives out the source code to there product. If anything they even lock the MCU to prevent reading the firmware back out of a known good chip.

There's nothing stopping them from giving out the source though. If the goal was to design a long life and repairable product that would be a step that could be taken to do so. The fact that they choose not to is a separate issue.

[Scrts]

Yeah but nobody gives out the source code to there product. If anything they even lock the MCU to prevent reading the firmware back out of a known good chip.

There's nothing stopping them from giving out the source though. If the goal was to design a long life and repairable product that would be a step that could be taken to do so. The fact that they choose not to is a separate issue.

Sharing code works if you are enthusiast. It doesn't work if you're a business and want to stay a profitable business. Mostly because of China.

[james_s]

Sharing code works if you are enthusiast. It doesn't work if you're a business and want to stay a profitable business. Mostly because of China.

That makes no difference at all. A purely hardware device with no microcontroller is just as secure against copying as a microcontroller based device with shared code. Even if you don't share the code, in most cases someone can just design something that does the same thing if the function of the device is in any way novel. If your widget is worth copying, someone is going to copy it, period.

[SilverSolder]

I have worked in several companies, going through product development cycles with them.

They take the competition's stuff apart and try to learn from it, but nobody ever attempted a direct copy -  they wanted an improved design, not a copy.

[Berni]

[...]  Nintendo was caught on these mini NES console for using pirated NES game images from the internet, because they still contained the header and metadata information that cartridge dumping tools and emulators use. [...]

That one made me chuckle...  the legitimate companies ripping off pirates?   

Yeah, its particularly funny that of all the companies out there Nintendo was caught. They are easily the most copyright obsessed company in the whole gaming market. Not only do they constantly press legal action against emulator developers (since they always had a huge gripe against piracy), they even go after people uploading gameplay videos of there games on youtube. That's like if Tesla asked everyone who does a car review to give them a share of the video revenue because they created the car that they are using in the video.

I have worked in several companies, going through product development cycles with them.

They take the competition's stuff apart and try to learn from it, but nobody ever attempted a direct copy -  they wanted an improved design, not a copy.

Yes most proper companies indeed do that. In order to compete with the other companies product you have to be familiar with there product, if anything to compare its performance with yours.

But when it comes to most chinese companies they will want to make an exact copy. They will rip it apart, scan in the whole PCB, trace it out, make a copy and start producing it. They see a product sells well, so they go and make the same thing, but cheaper, so that people buy there copy instead. Sometimes the copy is actually genuinely good, other times its complete garbage that ruins the reputation of the original product. This is why you see rubbed off chip partnumbers in mostly Chinese products, they are trying to defend the design from being copied by the next guy.

Yes (unless the code is open-source of course). And that is understandable too. Now it all boils down to "repairability", and companies won't bother much (at least most of them) as long as there is neither market drive or some regulation.

Even though the idea is getting more popular, I do reckon that a large majority of consumers still don't care about repairability much - they'll favor the price tag, that is, the initial cost. So I guess, at least in the short to mid-term, it can only be enforced through regulations, and not from market drive. There is some attempt at regulating this in the EU, but at the moment, as I see it, it's more like a "cosmetic" directive than something really helping repairability in the end.

Solution though, once companies are working towards this goal, is pretty simple. If they use closed source, they just need to make firmware updates/replacements available with easy to use tools. It could use encryption so that reverse engineering would be made tough. Sorted. Now for the case the company goes out of business - then unfortunately it would definitely be a matter of regulation, and not individual will. If companies going bankrupt were forced to publicly release the source code/repair manuals/etc of their products, then it would solve the issue. The legal implications may be complex though.

Even people like Keysight that used to make some damn nice service manuals back in the HP days are not doing it anymore. Pretty much any piece of test gear they made up to the 1990s came with complete schematics of everything. These days all you get is a high level block diagram that turns out to not be all that useful and a troubleshooting flowchart that usually ends with "Replace board A3". Tho if you lost the contents of a ROM chip back then it was a problem since you could not get the ROM image anywhere, tho you could call up HP and ask them to sell you a new ROM chip with the data already in it. These days they likely won't sell parts this old anymore, so your best bet is finding a guy on the internet that dumped the ROM contents and still has the image file laying around (Had to do this before).

Then again todays test equipment is often a lot less repairable purely due to complexity. If you have a blown acquisition ASIC in your scope well you are screwed, not like you are going to go swapping that huge expensive unobtanium BGA chip even if you could just buy one for 50 bucks. Tho in my opinion there should still be schematics to help fix the more common simple power supply issues and similar. Also an image of flash chips, such as for the case of the X3000 scopes bricking themselves, im sure someone would gladly go trough the trouble of pulling the chip out, flashing it and putting it back in if that's what it takes to make a perfectly good scope work again.

[SilverSolder]

[...] there should still be schematics to help fix the more common simple power supply issues and similar. [...]

Exactly - hardly giving away IP by showing a power supply and distribution diagram, or how the boards are connected together, etc. -  I think there is an element of planned obsolescence here, i.e. they don't want people to be fixing them and keeping them alive for 50 years or more like we are doing with the best equipment from the past! 

[SilverSolder]

[...]
But when it comes to most chinese companies they will want to make an exact copy. They will rip it apart, scan in the whole PCB, trace it out, make a copy and start producing it. They see a product sells well, so they go and make the same thing, but cheaper, so that people buy there copy instead. Sometimes the copy is actually genuinely good, other times its complete garbage that ruins the reputation of the original product.
[...]

There comes a point when a copy is so bad that it becomes a scam (e.g. the NPN transistors re-labeled as JFETs that I purchased recently - LOL, why did they bother?).

On the other hand, a copy that is as good as (or even better than) the original...   I have mixed feelings about that.  We try to protect the investment in design and development by using patents, for example.  On the other hand, you can legitimately argue that many corporations play games with patents for trivial "inventions" so they are just blocking the mainstream adoption of new technologies.  I am thinking of tactics like patenting stuff just to prevent competitors from ever doing something, not because the corporation has any intention of actually using the patent themselves...