2021-07-19 01:55 AM
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!
Solved! Go to Solution.
2021-07-20 03:08 AM
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
2021-07-20 03:08 AM
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
2021-07-28 07:43 AM
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.
2022-11-07 11:10 AM
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!
2022-11-07 11:53 AM
Try the boot loader protocol manuals, that'd be where I'd look..
2022-11-07 11:57 AM
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..