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 models 2); 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 3; check your programming tool's manual for the details.
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.
According to this article, the full list of devices which have the "empty FLASH" check implemented is:
- STM32L4+
- STM32WB
- STM32G0
- STM32F04x
- STM32F09x
- STM32F070x6
- STM32F030xC
- STM32L011x/ STM32L021x
- STM32L41x/ STM32L42x
- STM32L43x/ STM32L44x
- STM32L45x/ STM32L46x
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.
2. For example, OpenOCD. Details are dependent on the particular STM32 family, for example, for 'L4, it's the stm32l4x option_load command.