STM32 ROM bootloader, initial state and when erased

[sbend]

Hi,

On the STM32 F4 products, there is a hardware/ROM bootloader, that can be activated through the BOOT0 pin. It works great, no issues with that.

In a production environment, I would like to flash the board automatically, without manually pressing buttons on a board.

My question is related to the "initial condition" of an STM32 F4 MCU. I was hoping the bootloader would be activated on boot, if there is no application to run. E.g if the flash memory is erased and all FF's.

I tried doing a full chip erase and reset, but it does not enable the USB DFU options.
Is the default behavior, from the factory, that the ROM bootloader is active? Without activating the BOOT0 pin.

Any recommendations on how to flash an STM32 MCU in a fairly low volume production environment? Preferably, using the USB connection and not the SWD connectivity.

[Alex777]

see Figure 1

[sbend]

Thank you for the information! I might be reading it wrong, but it only describes the DFU bootloader, after it has been activated. My questions is more related to, the conditions that activates the bootloader. 

In the document you provided, there is a reference to an2606, that describes the activation patterns:

https://www.st.com/resource/en/application_note/an2606-stm32-microcontroller-system-memory-boot-mode-stmicroelectronics.pdf 

Table 2 has a lot of defined patterns for the bootloader and I see one of the conditions is "empty" flash. I assume this is the case for factory provided MCU's.

Figure 14 has more details about bootloader activation for the F4's

Activation is then dependent on BFB2(bit) and nBoot0_SW(bit) values. Do you/any know the initial factory state of those two bits?
I still cant figure out if a factory STM32 F4 enables the system bootloader, with USB DFU, on initial boot.

[TDK · Accepted solution]

> I still cant figure out if a factory STM32 F4 enables the system bootloader, with USB DFU, on initial boot.

It will not. You need to pull BOOT0 high.

The initial value of BFB2 and other option bytes are listed in the reference manual. The as-delivered state is BFB2=0.

AN2606 has a lot of information. Look only at what is relevant to your chip. There are a lot of STM32F4 models, you'll need to be more specific. Figure 14 is not relevant and only one section of Table 2 is relevant depending on your part number.

[sbend]

---

@TDK wrote:

> I still cant figure out if a factory STM32 F4 enables the system bootloader, with USB DFU, on initial boot.

It will not. You need to pull BOOT0 high.

---

Thank you - I think it answers my question.

The specific MCU is STM32F412VGT6, but I assume it has be behavior you stated.

It won't change anything, but I am curios what the rationale is for this. I would think if it does not have a program to run, it would make sense to go into boot mode; independent of the boot pin state. Other MCU's have this behavior at least.

[sbend]

Just checked the AN2606, it is pretty clear for the STM32F412xx. It does not check the internal memory for BL activation.

33.1 Bootloader configuration

The STM32F412xx bootloader is activated by applying Pattern 1

Pattern 1: Boot0(pin) = 1 and Boot1(pin) = 0

[TDK]

> It won't change anything, but I am curios what the rationale is for this.

I didn't design the chip, and unlikely the people who did will respond here, however:

Some newer STM32 series have this behavior via the "empty flash" check mechanism, but it seems ST has switched away from it. It has some drawbacks as the check is only performed at power up, not at reset, so after you upload code, the chip needs power cycled to boot from flash. This is a major drawback.

Since SWD is active during normal code operation (outside of low power states, excessive resetting, repurposing SWD pins), the bootloader isn't needed during development for the majority of cases. While it might help out your project, it's not globally optimal. SWD only takes 2 pins, it isn't a real burden to design a board with that programming method in mind.

Another major drawback is that boot mode configures pins in various states, which might cause unintended operation if you have this loaded on a board with peripherals connected to those pins, which is a fairly common scenario. Imagine the bootloader activating an internal pullup on a pin that starts a motor or some other critical operation. Having the chip crash but leave all its pins in default analog or input mode is often preferable.