How to jump to system bootloader from application code on STM32 microcontrollers

[B.Montanari]

Introduction

There are many possible ways to access the System Bootloader in STM32 devices and, in this tutorial, we will cover how to easily perform this jump directly from application code for all our families and product series, except for the STM32F0 and some STM32L0 that have an empty check mechanism in place.
To achieve this goal, we highly recommend following two main sources of documentation to ensure an easy and successful jump. Both the microcontroller’s Reference Manual and the Application Note AN2606 contain bootloader details, such as important addresses, supported peripherals and specific requirements to keep in mind when using the STM32 devices Custom or System Bootloader. In the app note it is possible to see the note explaining the effect of the empty check for the mentioned series:

This article will not cover the workaround of erasing the first page, but the code will have all STM32s addresses in it to facilitate the implementation, in case the reader wants to use it. We do suggest reading this article that explains how to execute code from SRAM.

I'd also like to appreciate the fantastic contribution from @Ahmet Yasin CİVAN in the post STM32H745XI: Software Jump to System Bootloader Without BOOT0/Option Bytes – Has Anyone Succeeded? , as this address a particular problem related to the STM32H745 series. 
Assuming you are using a series that allow you to make the jump from the application into system memory, we need to be aware of some important and necessary steps to be performed and some notes to keep in mind.

1. How to find System Memory / Bootloader Start Address value:

Refer to AN2606 “Configuration in System Memory Boot Mode” tables. Each device will have a specific System Memory/Bootloader address, and this value must be known to jump to bootloader correctly.
For example, for the STM32H723ZG microcontroller (a quick article showing the code for this series is available here), the Bootloader doesn’t start from the same address as the System Memory, but this is clearly defined in Table 111.

1.2. Disable, deinit and clear all peripherals your application has configured:

Including Clock Structure, Systick timer, ISR, Peripheral initializations and GPIO, every peripheral settings must be set to their default states to avoid interruptions when system is in boot mode. That’s why it is of the most importance to deinit all these functions and prevent an interruption to happen without a proper handler.

1.3. Re-enable Interrupts:

With the registers cleared, the interrupts can be re-enabled without compromising the application while in Bootloader.
 

1.4. Set the Bootloader Reset Handler address:

Bootloader Reset Handler address = Bootloader address + 4 bytes offset.

1.5. Set the Main Stack Pointer (MSP) to the values stored at the Bootloader stack.

1.6. Call a function pointing to the system bootloader to start execution.

Obs.: If your project uses watchdogs (IWDG and or WWDG), set the time base to the higher value possible to avoid a reset from it while in Boot Mode.

2. Development

Considering all the topics mentioned above, there is defined below a general code where you can simply set the MCU used in your application according to the list in the “enum” structure and the function is ready to be used in your project.
This code works by lighting one of the available User LEDs in the NUCLEO-H723ZG board, and then entering in system bootloader mode by calling the JumpToBootloader function.
Please be aware that all the different parts of code are specifically written between /*USER CODE BEGIN*/ regions so the code will not be erased when regenerating the project *.ioc file.
 

/* Private define ------------------------------------------------------------*/
/* USER CODE BEGIN PD */
/* Set the enumeration of the STM32 Microcontrollers Series*/
enum{C0, F030x8, F030xC, F03xx, F05, F07, F09, F10xx, F105, F107, F10XL, F2, F3, F4, F7, G0, G4, H503, H563, H573, H7x, H7A, H7B, L0, L1, L4, L5, WBA, WBX, WL, U5};

#define MCU			H7x		//Define here the MCU being used
/* USER CODE END PD */

/* USER CODE BEGIN PFP */
void JumpToBootloader(void);
/* USER CODE END PFP */

/* Infinite loop */
	/* USER CODE BEGIN WHILE */
	while (1)
	{
		HAL_GPIO_TogglePin(LED_GREEN_GPIO_Port, LED_GREEN_Pin);
		HAL_Delay(1000);

		JumpToBootloader();

		/* USER CODE END WHILE */
		/* USER CODE BEGIN 3 */
	}
	/* USER CODE END 3 */

/* USER CODE BEGIN 4 */

void JumpToBootloader (void)
{
uint32_t i=0;
void (*SysMemBootJump)(void);


/* Set a vector addressed with STM32 Microcontrollers names */
/* Each vector position contains an address to the boot loader entry point */

	volatile uint32_t BootAddr[33];

	BootAddr[C0] = 0x1FFF0000;
	BootAddr[F030x8] = 0x1FFFEC00;
	BootAddr[F030xC] = 0x1FFFD800;
	BootAddr[F03xx] = 0x1FFFEC00;
	BootAddr[F05] = 0x1FFFEC00;
	BootAddr[F07] = 0x1FFFC800;
	BootAddr[F09] = 0x1FFFD800;
	BootAddr[F10xx] = 0x1FFFF000;
	BootAddr[F105] = 0x1FFFB000;
	BootAddr[F107] = 0x1FFFB000;
	BootAddr[F10XL] = 0x1FFFE000;
	BootAddr[F2] = 0x1FFF0000;
	BootAddr[F3] = 0x1FFFD800;
	BootAddr[F4] = 0x1FFF0000;
	BootAddr[F7] = 0x1FF00000;
	BootAddr[G0] = 0x1FFF0000;
	BootAddr[G4] = 0x1FFF0000;
	BootAddr[H503] = 0x0BF87000;
	BootAddr[H563] = 0x0BF97000;
	BootAddr[H573] = 0x0BF97000;
	BootAddr[H7x] = 0x1FF09800;
	BootAddr[H7A] = 0x1FF0A800;
	BootAddr[H7B] = 0x1FF0A000;
	BootAddr[L0] = 0x1FF00000;
	BootAddr[L1] = 0x1FF00000;
	BootAddr[L4] = 0x1FFF0000;
	BootAddr[L5] = 0x0BF90000;
	BootAddr[WBA] = 0x0BF88000;
	BootAddr[WBX] = 0x1FFF0000;
	BootAddr[WL] = 0x1FFF0000;
	BootAddr[U5] = 0x0BF90000;

	/* Disable all interrupts */
	__disable_irq();

	/* Disable Systick timer */
	SysTick->CTRL = 0;

	/* Set the clock to the default state */
	HAL_RCC_DeInit();

	/* Clear Interrupt Enable Register & Interrupt Pending Register */
	for (i=0;i<5;i++)
	{
		NVIC->ICER[i]=0xFFFFFFFF;
		NVIC->ICPR[i]=0xFFFFFFFF;
	}

	/* Re-enable all interrupts */
	__enable_irq();

	/* Set up the jump to boot loader address + 4 */
	SysMemBootJump = (void (*)(void)) (*((uint32_t *) ((BootAddr[MCU] + 4))));

	/* Set the main stack pointer to the boot loader stack */
	__set_MSP(*(uint32_t *)BootAddr[MCU]);

	/* Call the function to jump to boot loader location */
	SysMemBootJump();

	/* Jump is done successfully */
	while (1)
	{
		/* Code should never reach this loop */
	}
}

/* USER CODE END 4 */

There are different useful ways to test if the code worked successfully, two of them are explained below.
 

2.1. STM32CubeIDE debugging tab.

You can check whether the PC is set to the Flash or Boot address in the debug tab on the top left corner of the debug perspective. At first, the PC starts in Flash address: 0x08000614 (for this particular demo).

After entering the Bootloader, the PC is now set to an address inside the Boot region: 0x1FF127BC. You can see the tab below after hitting “pause” button.

 

2.2. STM32CubeProgrammer Tool

Once within the Bootloader region, we can use the STM32CubeProg to guarantee that the system is working in system boot mode.
For this tutorial, we will use the USB entry point to perform this, but other interfaces available for the given series could be used as well. Just keep in mind that the USB has higher priority than the others, so if the cable is connected it will be the one selected. The AN2606 covers all of this peripherals and needed settings for all series.
Obs.: Please pay attention to the pins specified in the AN2606, because even if the STM32CubeIDE allows the pin reallocation, to enter in bootloader the pins must be the same as in the Application Note.
To execute this over USB, connect the USB cable on the User USB connector. After that:

- In the right corner, select USB instead of ST-LINK
- Refresh the Port to recognize the USB
- Hit “Connect”

After connecting,  search for the Bootloader start address and you will see something similar to the following image.

You have now successfully jumped to bootloader from the application. Well done!
Hope this article was helpful.
 

[MM..1]

Good point , but better is solve why jump to app dont work

STM32_Programmer_CLI -c port=USB1 -g

next i combine -d xxx.elf -v -g and this jumps to app ok

I mean 

STM32_Programmer_CLI -c port=USB1 -g 0x08000000

will never work. You need read vector and use direct address to app or only -g alone read it instead you. 

And use jump to reset func used dummy in compilation is cool workaround.

[pH61352]

Hello,
I'm working with STM32G0B1 device (starting development with Nucleo board). This device check empty user flash at boot time. If 0x08000000 is empty, it starts bootloader from system memory.
I found a solution that looks too easy to work but it realy works stable in my environment.
To start the bootloader from my application I just call:

HAL_FLASH_unlock();
HAL_FLASHEx_ForceFlashEmpty(FLASH_PROG_EMPTY);
HAL_NVIC_SystemReset();

After calling this 3 lines in my application code the STM32G0B1 restarts into bootloader and I can get DFU access over USB (I just used it with USB, but I assume UART, ... will also work).
I can use STM32CubeProgrammer (just tested the graphical interface) as well as the dfu-util application running on my Raspberry to flash my new application on the device. I also can restart my new application without providing a manual HW reset or power sequence. With STM32CubeProgrammer I just select "Run after programming" option or with dfu-util the "-s 0x08000000:leave" option.
Of course, this solution isn't failure tolerant, means if anything is fail during flashing the device cannot go back to bootloader mode automatically, but that's fine for me.

[lamare]

One of the disadvantages of jumping to the bootloader from the main loop is that at that point the hardware is already initialized and peripherals are already configured, so what I'm doing is set a flag in RAM on a place that's not erased with a system reset (system stack) and check that flag first thing after boot up in main().

So, in my main(), first thing I call is handleBootLoader();

In the situation I use these, there's multiple devices that are daisy chained, so the serial line goes from one device to the next. In order to program one of the devices, the other ones need to go into daisy chain relay mode and just pass through whatever data they receive. 

Works well in practice.

#include "stm32f4xx_hal.h"
#include "stdbool.h"
#include "protocol_processor.h"

#define BOOTLOADER_ADDRESS 		0x1FFF0000 // STM32F40xxx. See https://bit.ly/AN2606
#define BOOTLOADER_FLAG_OFFSET 	100			// 4 * 100 = 400 bytes below top of stack
#define BOOTLOADER_FLAG_MAGIC	0xFEEFFEEF
#define RELAYMODE_FLAG_MAGIC	0xEFFEEFFE

typedef void 		(*pFunction)(void);

static pFunction 	JumpToBootLoader;
static uint32_t 	JumpAddress;

extern int 			_estack;
static uint32_t* 	bootloader_flag = (uint32_t*) (&_estack - BOOTLOADER_FLAG_OFFSET);


void resetToBootLoader()
{
	*bootloader_flag = BOOTLOADER_FLAG_MAGIC;
	HAL_NVIC_SystemReset();
}


void resetToRelayMode()
{
	*bootloader_flag = RELAYMODE_FLAG_MAGIC;
	HAL_NVIC_SystemReset();
}


void handleBootLoader()
{
	if( *bootloader_flag == BOOTLOADER_FLAG_MAGIC )
	{
		*bootloader_flag = 0; // so next boot won't be affected

		/* Jump to system memory bootloader */
		JumpAddress = *(__IO uint32_t*) (BOOTLOADER_ADDRESS + 4);

		JumpToBootLoader = (pFunction) JumpAddress;
		JumpToBootLoader();
	}
	else if( *bootloader_flag == RELAYMODE_FLAG_MAGIC )
	{
		*bootloader_flag = 0; // so next boot won't be affected
		daisyChainRelayMode = true;
	}
	//*bootloader_flag = 0; -> don't mess if flag not set
}

 

 

 

[Ahmet Yasin CİVAN]

STM32H745XI ROM Bootloader Jump – Solving the Common UART Handshake Failure Issue

If you’ve been trying to perform a software-only jump to the ROM bootloader on the STM32H745XI (dual-core) – for example, to update firmware over UART – but kept running into a silent failure (no UART handshake or MCU lockup), this article is for you!

I faced exactly this problem, and after extensive debugging, I discovered that the key is to fully disable PLL2/PLL3 and carefully reset all peripherals and clocks in the correct order. In this write-up, you’ll find:

Key takeaways from the article:

• Why the classic “MSP/PC jump” method that works on STM32F4/F7 doesn’t work out of the box on STM32H745.

• Exactly which PLL and peripheral clock configurations break the bootloader’s UART handshake.

• Debugging and verification steps to pinpoint the issue.

• A complete, tested, and safe bootloader jump sequence that works reliably every time.

Read it here... 

https://community.st.com/t5/stm32-mcus-products/stm32h745xi-software-jump-to-system-bootloader-without-boot0/m-p/808797#M280209
Please check it out and share your feedback or testing results with us!