Custom bootloader jump to app best practices

[Dave Jones]

Posted on April 14, 2018 at 00:17

I am writing a custom bootloader for the STM32L452. Before I jump to the application code from the bootloader I want to get the hardware to as close to a reset condition as possible to avoid any surprises.

My plan is to:

  call HAL_RCC_DeInit(); to turn off the PLL and set the clock to it's default state

  set SysTick->CTRL  = 0; to turn off the systick  call HAL_DeInit(); to disable all the peripherals (it looks like it does a force reset/release of APB1, APB2, AHB1, AHB2, and AHB3)

I'll then disable IRQs, set the stack pointer, and jump to the startup vector in the application. The application startup code should then take care of setting everything to it's initial state before it calls main().

Does this seem like I have covered everything? Nothing left that might leave a pending interrupt bit, or some other surprise?

[Tesla DeLorean]

There is a balance here.

No need to initialize clocks and PLL's twice, decide who does it, and perhaps test the current state before tearing down and rebuilding. Code provided is dumb, a little effort can make it smart/adaptive. Some of the code I have that can run on multiple STM32 reads DEV_ID and then sets PLL, AHB, APB and wait states optimally, ie F407 vs F411 vs F446 vs F401 on an F4-DISCO

Main thing of concern is interrupts, SysTick as you note is a big one, but you really don't want to hand off a mess to the application, and anything that might fire before the app's ram/statics have been properly initialized.

I would generally lean toward having an expedited path between loader Reset Handler and transfer to app's, basically checksum/validate and jump. Main loader code firing is it detects app is broken, or app has reset with a specific code to run loader or nuke itself, or jump to ROM DFU.