STM8L low power run mode

[taneli]

Posted on December 04, 2013 at 08:49

Hello.

We are developing a low power product that uses STM8L151 MCU. The product is in low power run mode when on idle stage and program is executed from RAM. I was wondering that how reliable is this functionality when device is powered on for years. We use IAR compiler that copies RAM function from flash to RAM only at startup. This worries me a bit... how big is the possibility of RAM corruption? We use IWD but Im not sure if that catches some RAM corruptions that does not affect to IWD refreshing.

[pierreandre]

Posted on December 05, 2013 at 11:00

Hello,

RAM corruption greatly depends on the environment, if there is no external perturbation, there is no risks of RAM problem.I have a product on the markets which store vital parameters on RAM and I check the RAM content each 16 minutes, if any problem is found the system blocks itself and come back to factory. We have 100% traceability and no products (many hundredth thousands devices over a decade) come back for RAM corruption problems, but it was on SAMSUNG and later MSP430 uC.On the others hand I've worked on a pico-satellite during my studies, an there are many RAM problem due to latch-up (and others things) when high energy particles hit the cells (such effects could happen due to ''terrestrial'' radiation) we selected COTS components so we know this was an issue, and designed the system to be reliable anyway.From my point of ''coding'' view, I'll store a simple CRC of the function in EEPROM and compare this one with the CRC calculated from function in RAM, and reload the code if any problem was found. You have to write your own methods to do this, but it is a very simple and a least safe way. But this could perhaps not be done in your system.Anyway, if you are sure the system is used in standard condition, like something designed to be weared by a human, and depending the application safety requirements, you simply could load the function with IAR sytem and let's go.The watchdog is only usefull if there is PC corruption, for example due to bitflip in stack or eeprom. As your program will run in RAM this is a sense to use it. But many engineers use it as ''debug'' function which is completely wrong from my point of view, as such small embedded firmware could be fully debugged. If there is any hand out possible problem, timeouts has to be used.If you have parameters in RAM which could break your system, you have to test them before executing the function.So in conclusion:- Use the watchdog to protect you main loop- Use CRC to be sure vital function are still OK- Check all the variables that are ''dangerous'' before executing themI'me clearly not an expert in safety execution, but this could be sufficient.