Skip to main content
PJosh.8
PJosh.8
Associate
March 28, 2019
Question

STM32F103 - Code flash getting erased automatically

  • March 28, 2019
  • 14 replies
  • 4185 views

Hi,

Our STM application is a smart bike IoT device, that let's a user track his / her vehicle.

Of our devices deployed in the field, some of them stopped functioning. On debugging we found that the entire STM flash was erased.

What could be the possible reason for the STM flash getting erased?

Additional info:

  1. We use the the STM internal flash for storing certain critical parameters, which are written to typically 10 times a day.
  2. Additionally we have a second MCU that is used for updating STM's firmware. We have placed extra checks here to ensure it does not accidentally bootload STM

What measures should we take to prevent such an erase?

Thanks in advance,

Prathamesh

This topic has been closed for replies.

14 replies

Show previous replies
S.Ma
S.Ma
Principal
March 29, 2019

Note: Some STM32 have an analog watchdog for such type of purpose (in case the watchdog is not enough). I think it's called WWD or something.

PJosh.8
PJosh.8Author
Associate
March 29, 2019

> Have you implemented the HW watchdog or ensure the Vdd is always within the operating range? 

I don't think so. Do you mean something similar to the brown out detection some processors provide?

> All these are learnt by customer field returns making a valuable QA test list over time which improves the ruggedness of the end product.

Yes! The 3 range Vdd input was very insightful. We will bear that in mind in future hardware revisions.

Meanwhile we are eliminating all runtime usage of STM code flash, and have pushed the update in a select few devices. We'll observe if the issue recurs.

CYap.1
CYap.1
Visitor II
November 22, 2021

Did you ever solve the issue through one of your changes or track down its root cause?

S.Ma
S.Ma
Principal
March 29, 2019

Watchdog requires specific SW implementation, basically you got a reset countdown (say 500msec) and the SW must reset this countdown in one place of the code. The problem is that if the core gets crazy, 500 msec is a lot of crazy executed code before the reset.

That is why there is also the analog watchdog which triggers if the MCU voltage drops too low.

Worst case would be if the flash erase occurs just when the supply is cut, is there enough juice in the decoupling caps to complete the erase/write? Did I implement a backup sector so that when writing or erase fails, there is a recovery in place?

Terms & ConditionsAccessibility statement