2

Bitflips/random hardware faults and row hammering are some of the things which could damage the memory. Do the current breed of latest microcontrollers, used in embedded systems, have any mechanism to detect these?

I’m not aware of how this is handled and can anyone provide some insights on this?

JRE
  • 67,678
  • 8
  • 104
  • 179
Rookie91
  • 2,108
  • 4
  • 29
  • 46
  • Yes, some of them do support error correction code (ECC) in their memories, to detect corruption. What kind of insight are you after? – Justme Sep 19 '20 at 18:47
  • @Justme , thank you for the input , I just want to know how it is caught(whether in the hw level or in the Sw level) in the safety critical systems, where these issues could lead to fatalities. – Rookie91 Sep 19 '20 at 18:51
  • The ECC would be handled at the hardware level just like if your PC had ECC memory installed, so that hardware knows that there are errors in memory, so the code execution stops to prevent executing invalid code, or to prevent executing code that might process invalid data. – Justme Sep 19 '20 at 19:26
  • There are a lot more problems with RAM out there... we used a RAM of a big, known manufacturer. A SW reading a few cells very often caused problems. The manufacturer called it misuse. That's because of internal layout and physical effects on adjacent cells... A automotive ECU I worked on some years ago used a runtime memory test... it cycled through memory and did a read/write pattern test. So every 15min the complete memory was tested. – schnedan Sep 19 '20 at 20:57
  • @schnedan runtime memory test seems like a good solution at software level, you have any suggestions for reading on that topic? Thank you for sharing your experience. – Rookie91 Sep 20 '20 at 04:44
  • @Justme thank you the insights, So far I was not aware of ECC peripheral in micro controllers, could you suggest some controllers who implement this feature in them? Or is it available in all micro controllers memory by default. – Rookie91 Sep 20 '20 at 04:51
  • @Rookie91 https://www.memtest86.com/tech_memory-test.html - that is, condensed, my knowlege. So I would choose writing patterns like 0x00 0x55 0xAA 0xFF plus a random value. no, not all µC have ECC. search for µC targeting industrial use and functional safety applications. e.g. infineon used to have ECC also in small devices,... they also suggested tests for their flash ROMs which are susceptible to errors more than RAMs. – schnedan Sep 20 '20 at 06:49
  • @schnedan "Walk patterns" are pretty awful to implement and highly MCU-specific too. Chances are big that they add far more dangers than they solve, due to the extra complexity and real-time scheduling issues. I wouldn't even consider it nowadays, since there's ECC. – Lundin Sep 23 '20 at 11:52
  • @Lundin ECC in most cases is only available with internal (SRAM )memory in small/midrange µC. " pretty awful to implement and highly MCU-specific too" - that's why skilled engineers do such stuff, right? – schnedan Sep 23 '20 at 11:58
  • @schnedan Both the NXP/ST and Renesas lines of safety MCUs are pretty much upper end. The MCP56 that I work with uses PowerPC cores and you can clock it at 133MHz. Not what I would call mid range. As for skilled engineers, they use the KISS principle, not the "if it ain't broken it ain't got enough features yet" principle :) – Lundin Sep 23 '20 at 12:09
  • Older automotive / industrial µC e.g. from Infineon used to offer ECC for flash only and Memory Tests are pretty simple... implemented ist myself 2 or 3 times already. Its not rocketsience. PS: It just happens in reality: sometimes other people select a µC you have to cope with. – schnedan Sep 23 '20 at 12:31

1 Answers1

1

Most MCU manufacturers have a line of "safety MCUs" nowadays, with built-in hardware ECC ("error correction code"). Not so much used for actual error correction, but to stop in a safe manner when RAM corruption happens.

The most prominent feature of "safety MCUs" is otherwise that they execute the code on two cores in "lock-step". There's various levels of more or less intricate error checking of hardware peripherals too.

One example is MPC56/SPC56 from NXP/ST. Similar safety MCUs should be available from Renesas, Infineon and others. Pretty much all modern cars use some flavour of safety MCU.

Lundin
  • 17,577
  • 1
  • 24
  • 67
  • thank you so much for the insights, so the purpose of the lockstep is mainly to check for deviations between main cpu and checker core right ? So will the lockstep take care of RAM issues or do the ECC peripheral would do it ? Or is it like I have ECC failure in main cpu and if there is no ECC failure in Checker core, then it’s been assessed that Ram error have occurred and we should initiate appropriate actions? – Rookie91 Sep 23 '20 at 11:46
  • @Rookie91 Both cores execute the program. If one of them goes crazy or if its clock starts to lag behind, you will be able to terminate the program/reset etc. Not to be confused with regular multi-cores or co-processors, where different cores perform different tasks. – Lundin Sep 23 '20 at 11:49
  • thank you for the swift insights, I had this doubt as my company does use Infineon like you have suggested as an eg of tricore but I do not have proper resources/access to understand how memory failure is taken up as I work on other domain. I have seen that it does have an ECC peripheral so lockstep feature would be like an additional safety layer for critical operations right ? And not necessarily only for memory issues and I trust it’s a part of redundancy in design. – Rookie91 Sep 23 '20 at 11:59
  • @Rookie91 How they handle failures would be application-specific. In most cases you'd just terminate the program as safely and gracefully as you can, then do a MCU reset. But in medtech or automotive, you'd try to keep running the best you can instead. – Lundin Sep 23 '20 at 12:07
  • thank you very much for the time and perspective :) – Rookie91 Sep 23 '20 at 12:12