STM32F103 - Code flash getting erased automatically

[PJosh.8]

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

[After Forever]

> What measures should we take to prevent such an erase?

Put the flash back into locked state after storing there data.

Also debug the code, find all the possible scenarios where your flash writing / erasing code can act erroneously or executed unintentionally.

[PJosh.8]

Hi,

We do lock the flash after storing. Here's a snippet.

	HAL_FLASH_Unlock();
	__HAL_FLASH_CLEAR_FLAG(FLASH_FLAG_EOP | FLASH_OBR_OPTERR | FLASH_FLAG_WRPERR | FLASH_FLAG_PGERR );
	FLASH_PageErase(address);
	CLEAR_BIT(FLASH->CR, FLASH_CR_PER);
	osDelay(10);
 ... 
	for(i =0; i<array_size; i++)
	{
		status = HAL_FLASH_Program(TYPEPROGRAM_WORD, address+4*i, data_array[i]);
		osDelay(10);
	}
	HAL_FLASH_Lock();

address and array_size are fixed (values are #defined in code)

[After Forever]

> osDelay

You are using an RTOS, are you making sure that other tasks aren't running while you are programming the flash?

[Tesla DeLorean]

Flashing needs a stable power supply.

Are you using EEPROM emulation, or other code that might be erasing/writing flash during regular operation?

Bounds check code to limit regions of FLASH that can be touch, especially during errant or early execution.

[PJosh.8]

> You are using an RTOS, are you making sure that other tasks aren't running while you are programming the flash?

No actually. I will try doing that. Encapsulating the snippet in between taskENTER_CRITICAL() and taskEXIT_CRITICAL() should ensure that right?

> Are you using EEPROM emulation, or other code that might be erasing/writing flash during regular operation?

No, we aren't using EEPROM emulation, but we do write to flash during regular operation although infrequently. The address and area we write to are fixed. Will try placing additional runtime checks on the flash write address.

Does the flash unlock command unlock the entire flash for write?

[Alex R]

DO you have any Over-The-Air (remote, wireless) firmware upgrade on your system?

[PJosh.8]

> DO you have any Over-The-Air (remote, wireless) firmware upgrade on your system?

Yes we do. Since we started encountering the flash erase issue, we have installed extra checks to ensure it does not accidentally go into firmware upgrade mode. All instances of flash erase occurred when the device was not (visibly) updating its firmware.

[Alex R]

Were the units that failed in the field working ok previously? For how long?

Are the units exposed to physical elements (rain, cold, snow, low temperatures)?

Is there any indication of any physical damage on the failed units (electric shorts, condensation, etc)?

[PJosh.8]

> Were the units that failed in the field working ok previously? For how long?

Yes they were working perfectly fine before that. For any time between 1 week to a month.

> Are the units exposed to physical elements (rain, cold, snow, low temperatures)?

No.

> Is there any indication of any physical damage on the failed units (electric shorts, condensation, etc)?

None at all. In fact, we re-flashed the STM in a couple of devices and they started working normally again.

[S.Ma]

Have you implemented the HW watchdog or ensure the Vdd is always within the operating range? The reset or power on/off reset implementation must ensure that the voltage of the MCU is in the operating range.

• Erase flash or other driving high current HW (lights, motor) may source more current causing voltage droops
• If the supply can transiently be removed could also cause a droop
• Someone using ESD gun on bike

In general case, Vdd has 3 ranges: very low voltage where the chip does not work

nominal voltage where the chip is guaranteed to work

Between the two, the chip is "unknown" and could be "drunk".

This is the reason why there is power on reset or power off reset (voltage droops) to take care off.

The reset pin is one way to let the chip run in valid conditions.

In other typical case, if someone use a chip on a CR2032 button battery and there is a too big surge of current, the serial resistor of the battery will make a big voltage drop which easily show this thing to take care.

In some cases, we fill the unused flash memory with op-code causing reset or exception in case the program counter derails.

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

Again, this is just an hypothesis scenario in present case, which is good to checklist in any design.