2018-03-15 03:41 AM
I implemented an error handling after an ECC related NMI is called (double bit error). How can I test it?
Typical I overflash with corrupt data. But in case of the STM32L4 the hardware prevent it.
Do you know a diffent possibility to create this event for the test case?
Thank you
Steffen
#stm32l4-ecc-embeddedflash2018-03-15 06:40 AM
Hello Steffen,
I am not sure if you can anyhow simulate wrong data in Flash in order to test ECC. I had such request in past from one of STM32L4 customers. This customer was developing an application, which later on should be certified by TÃœV.
TÃœV
asked to show the real use case as a proof that ECC works in order to take this solution into account as one of safety featuers. At this time ST feedback was that it is probably not possible to trigger ECC by user in order to see step by step how it works.Regards
Szymon
2018-03-15 01:25 PM
Another, less drastic method may be to try to glitch the programming/erasure.
I'd try to do this using the mcu itself - start programming a FLASH word and simultaneously a timer which after a delay would output a pulse onto a pin, connected to an external circuitry which would cut the power (ground it hard) to the mcu.
JW
2018-03-15 02:09 PM
What about trying to bake the parts?
Szymon, as an ST insider, you could be able to get hands on the reliability data of the FLASH embedded in the 'L4, that should give an estimate of what temperature would be needed to achieve FLASH error within reasonable time. But I'd try at perhaps slightly below 300deg.C for a couple of hours for starter. Much better If you could run the part during the bake.
Of course there are more things which could go wrong at such temperatures, and methods have to be devised to distinguish this particular error from any potential others. That particular part is to be thrown away after the test of course.
Ionizing radiation may also be an option - any X-ray around?
JW
2018-03-15 02:16 PM
One solution could be to cycle a part of the Flash well above 10k until the ECC interrupt triggers.
2018-03-15 02:36 PM
The more important question is what is the response to an indication that the code space is not viable?
Spoofing a call to the routine itself shouldn't be hard to do, mapping the other interrupt priorities/preemption lower should emulate the nothing else running situation.
If the flash in the vector table isn't viable there will be situations where code is never called.
2018-03-15 02:55 PM
If the flash in the vector table isn't viable there will be situations where code is never called.
Very true.
In that case, the processor would go to lockup (as per ARMv7 ARM, B1.5.15 Unrecoverable exception cases). I presume an application where FLASH integrity is being put under doubt, some sort of watchdogs would be used too.
JW
2018-03-15 03:51 PM
Yep... and it's undoubtedly the least painful one... How could I be so stupid not
https://www.avrfreaks.net/forum/eeprom-endurance-and-pages?skey=endurance
this simple method...JW
2018-03-15 04:37 PM
And not at the end your eating from..
ie pick a small inconspicuous patch at the end in an unused area that's not going to totally compromise the usability of the part for additional tests.