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.