cancel
Showing results for 
Search instead for 
Did you mean: 

Rebooting into bootloader mode from software?

MFord.1
Associate III

Hi all, I am pretty new to STM32 development and pretty green to embedded systems in general.

The main goal I am trying to achieve is receiving firmware updates from a master controller over UART. I am using a STM32F091CC chip on my slave device and was planning on letting the master use the chips internal bootloader to accomplish this. Basically my plan is: receive an update command from master -> send an ACK response -> reboot myself into bootloader mode -> let master take control.

0693W000000VIrUQAW.png

I am aiming to use the 5th row configuration (which is supported by STM32F09 devices). This configuration seems to not care about the BOOT0 pin and can be setup entirely through software by setting the nBOOT1, nBOOT0, and BOOT_SEL pin.

My question is centered around how do I get the chip to recognize these changes and enter bootloader mode? There is a very good chance I missed this in the documentation, but I've been looking around and it seems somewhat vague.

I know it will take some type of reset to accomplish this. I need to use HAL_FLASH_OB_Launch() to load the new option bits anyways, and this causes a "system reset". Is this reset enough to recognize these changes and enter into bootloader mode? Do I need something more heavy duty like an actual power on reset? Does this approach even make sense at all?

If you could point me to the right documentation that would be awesome! Thanks!

5 REPLIES 5
TDK
Guru

Your approach makes sense. They should be recognized on system reset.

There is also an alternate way of jumping to the bootloader in your user code instead of messing around with option bytes. In my estimation, that is the more common approach.

If you feel a post has answered your question, please click "Accept as Solution".
MFord.1
Associate III

Thanks for your reply!

I did look into that alternative way too. Out of curiosity, is there really a pro/con of doing it a certain way? Obviously, the end goal is the same. It seems like if you are handling it through software regardless, it would be easier setting 3 bits and calling a reset than configuring the chip as if it is coming out of reset and jumping? I guess it doesn't really matter either way. Is there a "safer" option?

One advantage of not messing with option bits is that every time you reset, the chip boots user code. Up to you.
If you feel a post has answered your question, please click "Accept as Solution".
MFord.1
Associate III

Good point. One last question, if you went the non-option bits route, you would theoretically never have to reset/reboot right? You could just stay bouncing in between bootloader and user code indefinitely?

Yes, if you do it right.
Resetting peripherals using the __HAL_RCC_***_FORCE_RESET makes things easier.
If you feel a post has answered your question, please click "Accept as Solution".