2024-10-07 04:57 PM
Hi,
I am designing a system that will be using an STM32F411 microcontroller as the hardware application processor, the system will also have onboard a Single board computer module running Linux. While the application processor will take care of the majority of the hardware interface because of the realtime nature of the application, the SBC will be hosting the user interface, provide logging services, network access as well as management/supervisory functions, this is I think a fairly typical system for a real-time control architecture.
The SBC I am using is a plug in compute module, this is a read-made plug and play system that runs Linux, my application board provides the power and other ancillary interface hardware.
I am in the design phase, and I have a question about programming the STM32 micro. On the bench, and even on the board in the field I intend to have the four ping SWD interface the for common low cost STLink programmers. However, in production use I would like to be able to take over-the-wire firmware updates, so the obvious approach here is to have the SBC look for the updates, and when available and appropriate to do so, should be able to flash the firmware directly onto the STM32 microcontroller.
I would rather not design in another processer and embed and STLink (like the Nucleo boards do), so I am wondering what the simplest and best option would be to allow the SBC to flash the STM32. I understand that the STM32 has a boot loader built into the micro, and that I can force a reset and control the boot pins to put that boot loader into different modes.
I only have basic STM32 knowledge, so I am just looking for general block-diagram level guidance here. I have SPI, I2C, USB 2.0 and UARTS available from the SBC.
To keep it simple, my thinking is, I can connect the the SBC to the UART0 of the STM32 as well as some IO hookup for the STM32 reset and boot pins. I should then be able to restart the STM32 to put the boot loader into flash firmware mode on UART0. Also, when not being used to flash the STM32 I could use the UART interface as the inter-communication between the SBC and STM32, the UART will be more than fast enough for the inter-communications I need.
A second thought is, I could connect the USB interface on the SBC to the USB interface on the STM32, I understand its possible to make the boot loader use he onboard USB interface of the STM32? This would give me the advantage of having a much higher communications througput, but perhaps makes the software job more complicated.
Am I on the right track here? Is there something else/better I should be considering or doing. Appreciate any high-level guidance here.
Solved! Go to Solution.
2024-10-07 05:50 PM
You're on the right track. I'd avoid USB if you only need it for firmware update.
Use the built-in bootloader on UART pins supported by the bootloader per AN2606.
STM32 microcontroller system memory boot mode - Application note
Jump to bootloader code in software when needed. Example code here:
How to jump to system bootloader from application ... - STMicroelectronics Community
Use the UART protocol to flash the chip per AN3155.
USART protocol used in the STM32 bootloader - Application note
Since you need to erase the code before you can flash it, this can brick the chip if power is interrupted. To avoid that, you could temporarily program option bytes to always jump into the bootloader prior to flashing, and reset those option bytes after the flash is successful. That way, if power is lost, the chip will boot into the bootloader and you can still access it.
2024-10-07 05:50 PM
You're on the right track. I'd avoid USB if you only need it for firmware update.
Use the built-in bootloader on UART pins supported by the bootloader per AN2606.
STM32 microcontroller system memory boot mode - Application note
Jump to bootloader code in software when needed. Example code here:
How to jump to system bootloader from application ... - STMicroelectronics Community
Use the UART protocol to flash the chip per AN3155.
USART protocol used in the STM32 bootloader - Application note
Since you need to erase the code before you can flash it, this can brick the chip if power is interrupted. To avoid that, you could temporarily program option bytes to always jump into the bootloader prior to flashing, and reset those option bytes after the flash is successful. That way, if power is lost, the chip will boot into the bootloader and you can still access it.
2024-10-07 06:25 PM
Hey TDK, ok thank you, thats all I need, thank you very much for the links. I will have a read, but it looks like I will simply hook up to UART0 then, it sounds nice and easy as I hoped it would be :)
2024-10-07 07:45 PM
One other question, you mentioned "you could temporarily program option bytes to always jump into the boot loader prior to flashing, and reset those option bytes after the flash is successful" do you mean setting the boot0/boot1 pins before resetting the chip? Or did you mean there are configuration bytes I have to program after entering into the boot loader?
2024-10-07 08:07 PM
Oops, scratch that. On most chip families, there are option bytes you can set in flash so that the chip boots into the bootloader regardless of the BOOTx pin input. However, on the STM32F411, the only way to get into the bootloader is with pins BOOT0=1 and BOOT1=0 (per AN2606):
So if power cuts down midway through the flashing process, you'll need to connect to it with SWD in order to recover.
2024-10-08 08:23 AM
@TDK wrote:So if power cuts down midway through the flashing process, you'll need to connect to it with SWD in order to recover.
@gerrysweeney or, perhaps, have sufficient backup power in your system to be able to complete an update...?