STM32 gotchas
44.Some STM32 models after first programming don't run, and need power-on reset (AN2606 pattern6)

If a brand new STM32F091 is programmed with a program, which has already be proven to work, it is not enough to perform a software reset or even a NRST-"pushbutton" reset; a power-on reset is needed to run the application. What gives?

This is a surprising, but documented behaviour. STM32F091, when "pristine"1, upon startup detects empty FLASH and goes directly into bootloader. This may be a pleasant feature (as most other STM32 models require some physical action to enter the bootloader, usually pulling up the BOOT0 pin).

However, this is a somewhat more involved procedure, described in RM0091, Boot configuration/Empty check subchapter. The hardware does not check the whole FLASH: contrary, it checks only the first word in it (at address 0x0800'0000). If this word is 0xFFFF'FFFF, FLASH is considered empty, a flag is set (user-invisible or undocumented in 'F091, documented in some other models2); and if this flag is set, bootloader is subsequently entered.

Problem is, that this flag is not cleared with most sources of reset. As the "FLASH-empty" check is performed by hardware at the same moment when the FLASH option bytes are read, i.e. at power-on reset, this is what's required to clear the flag. It means, after programming, power has to be removed and then restored again, to run the application for the first time.

Alternatively, option bytes can be reloaded - thus the "FLASH-empty" check performed and flag cleared - by executing OBL_LAUNCH command (i.e. writing 1 into FLASH_CR.OBL_LAUNCH). There may be programming tools which can perform this through the debug (SWD) interface; I am not aware of them.

There are several STM models which "suffer" from this problem, but it's not easy to identify them. While they have pattern6 bootloader entry, as documened by AN2606, some - as e.g. the 'F042 - compensate for this problem in the bootloader itself, detecting "non-empty" FLASH and launching the application from software. For each suspected model, the respective RM has to be consulted for the minute details.

1. Or, it has been erased and power-on reset has been applied. Or, for whatever weird reason, it has the 0x0800'0000 word unprogrammed, i.e. equal to 0xFFFF'FFFF, at the moment of power-on.

2. For example, see FLASH_SR.PEMPTY in RM0394.