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"¹, 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 models²); 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 pattern 6 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.