STM32L476 - how can I create an ECC error to test my error handling

[Steffen Rose]

Posted on March 15, 2018 at 11:41

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-embeddedflash

[Szymon PANECKI]

Posted on March 15, 2018 at 14:40

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

[waclawek.jan]

Posted on March 15, 2018 at 21:25

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

[waclawek.jan]

Posted on March 15, 2018 at 21:09

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

[Bertrand DENIS]

Posted on March 15, 2018 at 22:16

One solution could be to cycle a part of the Flash well above 10k until the ECC interrupt triggers.

[Tesla DeLorean]

Posted on March 15, 2018 at 21:36

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.

[waclawek.jan]

Posted on March 15, 2018 at 21:55

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

[waclawek.jan]

Posted on March 15, 2018 at 22:51

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

[Tesla DeLorean]

Posted on March 15, 2018 at 23:37

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.