Difference between revisions of "Reset and Halt After Bootloader"

From SEGGER Wiki
Jump to: navigation, search
(Instrument the Startup Code)
(Solution)
Line 9: Line 9:
 
#Instrument the startup code of your application as described below
 
#Instrument the startup code of your application as described below
 
#Change the reset strategy to "Reset + Halter After Bootloader using watchpoint"
 
#Change the reset strategy to "Reset + Halter After Bootloader using watchpoint"
=== Instrument the Startup Code ===
+
=== 1. Instrument the Startup Code ===
 
The following instructions needs to be added to the startup code:
 
The following instructions needs to be added to the startup code:
 
<source lang="asm">
 
<source lang="asm">
Line 23: Line 23:
 
</source>
 
</source>
   
=== Change the Reset Strategy ===
+
=== 2. Change the Reset Strategy ===
 
The reset strategy needs to be set to strategy 12.
 
The reset strategy needs to be set to strategy 12.
   

Revision as of 16:02, 7 July 2021

Nowadays, most MCUs have a so called boot ROM which needs to be executed after reset before jumping to the user application. The boot ROM has different tasks such as setting up clocks, enable 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 boot ROM behavior may change between silicon revisions of the same device.

Problem

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 devices require so called device specific reset method which handles the device specific boot ROM behavior. 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.

Solution

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 of your application as described below
  2. Change the reset strategy to "Reset + Halter After Bootloader using watchpoint"

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 sequence.
# https://wiki.segger.com/Reset_and_Halt_After_Bootloader
#
mov r0, 8
ldr r0,[r0]
nop
nop

2. Change the Reset Strategy

The reset strategy needs to be set to strategy 12.

How to change the reset strategy is described here: https://wiki.segger.com/Changing_J-Link_Reset_Strategy

Example