cancel
Showing results for 
Search instead for 
Did you mean: 

Bootloader: how to exit and jump to application in flash memory

FValm.1
Associate III

Hi! I'm searching a way to exit from the builtin bootloader after having successfully programmed my flash from USB. Is it possible to jump to my program in flash if I continue to hold the boot0 pin always high? I have done some attempts using STM32_Programmer_CLI.exe specifying the start address (option -s from command line) to my ResetHandler function which is in flash at address 0x8000970. It seems that this doesn't work and it needs to switch boot0 pin at a low level to make it works.

Just to explain my setup: I'm using the STM32_Programmer_CLI.exe program as following:

STM32_Programmer_CLI.exe -c port=USB1 -w myprog.bin 0x8000000 -s 0x8000970

Do you have any suggest? Thank you!

1 ACCEPTED SOLUTION

Accepted Solutions
FValm.1
Associate III

For all people facing the same problem. I finally understood what I was doing wrong!

First error was with the start address: it needs to specify the first location of the interrupt vector table. So the correct address was 0x8000000. Indeed the CLI add +4 to that address and read at that location to know the address where to jump.

Second problem was that my program in flash crashed quite immediately after starting. Indeed It needed to decomment in the system_stm32f4xx.c (I was playing with a nucleo-F411RE for the moment) the following define:

#define USER_VECT_TAB_ADDRESS

otherwise the pointer to the interrupt vector table (SCB->VTOR) keeps pointing to the bootloader interrupt vector table. So, at the first occurence of any interrupt, the program jumped to the bootloader area where the interrupt was not managed and entered an infinite loop

View solution in original post

5 REPLIES 5
FValm.1
Associate III

For all people facing the same problem. I finally understood what I was doing wrong!

First error was with the start address: it needs to specify the first location of the interrupt vector table. So the correct address was 0x8000000. Indeed the CLI add +4 to that address and read at that location to know the address where to jump.

Second problem was that my program in flash crashed quite immediately after starting. Indeed It needed to decomment in the system_stm32f4xx.c (I was playing with a nucleo-F411RE for the moment) the following define:

#define USER_VECT_TAB_ADDRESS

otherwise the pointer to the interrupt vector table (SCB->VTOR) keeps pointing to the bootloader interrupt vector table. So, at the first occurence of any interrupt, the program jumped to the bootloader area where the interrupt was not managed and entered an infinite loop

Amel NASRI
ST Employee

Thanks @FValm.1​ for sharing your experience!

-Amel

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

This needs to be boosted SO MUCH! I've been trying to switch between bootloader and application mode via CLI, and no where in any of the official reading material did I find any reference to this!

Try the boot loader protocol manuals, that'd be where I'd look..

0693W00000WHdtqQAD.jpg

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

The fact that ST uses a #define for something that should be a linker fixed up symbol, is truly lamentable, but this has been flagged to them for well over a decade, so I don't anticipate resolution anytime soon.

Or error / fault handlers as while(1) loops, technical support learn zero about product failures from blank screens and non-responsive devices. "Does not work" is very hard to diagnose..

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..