Difference between revisions of "Reset and Halt After Bootloader"

From SEGGER Wiki
Jump to: navigation, search
(1. Instrument the Startup Code)
(1. Instrument the Startup Code)
(One intermediate revision by the same user not shown)
(No difference)

Latest revision as of 07:59, 9 July 2021

Many MCUs have a so called boot ROM. This boot ROM contains the code which is executed after reset before jumping to the user application. The boot ROM has different tasks such as setting up clocks, enabling the debug interface, initializing the peripherals depending on the different boot sources, etc... Naturally, the boot ROM behavior is different from MCU to MCU because the requirements are specific to the used device. Indeed, it's not unusual that the boot ROM behavior has been changed between two silicon revisions of the same device.


The debug architecture does not specify how the boot ROM has to be designed / needs to behave thus it is not really possible to implement a generic reset method for such MCUs where the MCU is halted on the first instruction of the user application right after the boot ROM has been executed. Instead, such a device requires a so called device specific reset routine which can handle all possible device specific boot ROM scenarios such as no valid image, valid image in QSPI, boot via SD card, etc... Implementing such a device specific reset can be quite challenging up to impossible + be really time consuming because modern MCUs usually do not only have one boot path but a variety of boot paths. Furthermore, the boot ROM behavior is usually not documented by silicon vendors for certain reasons.


If the J-Link does not support reset + halt after bootloader for your device or for your boot source, a proper reset can be easily enabled by two steps:

1. Instrument the Startup Code

The following instructions needs to be added to the startup code:

// Perform a dummy read access from address 0x00000008 followed by two nop's
// This is needed to support the reset strategy: Reset and Halt After Bootloader.
// https://wiki.segger.com/Reset_and_Halt_After_Bootloader
mov r0, 8
ldr r0,[r0]

2. Change the Reset Strategy

The reset strategy needs to be set to strategy 12. How to change the reset strategy:


The following example project was created with the SEGGER Embedded Studio and runs out-of-the-box on SEGGERs Cortex-M Trace Reference Board. It is a simple blinky application which toggles LED0. It makes use of a generic startup code which has been instrumented as described above.

The project can be easily ported to any other Cortex-M based MCU.


Test & Verify functionality using J-Link Commander

  1. Download the application using Embedded Studio to the target
    JLinkCommander ResetHaltAfterBTL02.gif
  2. Connect to the target using J-Link Commander
  3. Perform a reset
  4. Check PC (== 0x0800010E)
    JLinkCommander ResetHaltAfterBTL00.gif
  5. Switch reset strategy to Reset + Halt After Bootloader
  6. Perform a reset
  7. Check PC (== 0x08000116)
    JLinkCommander ResetHaltAfterBTL01.gif

Conclusion / Summary

After performing the normal reset, the MCU is halted on the reset vector (Reset_Handler / 0x0800010E).
After performing a reset via reset + halt after bootloader strategy, the MCU is halted on the instrumented startup code (0x08000116)
This confirms that the reset behaves as expected.
In order to simulate a bootloader, the instrumented code may be moved from the startup code to somewhere in the user application. Performing a reset should show that the CPU is halted at the address where the instrumented code has been moved to.