2025-09-30 5:44 PM - last edited on 2025-10-08 7:33 AM by Amel NASRI
Hello community
The upgrade process of my device should be handled by the ROM bootloader over UART1 and FDCAN1. Therefore i can unset nBoot0 from the application and reboot to ROM. (If the new app can boot it sets nBoot0)
The reset is triggerd by the HAL_FLASH_OB_Launch().
After this reset i can communicate with the rom bootloader only per UART. To use FDCAN communication a power reset is necessary.
Then it works perfectly fine (go cmd). Trying this i havent connected any UART to my board.
If resetted and once sucessfully queried per fdcan the uart option from STM32_Programmer_CLI.exe says "Error: Activating device: KO." So the protocol detection works after the power reset. (After the OB reset it chooses UART1)
On the NUCLEO board the first thing i get after debugging HAL_Init() is exactly one Frame error in HAL_UART_ErrorCallback() but PA10 is not connected.
I havent seen that behavior on my custom board and can only imagine that by the OB reset the uC sees a uart tx somehow. This vague assumption will be investigated.
Does a timeout exist if a protocol is choosen?
Im happy to receive hints about this and thinking about using a custom bootloader on flash...
(The bootloader version from can cmd(0x1) is 0x10, the get id cmd(0x2): 0x04 0x67)
2025-10-13 1:51 AM
Hello @mtellian
At startup, the STM32 bootloader samples all supported interfaces in a fixed order: FDCAN, USART, I2C, SPI, and USB. It locks onto the first protocol where valid activity is detected—such as a FDCAN frame or a USART sync byte—and disables all other interfaces for that session. If no valid activity is detected on FDCAN, the bootloader continues to check the next interfaces in sequence until one is activated, and the selected protocol remains active until the next reset.
Please see the diagram below:
2025-10-13 5:42 AM
Hello Saket_Om
Im aware of the selection process from AN2606.
Do you have any input how to debug this. My next step would be to use the https://github.com/STMicroelectronics/stm32-mw-openbl and flash LEDs depending on the selection state.
Is this exactly the same code like in ROM? Can i assume the ROM Bootloader version of the microcontroller is V1.0.0 according to the Get Version cmd?
I found this version history:
https://htmlpreview.github.io/?https://github.com/STMicroelectronics/stm32-mw-openbl/blob/main/Release_Notes.html
How can i obtain the souces of this V1.0.0?
2025-10-15 8:33 AM
Hello @mtellian
Could you provide the value of the program counter (PC) after executing HAL_FLASH_OB_Launch()?
@mtellian wrote:
the https://github.com/STMicroelectronics/stm32-mw-openbl and flash LEDs depending on the selection state.
Is this exactly the same code like in ROM? Can i assume the ROM Bootloader version of the microcontroller is V1.0.0 according to the Get Version cmd?
The open bootloader is different from the ROM bootloader; however, both bootloaders are compatible and use the same commands. Note that the source code for the ROM bootloader is not provided by ST.