STM32F105 Spontaneously Erased

[Stephen28]

Posted on June 02, 2012 at 01:27

I have not received back two units with an STM32F105 that appears to have been erased in the field.  The units are sealed, and show now signs of tampering.  When received there is no response.  When we connect the JTAG and re-program the STM32 the system works perfectly.  Has anyone seen this, and how do I prevent if from happening?

Thanks

[frankmeyer9]

Posted on June 03, 2012 at 11:16

I can't speak of field experience with stm32 controllers in this regard, but several other devices.

Do you use IAP, i.e. erasing/storing flash blocks at runtime ? If so, I would carefully scrutinize the involved algorithms. If not, I would read out the whole flash content, and check if there is something suspicious. Is is the same you programmed in ? It might also be a hardware problem, were the boot pins become floating under some circumstances. When the uC starts the bootloader instead of your app, this also provokes the usual customer claim ''device not working''.

[Tesla DeLorean]

Posted on June 03, 2012 at 14:20

That would certainly echo my thoughts.

Pulling BOOTx pins to desired levels to assure the right code executes. Do you have any code that unlocks the flash array? If you have read back the failed device check that all locations are at 0xFF, or if you have some bit/byte/page level failures. On products from other vendors I have observed flash failure when the array is accessed during power up and the supply has not fully stabilized, and the POR delay/thresholding isn't adequate. ie things on the core start functioning a little over 1.2 or 1.8V, but you really want it to have hit ~3V. Issue with slow supply rise times, cheesy RC circuits on the -RESET lines.

[Stephen28]

Posted on June 05, 2012 at 02:47

Thanks fm and clive1, I check the contents of the flash on the next device that come back from a customer.