J-Link Reset Strategies
Since there is no one way of resetting and halting a CPU core before it starts to execute instructions, J-Link/J-Trace supports different reset strategies. Reset strategies that use the reset pin, for example, cannot succeed on targets where the CPU's reset pin is not connected to the JTAG connector's pin. Reset strategy 0 is always the recommended strategy because it has been adapted to work on every target, even if the reset pin (pin 15) is not connected.
Is there a problem if the core executes instructions after a reset?
Instructions that are executed can cause various problems. Some cores can be completely "confused," which means that they can not be switched into debug mode (the CPU cannot be halted).
In other cases, the CPU may have already initialized some hardware components, which might cause unexpected interrupts or, worse, the hardware may have been initialized with illegal values. In some of these cases, such as where illegal PLL settings are involved, the CPU may be operating beyond specification, which could possibly lock it.
Strategies for Cortex-M devices
J-Link supports different specific reset strategies for Cortex-M cores. All of the following reset strategies are available via JTAG and in SWD as a target interface, and all of them halt the CPU after the reset.
It is recommended that the correct device be selected in the debugger, so that it can pass the device name to the J-Link software, which makes it possible for J-Link to detect the best reset strategy for the device.
Type 0: normal
This is the default strategy. It does whatever is implemented and is the best way to reset the target device. If the correct device is selected in the debugger, this reset strategy may also perform special actions that might be necessary for the connected device. This, for example, is the case for devices that have a ROM bootloader that needs to run after a reset and before the user application is started (especially if the debug interface is disabled after a reset and needs to be enabled by the ROM bootloader).
If no device-specific reset is implemented, then the reset is implemented as follows:
- The device should halt immediately after a reset (before it can execute any user-application instruction), which is ensured by setting the VC_CORERESET in the DEMCR.
- The core and the peripherals should be reset by setting the SYSRESETREQ bit in the AIRCR.
- The S_RESET_ST bit in the DHCSR should then first become high (reset active) and then low (reset no longer active) afterwards.
- VC_CORERESET should be cleared.
A J-Link script file showing this reset strategy can be found here.
Type 1: core
Only the core is reset via the VECTRESET bit. The peripherals are not affected. After setting the VECTRESET bit, J-Link waits for the S_RESET_ST bit in the Debug Halting Control and Status Register (DHCSR) to first become high and then low.
The CPU does not start execution of the program because J-Link sets the VC_CORERESET bit before a reset, which causes the CPU to halt before execution of the first instruction.
In most cases, it is not recommended to reset the core only, since most target applications rely on the status of some peripherals' reset state (PLL, external memory interface, etc.) and may be confused if they boot up and the peripherals are already configured.
Type 2: reset pin
J-Link pulls its reset pin low to reset the core and the peripherals. This normally causes the CPU reset pin of the target device to go low as well, resulting in a reset of both the CPU and peripherals.
This reset strategy will fail if the reset pin of the target device is not pulled low. The CPU does not start execution of the program, because J-Link sets the VC_CORERESET bit before the reset, which causes the CPU to halt before the execution of the first instruction.
Type 12: reset and halt following bootloader execution
This halts the MCU after the bootloader is executed. An instrumented startup code is required. Details are available here: Reset and Halt After Bootloader.
Strategies for Cortex-A devices
J-Link supports a default reset strategy for the Cortex-A cores. The following reset strategy is available via JTAG and in SWD as target interface. It halts the CPU after the reset.
It is recommended that the correct device is selected in the debugger so the debugger can pass the device name to the J-Link Software which makes it possible for J-Link to detect what is the best reset strategy for the device.
Type 0: normal
J-Link sets Vector Catch Enable in Vector Catch Register and DBGNOPWRDWN in Device Power Down and Reset Control Register. Afterwards, a reset is triggered via the reset pin with a (by default) 20 ms high phase. After the reset signal, J-Link allows a 100 ms delay to let the core boot.
Strategies for Cortex-R devices
J-Link supports a default reset strategy for the Cortex-R cores. The following reset strategy is available via JTAG and in SWD as target interface. It halts the CPU after the reset.
It is recommended that the correct device is selected in the debugger so the debugger can pass the device name to the J-Link Software which makes it possible for J-Link to detect what is the best reset strategy for the device.
Type 0: normal
J-Link sets Vector Catch Enable in Vector Catch Register and DBGNOPWRDWN in Device Power Down and Reset Control Register. Afterwards, a reset is triggered via the reset pin with a (by default) 20 ms high phase. After the reset signal, J-Link allows a 100 ms delay to let the core boot.
Strategies for ARMv8-A devices
J-Link supports different specific reset strategies for ARMv8-A based devices. All of the following reset strategies are available via JTAG and in SWD as target interface. All of them halt the CPU after the reset.
It is recommended that the correct device is selected in the debugger so the debugger can pass the device name to the J-Link Software which makes it possible for J-Link to detect what is the best reset strategy for the device.
Type 0: normal
This is the one and only reset strategy for ARMv8-A. A reset pin is mandatory. If the correct device is selected in the debugger, this reset strategy may also perform some special actions that might be necessary for the connected device. This, for example, is the case for devices that have a ROM bootloader that needs to run after a reset and before the user application is started (especially if the debug interface is disabled after a reset and needs to be enabled by the ROM bootloader).
If no device-specific reset is implemented, the reset is implemented as follows:
- The device should halt immediately after the reset (before it can execute any user application instructions), which is ensured by setting EDECR.RCE == 1.
- The core and peripherals should be reset by toggling the reset pin.
- The core should be powered if necessary.
- Debug mode should be enabled if necessary.
- The reset catch bit (EDECR.RCE == 0) should be cleared.
Strategies for ARMv8-R devices
J-Link supports different specific reset strategies for ARMv8-R based devices. All of the following reset strategies are available via JTAG and in SWD as target interface. All of them halt the CPU after the reset.
It is recommended that the correct device is selected in the debugger so the debugger can pass the device name to the J-Link Software which makes it possible for J-Link to detect what is the best reset strategy for the device.
Type 0: normal
This is the one and only reset strategy for ARMv8-R. A reset pin is mandatory. If the correct device is selected in the debugger, this reset strategy may also perform some special actions that might be necessary for the connected device. This, for example, is the case for devices that have a ROM bootloader that needs to run after a reset and before the user application is started (especially if the debug interface is disabled after a reset and needs to be enabled by the ROM bootloader).
If no device-specific reset is implemented, the reset is implemented as follows:
- The device should halt immediately after the reset (before it can execute any user application instructions), which is ensured by setting EDECR.RCE == 1.
- The core and peripherals should be reset by toggling the reset pin.
- The core should be powered if necessary.
- Debug mode should be enabled if necessary.
- The reset catch bit (EDECR.RCE == 0) should be cleared.
Strategies for ARM7/9
Strategies for ARM 7/9 devices
Type 0: hardware, halt after reset (normal)
The hardware reset pin is used to reset the CPU. After a reset-pin release, J-Link continuously tries to halt the CPU, which is typically halted shortly after the reset-pin release. In most systems, the CPU can execute some instructions before it is halted. The number of instructions executed depends primarily on JTAG speed: The higher the JTAG speed, the faster the CPU can be halted.
Some CPUs can actually be halted before executing an instruction, because the starting of the CPU is delayed after a reset-pin release. If a pause has been specified, J-Link waits for the specified time before trying to halt the CPU.
This can be useful if a bootloader residing in flash or ROM needs to be started after a reset. This reset strategy is typically used if nRESET and nTRST are coupled. If nRESET and nTRST are coupled, on either the board or the CPU itself, the reset clears the breakpoint, which means that after a reset the CPU cannot be stopped with the BP@0 reset strategy.
Type 1: hardware, halt with BP@0
The hardware reset pin is used to reset the CPU. Prior to resetting, the ICE breaker is programmed to halt program execution at address 0, meaning that, effectively, a breakpoint is set at address 0. If this strategy works, the CPU is halted before executing a single instruction.
This reset strategy does not work on all systems for two reasons:
- If nRESET and nTRST are coupled, either on the board or the CPU itself, a reset clears the breakpoint, which means the CPU is not stopped after the reset.
- Some MCUs contain a bootloader program (sometimes called kernel), which needs to be executed to enable JTAG access.
Type 2: software for Analog Devices ADuC7xxx MCUs
This reset strategy is a software strategy wherein a CPU is halted before performing a sequence that causes a peripheral reset.
The following sequence is executed:
- The CPU is halted.
- A software reset sequence is downloaded to RAM.
- A breakpoint is set at address 0.
- The software reset sequence is executed.
This sequence performs a reset of the CPU and peripherals and halts the CPU before executing instructions of the user's program. This reset sequence is recommended for Analog Devices ADuC7xxx MCUs and works with these chips only.
Type 3: no reset
No reset is performed at all.
Type 4: hardware halt with WP
The hardware reset pin is used to reset the CPU. After a reset-pin release, J-Link continuously tries to halt the CPU using a watchpoint. This typically halts the CPU shortly after a reset-pin release, and the CPU can, in most systems, execute some instructions before it is halted.
The number of instructions executed depends primarily on JTAG speed: The higher the JTAG speed, the faster the CPU can be halted. Some CPUs can actually be halted before executing any instruction, because CPU start-up is delayed after a reset-pin release.
Type 5: hardware halt with DBGRQ
The hardware reset pin is used to reset the CPU. After a reset-pin release, J-Link continuously tries to halt the CPU using the DBGRQ. This typically halts the CPU shortly after reset-pin release, and the CPU can, in most systems, execute some instructions before it is halted.
The number of instructions executed depends primarily on JTAG speed: The higher the JTAG speed, the faster the CPU can be halted. Some CPUs can actually be halted before executing any instructions, because CPU start-up is delayed after a reset-pin release.
Type 6: software
This reset strategy is a software reset only. A software reset means (basically) no reset, just a change in CPU registers, such as PC and CPSR.
This reset strategy sets the CPU registers to their post-reset values:
- PC = 0.
- CPSR = 0 x D3 (supervisor mode, ARM, IRQ / FIQ disabled).
- All SPSR registers = 0 x 10.
- All other registers (which are unpredictable after reset) are set to 0.
- The hardware reset pin is not affected.
Type 7: reserved
Reserved-type reset.
Type 8: software for Microchip AT91SAM7 MCUs
The device reset pin is disabled by default. This means that the reset strategies that rely on the reset pin (a low pulse on reset) do not work by default. For this reason, a special reset strategy is available and recommended.
The strategy resets the peripherals by writing to the RSTC_CR register. Resetting the peripherals puts all peripherals in the defined reset state. This includes the memory mapping register, which means that after a reset, flash is mapped to address 0. It is also possible to achieve the same effect by writing 0 x 4 to the RSTC_CR register located at address 0xfffffd00.
Type 9: hardware for NXP LPC MCUs
After a reset, a bootloader is mapped at address 0 on ARM 7 LPC devices. With this strategy, a reset is performed via reset strategy type 1, in order to reset the CPU. This also ensures that flash is mapped to address 0 by writing the MEMMAP register of the LPC. This is the recommended reset strategy for all ARM 7 LPC devices.
Strategies for devices with a RISC-V interface
J-Link supports different specific reset strategies for different cores with a RISC-V debug interface. All of the following reset strategies are available via JTAG and CJTAG, as well as in SWD as a target interface with debug specification 0.13.
Type 0: normal
This is the default strategy. It carries out whatever is employed as the "best way" to reset the target device.
If no device-specific reset is carried out, the reset is implemented as follows:
- The device should be halted.
- The core and peripherals are reset by setting the NDMRESET in the DMCONTROL.
- A minimum of 10 ms should elapse (adjustable by SetResetPulseLen).
- Bit NDMRESET is released in the DMCONTROL.
- A minimum of 100 ms should elapse.
- The user should wait until ALLHALTED is set in DMSTATUS.
Type 1: reset pin
J-Link pulls its reset pin low in order to reset the core and the peripherals.
This normally causes the CPU reset pin of the target device to go low as well, resulting in a reset of both the CPU and peripherals.
This reset strategy will fail if the target device's reset pin is not properly connected.
The sequence is as follows:
- The device should be halted.
- The core and peripherals are reset, pulling reset low.
- A minimum of 10 ms should elapse (adjustable by SetResetPulseLen).
- The core should be released from the reset by setting the reset pin high.
- A minimum of 100 ms should elapse.
- The user should wait until ALLHALTED in is set in DMSTATUS.
Device-specific reset
For many modern devices, generic reset strategies cannot be used since, for example, they have a ROM bootloader that (on reset) has to be executed prior to halting at the start of application code. Such devices require a device-specific reset. This is implemented through a ResetTarget() J-Link script file function.
If a custom ResetTarget() is implemented by the user, the script file function determines whether or not to honor the reset type selection (normal, reset pin, etc.). The script can request the currently selected type via the JLINK_ResetType variable within the ResetTarget() script file function.