2
\$\begingroup\$

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?

\$\endgroup\$
11
  • \$\begingroup\$ Yes, some of them do support error correction code (ECC) in their memories, to detect corruption. What kind of insight are you after? \$\endgroup\$
    – Justme
    Sep 19 '20 at 18:47
  • \$\begingroup\$ @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. \$\endgroup\$
    – Rookie91
    Sep 19 '20 at 18:51
  • \$\begingroup\$ 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. \$\endgroup\$
    – Justme
    Sep 19 '20 at 19:26
  • \$\begingroup\$ 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. \$\endgroup\$
    – schnedan
    Sep 19 '20 at 20:57
  • \$\begingroup\$ @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. \$\endgroup\$
    – Rookie91
    Sep 20 '20 at 4:44
1
\$\begingroup\$

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.

\$\endgroup\$
5
  • \$\begingroup\$ 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? \$\endgroup\$
    – Rookie91
    Sep 23 '20 at 11:46
  • \$\begingroup\$ @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. \$\endgroup\$
    – Lundin
    Sep 23 '20 at 11:49
  • \$\begingroup\$ 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. \$\endgroup\$
    – Rookie91
    Sep 23 '20 at 11:59
  • \$\begingroup\$ @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. \$\endgroup\$
    – Lundin
    Sep 23 '20 at 12:07
  • \$\begingroup\$ thank you very much for the time and perspective :) \$\endgroup\$
    – Rookie91
    Sep 23 '20 at 12:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.