#156 Flashing chip for first time doesn't allow for a reset

[Joel]

We've got a very weird situation. During production, we're using stm32flash to write a hex file to a STM32L432. It works, using this command:

stm32flash -w firmware.hex -v -a 0x48 /dev/i2c-1 -R -i 10,-11,11,:-10 -g 0

This works, and our firmware runs. It also leaves the BOOT0 pin low, such that it shouldn't enter the bootloader.

However, if we pull the NRST line low and high again, the device re-enters bootloader mode. We've confirmed the value of BOOT0 on a scope, and it's definitely 0.

If we fully power cycle the board, the chip boots to our firmware with no problems. stm32flash behaves as expected, with a write taking effect immediately and a reset bringing it back up to our firmware (unless BOOT0 is high).

If the flash memory is completely erased, either using stm32flash or using an STLink debugger, and the board has a hard power cycle, this effect can be reproduced.

According to the STM32 documentation, the stm32 goes into bootloader mode if the main flash is empty, regardless of the value of the BOOT0 pin (see table 2 in AN2606). It's behaving as if the decision as to whether the flash is empty is being made at power-up, and not happening again even if the chip is being reset.

According to the accepted answer here, the option bytes need reloading to force the chip to reload this internal flash-empty flag.

[Tormod Volden]

It sounds like you are seeing exactly what is expected for STM32F070x6 and STM32F030xC devices, and the AN2606 section for your device says it follows pattern 6 in table 2, which involves "flash memory empty" so I guess it is the same behavior here. Have you tried setting OBL_LAUNCH before resetting?

[Tormod Volden]

If you look at dev_table.c the STM32F030xC has a F_OBLL flag set. You may try that flag on your own device. I don't know if the stm_obl_launch_code that gets run is valid for that device.

EDIT: Or the F_PEMPTY flag, apparently intended for STM32L45xxx/46xxx.