Longevity of microcontroller devices?

[DaveC1964]

It seems many things these days uses micro controllers of some kind.  Everything from battery volt gauges, to flashlights, to blue tooth speakers.  From what I understand though they all use flash memory to store the program and flash memory is not a permanent solution and eventually the bits be subject to errors as they age and the electron charge dissipates on the floating gates.  Doesn't that mean that every device using a micro controller will become unusable with in a few years like a ticking time bomb, or is there some other technology in use?

[crossroad]

You can look in the datasheets, the vendors usually specify the lifetime/endurance of the flash. It's often a million or so cycles for over ten years. Additionally, TI makes MSP430s with FRAM which have memory that will last practically forever.

So, no, probably not. What will fail will be the other components like mechanical parts and capacitors before the micon gives, generally speaking

Also, there are techniques to mitigate data loss like error correction codes (quite an ingenious process of perfectly reconstructing corrupted data without storing three repetitive parities in most conditions) and memory conditioning (re writing the data periodically)

[ataradov]

Most MCUs guarantee 20 year retention over the whole temperature range. It would be way more under normal conditions.

If application writes the flash, then there are possible longevity issues, but hopefully application designers though of that.

I just looked up SAM D21. It guarantees > 100 years of retention on cells with < 100 write/erase cycles at 55 C ambient temperature.

[techman-001]

I have PIC mcu's in gear I installed 22 years ago. They have been running 8 hours a day, 7 days a week for that entire time and no failures other than mechanical (stepper motor bearings getting dust in them past the seals etc) and one was blown to bits by a direct lightning strike.

I think you can relax about flash memory losing its data under normal circumstances.

[woofy]

It is a legitimate concern for long life products. I have many thousands of boards running 24/7 and the earliest of those are over 25 years old.
Back then I used a PIC16C84 with a quoted data retention of >40 years. Later PICs seem to be going backwards with "min 20 years" retention. It all depends on the environment. For the SAME70 with 1k cycles on the clock its min 20 years at +85C, dropping to 10 years with 10k cycles. At 1k cycles and +105C its just 5.5 years.

[Gyro]

That might be something to do with the early PIC 16Cs being UVEPROM based (even if they were plastic packaged OTP), whereas the later parts use Flash memory.

[woofy]

PIC16C84's were Microchips first EEPROM based chips. They were the only C version chip to be electrically erased and reprogrammed. All later chips were F types such as the 16F83 and 16F84 which replaced the 16C84.
Prior UV and OTP C devices were different technology.

[Zero999]

Some high volume products still use mask programmed devices, which essentially have infinite program retention life.

[amyk]

There are quite a few threads in the repair forum where old nonvolatile memory has corrupted itself somehow... so I wouldn't say it can't happen, but it's relatively rare.

[srb1954]

Some high volume products still use mask programmed devices, which essentially have infinite program retention life.

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"

[Ice-Tea]

If application writes the flash, then there are possible longevity issues, but hopefully application designers though of that.

Any SW programmer worth his salt should. Off course, the Tesla lot didn't seem to have gotten the memo 

[Bassman59]

If application writes the flash, then there are possible longevity issues, but hopefully application designers though of that.

Any SW programmer worth his salt should. Off course, the Tesla lot didn't seem to have gotten the memo 

They were too busy moving fast and breaking things.

[David Hess]

At least up until recently, NOR Flash could be treated as EPROM or EEPROM as far as retention and essentially ignored.  The need for NOR Flash also prevents microcontrollers from being built on processes with the smallest feature sizes.  I think they only recently achieved 28 nanometers but were previously limited to 45 nanometers?

What is a real danger is designs going back at least 10 years which rely on NAND Flash for storage of state or even code.  (1) I have run across a few of these now where the device just quit, but of course well after the warranty expired.  They might as well be designed with a self destruct.

(1) Tesla provides a current example of this.

[SiliconWizard]

As said above, refer to datasheets, most of which are pretty conservative regarding Flash data retention. Although Flash memory has certainly a limited retention, I've personally never witnessed data loss in devices up to 25 years old.

20 years minimum is common from manufacturers' specs. That's never going to be failures "within a few years", unless you constantly WRITE to it. So that being said, if you're using part of the internal Flash of some MCU as NV memory that you often write to (to replace EEPROM for instance), then of course you'll shorten the MTBF.

Now if you want long-term retention (several decades), do not constantly write to Flash... and use mask ROM if you want really long-term.

For devices using Flash memory as code memory that is read only for most of its lifetime, the probability of something else failing first is pretty high IME (such as power supplies, dried capacitors, solder cracks, overheating, etc.)

[Berni]

The flash used in MCUs is better low density stuff, not the high density TLC and QLC garbage that is used in modern SSDs. The logic optimised fab process on them is not capable of the high density that dedicated flash proceses can do. For this reson some MCUs are now moving to external non volatile storage chips, usually QSPI.

As people said they last plenty long as long flash is not being constantly written to. But i suppose you could make an app read and write back blocks of flash at random long intervals to freshen up cells and do ECC checks. One needs to handle power loss in that case tho

[nctnico]

Some high volume products still use mask programmed devices, which essentially have infinite program retention life.

Very likely these are standard EPROMS without the (expensive) lid.

[DaveC1964]

The flash used in MCUs is better low density stuff, not the high density TLC and QLC garbage that is used in modern SSDs. The logic optimised fab process on them is not capable of the high density that dedicated flash proceses can do. For this reson some MCUs are now moving to external non volatile storage chips, usually QSPI.

As people said they last plenty long as long flash is not being constantly written to. But i suppose you could make an app read and write back blocks of flash at random long intervals to freshen up cells and do ECC checks. One needs to handle power loss in that case tho

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.  These devices will just quit one day.  I am not even referring to write cycles, just the tendency of flash to degrade over time just by sitting.  People love using MCU because they are cheap and versatile but I wonder how many will still be working in 5 or 10 years.

[SilverSolder]

[...] I wonder how many will still be working in 5 or 10 years.

As others have said, the answer is:  "The vast majority of them"

[crossroad]

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

[Zero999]

Some high volume products still use mask programmed devices, which essentially have infinite program retention life.

Very likely these are standard EPROMS without the (expensive) lid.

Mask ROM isn't as common as it used to be but devices still exist and are used in applications such as calculators and watches which are made in huge numbers. You'll find more of it in older equipment though.

[bd139]

Only major risk in a 20 year window on MCU failure is thermal cycling and poor software destroying by the NVRAM in the device by writing too heavily. That has between 10k and 1M writes depending on which device. So if you have something which writes the same cell every second it’s not going to last the day.

I tried this with a 16F84 years ago when they first came out and it lasted about two weeks which was way above the specification.

[tmadness]

What about GPIO?
I would imagine electron migration and other phenomenon would cause increased degradation if the pin was pushing high current. eg a gpio terminated directly to a BJT, LED etc
I remember seeing a few failures at the 10 year mark where MCU GPIO had failed on pins that were connected to BJT pulldowns.

[ataradov]

That is no different than any other chip. If you don't stress the device beyond maximum ratings, you really should not worry about it. If pins that are not loaded beyond their ratings fail, something else is going on.

[james_s]

Some high volume products still use mask programmed devices, which essentially have infinite program retention life.

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.

[Zero999]

Some high volume products still use mask programmed devices, which essentially have infinite program retention life.

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.

[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...