Difference between revisions of "J-Link Reset Strategies"

From SEGGER Wiki
Jump to: navigation, search
(Strategies for Cortex-M devices)
(26 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
__TOC__
 
__TOC__
  +
  +
<!--- %check if this chapter is up-to-date -->
  +
J-Link / J-Trace supports different reset strategies.
  +
This is necessary because there is no single way of resetting and halting a CPU core before it starts to execute instructions.
  +
For example reset strategies which use the reset pin can not succeed on targets where the reset pin of the CPU is not connected to the reset pin of the JTAG connector.
  +
Reset strategy 0 is always the recommended one because it has been adapted to work on every target even if the reset pin (Pin 15) is not connected.
  +
  +
'''What is the problem if the core executes instructions after RESET?'''<br>
  +
The instructions which are executed can cause various problems.
  +
Some cores can be completely "confused", which means they can not be switched into debug mode (CPU can not be halted).
  +
In other cases, the CPU may already have initialized some hardware components, causing unexpected interrupts or worse, the hardware may have been initialized with illegal values.
  +
In some of these cases, such as illegal PLL settings, the CPU may be operated beyond specification, possibly locking the CPU.
   
 
==Strategies for Cortex-M devices==
 
==Strategies for Cortex-M devices==
Line 6: Line 18:
 
All of them halt the CPU after the reset.
 
All of them halt the CPU after the reset.
   
'''Note:''' 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.
+
{{Note|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.<br>
Moreover, we recommend that the debugger uses reset type 0 to allow J-Link to dynamically select what reset is the best for the connected device.
+
Moreover, we recommend that the debugger uses reset type 0 to allow J-Link to dynamically select what reset is the best for the connected device.}}
   
 
=== Type 0: Normal ===
 
=== Type 0: Normal ===
Line 19: Line 31:
 
# Wait for the S_RESET_ST bit in the DHCSR to first become high (reset active) and then low (reset no longer active) afterwards.
 
# Wait for the S_RESET_ST bit in the DHCSR to first become high (reset active) and then low (reset no longer active) afterwards.
 
# Clear VC_CORERESET.
 
# Clear VC_CORERESET.
  +
A J-Link script file showing this reset strategy can be found [[J-Link_script_files#Reset_sequences | here]].
   
 
=== Type 1: Core ===
 
=== Type 1: Core ===
Line 24: Line 37:
 
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 afterwards.
 
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 afterwards.
 
The CPU does not start execution of the program because J-Link sets the VC_CORERESET bit before reset, which causes the CPU to halt before execution of the first instruction.
 
The CPU does not start execution of the program because J-Link sets the VC_CORERESET bit before reset, which causes the CPU to halt before execution of the first instruction.
  +
{{Note|In most cases it is not recommended to reset the core only since most target applications rely of the reset state of some peripherals (PLL, External memory interface etc.) and may be confused if they boot up but the peripherals are already configured.}}
 
'''Note:''' In most cases it is not recommended to reset the core only since most target applications rely of the reset state of some peripherals (PLL, External memory interface etc.) and may be confused if they boot up but the peripherals are already configured.
 
   
 
=== Type 2: ResetPin ===
 
=== Type 2: ResetPin ===
Line 34: Line 46:
 
The CPU does not start execution of the program because J-Link sets the VC_CORERESET bit before reset, which causes the CPU to halt before execution of the first instruction.
 
The CPU does not start execution of the program because J-Link sets the VC_CORERESET bit before reset, which causes the CPU to halt before execution of the first instruction.
   
  +
==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.
  +
  +
{{Note|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.<br>
  +
Moreover, we recommend that the debugger uses reset type 0 to allow J-Link to dynamically select what reset is the best for the connected 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 reset is triggered via reset pin with a (by default) 20ms high phase. After the reset signal J-Link waits 100ms delay to let the core boot.
  +
  +
==Strategies for ARMv8-AR devices==
  +
J-Link supports different specific reset strategies for ARMv8-AR 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.
  +
  +
{{Note|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.<br>
  +
Moreover, we recommend that the debugger uses reset type 0 to allow J-Link to dynamically select what reset is the best for the connected device.}}
  +
  +
=== Type 0: Normal ===
  +
This is the one and only reset strategy for ARMv8-AR. A reset pin is mandatory.
  +
If the correct device is selected in the debugger this reset strategy may also perform some special handling which might be necessary for the connected device.
  +
This for example is the case for devices which have a ROM bootloader that needs to run after reset and before the user application is started (especially if the debug interface is disabled after reset and needs to be enabled by the ROM bootloader).
  +
If no device specific reset is implemented, this reset is implemented as follows:
  +
# Make sure that the device halts immediately after reset (before it can execute any instruction of the user application) by setting EDECR.RCE == 1
  +
# Reset the core and peripherals by toggling the reset pin
  +
# Power core if necessary
  +
# Enable debug mode if necessary
  +
# Clear the reset catch bit (EDECR.RCE == 0)
  +
  +
==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 reset release, J-Link continuously tries to halt the CPU.
  +
This typically halts the CPU shortly after reset release; the CPU can in most systems execute some instructions before it is halted.
  +
The number of instructions executed depends primarily on the 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 the start of the CPU is delayed after reset 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 which resides in flash or ROM needs to be started after reset.
  +
This reset strategy is typically used if nRESET and nTRST are coupled.
  +
If nRESET and nTRST are coupled, either on the board or the CPU itself, reset clears the breakpoint, which means that the CPU can not be stopped after reset with the BP@0 reset strategy.
  +
  +
===== Type 1: Hardware, halt with BP@0 =====
  +
The hardware reset pin is used to reset the CPU.
  +
Before doing so, the ICE breaker is programmed to halt program execution at address 0; effectively, a breakpoint is set at address 0.
  +
If this strategy works, the CPU is actually 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, reset clears the breakpoint, which means the CPU is not stopped after reset.
  +
<!--- % debug access? "kernel"? --->
  +
*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.
  +
The CPU is halted and performs a sequence which causes a peripheral reset.
  +
The following sequence is executed:
  +
* The CPU is halted.
  +
* A software reset sequence is downloaded to RAM.
  +
* A breakpoint at address 0 is set.
  +
* The software reset sequence is executed.
  +
This sequence performs a reset of CPU and peripherals and halts the CPU before executing instructions of the user program.
  +
It is the recommended reset sequence 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 reset release, J-Link continuously tries to halt the CPU using a watchpoint.
  +
This typically halts the CPU shortly after reset release; the CPU can in most systems execute some instructions before it is halted.
  +
The number of instructions executed depends primarily on the 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 the start of the CPU is delayed after reset release.
  +
  +
===== Type 5: Hardware, halt with DBGRQ =====
  +
The hardware RESET pin is used to reset the CPU.
  +
After reset release, J-Link continuously tries to halt the CPU using the DBGRQ.
  +
This typically halts the CPU shortly after reset release; the CPU can in most systems execute some instructions before it is halted.
  +
The number of instructions executed depends primarily on the 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 the start of the CPU is delayed after reset release.
   
  +
===== Type 6: Software =====
  +
This reset strategy is only a software reset.
  +
"Software reset" means basically no reset, just changing the CPU registers such as PC and CPSR.
  +
This reset strategy sets the CPU registers to their after-Reset values:
   
  +
* PC = 0
  +
* CPSR = 0xD3 (Supervisor mode, ARM, IRQ / FIQ disabled)
  +
* All SPSR registers = 0x10
  +
* All other registers (which are unpredictable after reset) are set to 0.
  +
* The hardware RESET pin is not affected.
   
  +
===== Type 7: Reserved =====
The behavior of the J-Link can be customized via command strings passed to the JLinkARM.dll which controls J-Link. In some IDEs and applications such as the J-Link Commander, command strings can be directly passed via a native command. If this is not supported, there are some alternative options which can be used to use J-Link Command Strings anyhow. For further information regarding this, please refer to [[Using J-Link Command Strings#Generic]].
 
  +
Reserved reset type.
   
  +
===== Type 8: Software, for ATMEL AT91SAM7 MCUs =====
== J-Link Commander ==
 
  +
The reset pin of the device is disabled by default.
https://wiki.segger.com/J-Link_Commander#Using_J-Link_Command_Strings
 
  +
This means that the reset strategies which rely on the reset pin (low pulse on reset) do not work by default.
== Eclipse ==
 
  +
For this reason a special reset strategy has been made available.
https://wiki.segger.com/Eclipse#Using_J-Link_Command_Strings
 
  +
It is recommended to use this reset strategy.
  +
This special reset strategy resets the peripherals by writing to the RSTC_CR register.
  +
Resetting the peripherals puts all peripherals in the defined reset state.
  +
This includes memory mapping register, which means that after reset flash is mapped to address 0.
  +
It is also possible to achieve the same effect by writing 0x4 to the RSTC_CR register located at address 0xfffffd00.
   
  +
===== Type 9: Hardware, for NXP LPC MCUs =====
== Generic ==
 
  +
After reset a bootloader is mapped at address 0 on ARM 7 LPC devices.
If the used IDE / application does not provide the option to pass J-Link Command Strings to the J-Link DLL, we recommend to include them into a J-Link Script File using the J-Link Script File API function ''JLINK_ExecCommand("<JLinkCommandString>")''. For further information how to use a J-Link Script File in your environment, please refer to: https://wiki.segger.com/Using_J-Link_Script_Files
 
  +
This reset strategy performs a reset via reset strategy Type 1 in order to reset the CPU.
  +
It also ensures that flash is mapped to address 0 by writing the MEMMAP register of the LPC.
  +
This reset strategy is the recommended one for all ARM 7 LPC devices.
   
  +
== Change Active Reset Strategy ==
'''Example'''
 
  +
See [[Changing J-Link Reset Strategy]].
Please find below the content of an example J-Link Scipt File which passes the J-Link Command String ''EnableEraseAllFlashBanks'' via the ''JLINK_ExecCommand(...)'' J-Link Script File command to the J-Link DLL.
 
/*********************************************************************
 
*
 
* ConfigTargetSettings
 
*
 
* Function description
 
* Called before InitTarget(). Mainly used to set some global DLL variables to customize the
 
* normal connect procedure. For ARM CoreSight devices this may be specifying the base
 
* address of some CoreSight components (ETM, …) that cannot be auto-detected by J-Link
 
* due to erroneous ROM tables etc. May also be used to specify the device name in case
 
* debugger does not pass it to the DLL.
 
*
 
* Notes
 
* (1) May not, under absolutely NO circumstances, call any API functions that perform target communication.
 
* (2) Should only set some global DLL variables
 
*
 
* Return value
 
* >= 0 O.K.
 
* < 0 Error
 
* -1 Unspecified error
 
*/
 
int ConfigTargetSettings(void) {
 
//
 
// Enable erase for all flash banks (e.g. QSPI)
 
//
 
JLINK_SYS_Report("--EnableEraseAllFlashBanks--");
 
JLINK_ExecCommand("EnableEraseAllFlashBanks");
 
return 0;
 
}
 

Revision as of 16:26, 19 January 2023

J-Link / J-Trace supports different reset strategies. This is necessary because there is no single way of resetting and halting a CPU core before it starts to execute instructions. For example reset strategies which use the reset pin can not succeed on targets where the reset pin of the CPU is not connected to the reset pin of the JTAG connector. Reset strategy 0 is always the recommended one because it has been adapted to work on every target even if the reset pin (Pin 15) is not connected.

What is the problem if the core executes instructions after RESET?
The instructions which are executed can cause various problems. Some cores can be completely "confused", which means they can not be switched into debug mode (CPU can not be halted). In other cases, the CPU may already have initialized some hardware components, causing unexpected interrupts or worse, the hardware may have been initialized with illegal values. In some of these cases, such as illegal PLL settings, the CPU may be operated beyond specification, possibly locking the CPU.

Strategies for Cortex-M devices

J-Link supports different specific reset strategies for the Cortex-M cores. 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.

Note:

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.

Moreover, we recommend that the debugger uses reset type 0 to allow J-Link to dynamically select what reset is the best for the connected device.

Type 0: Normal

This is the default strategy. It does whatever is implemented as the best way to reset the target device. If the correct device is selected in the debugger this reset strategy may also perform some special handling which might be necessary for the connected device. This for example is the case for devices which have a ROM bootloader that needs to run after reset and before the user application is started (especially if the debug interface is disabled after reset and needs to be enabled by the ROM bootloader). If no device specific reset is implemented, this reset is implemented as follows:

  1. Make sure that the device halts immediately after reset (before it can execute any instruction of the user application) by setting the VC_CORERESET in the DEMCR .
  2. Reset the core and peripherals by setting the SYSRESETREQ bit in the AIRCR .
  3. Wait for the S_RESET_ST bit in the DHCSR to first become high (reset active) and then low (reset no longer active) afterwards.
  4. Clear VC_CORERESET.

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 afterwards. The CPU does not start execution of the program because J-Link sets the VC_CORERESET bit before reset, which causes the CPU to halt before execution of the first instruction.

Note:
In most cases it is not recommended to reset the core only since most target applications rely of the reset state of some peripherals (PLL, External memory interface etc.) and may be confused if they boot up but the peripherals are already configured.

Type 2: ResetPin

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 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 reset, which causes the CPU to halt before execution of the first instruction.

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.

Note:

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.

Moreover, we recommend that the debugger uses reset type 0 to allow J-Link to dynamically select what reset is the best for the connected 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 reset is triggered via reset pin with a (by default) 20ms high phase. After the reset signal J-Link waits 100ms delay to let the core boot.

Strategies for ARMv8-AR devices

J-Link supports different specific reset strategies for ARMv8-AR 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.

Note:

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.

Moreover, we recommend that the debugger uses reset type 0 to allow J-Link to dynamically select what reset is the best for the connected device.

Type 0: Normal

This is the one and only reset strategy for ARMv8-AR. A reset pin is mandatory. If the correct device is selected in the debugger this reset strategy may also perform some special handling which might be necessary for the connected device. This for example is the case for devices which have a ROM bootloader that needs to run after reset and before the user application is started (especially if the debug interface is disabled after reset and needs to be enabled by the ROM bootloader). If no device specific reset is implemented, this reset is implemented as follows:

  1. Make sure that the device halts immediately after reset (before it can execute any instruction of the user application) by setting EDECR.RCE == 1
  2. Reset the core and peripherals by toggling the reset pin
  3. Power core if necessary
  4. Enable debug mode if necessary
  5. Clear the reset catch bit (EDECR.RCE == 0)

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 reset release, J-Link continuously tries to halt the CPU. This typically halts the CPU shortly after reset release; the CPU can in most systems execute some instructions before it is halted. The number of instructions executed depends primarily on the 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 the start of the CPU is delayed after reset 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 which resides in flash or ROM needs to be started after reset. This reset strategy is typically used if nRESET and nTRST are coupled. If nRESET and nTRST are coupled, either on the board or the CPU itself, reset clears the breakpoint, which means that the CPU can not be stopped after reset with the BP@0 reset strategy.

Type 1: Hardware, halt with BP@0

The hardware reset pin is used to reset the CPU. Before doing so, the ICE breaker is programmed to halt program execution at address 0; effectively, a breakpoint is set at address 0. If this strategy works, the CPU is actually 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, reset clears the breakpoint, which means the CPU is not stopped after 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. The CPU is halted and performs a sequence which causes a peripheral reset. The following sequence is executed:

  • The CPU is halted.
  • A software reset sequence is downloaded to RAM.
  • A breakpoint at address 0 is set.
  • The software reset sequence is executed.

This sequence performs a reset of CPU and peripherals and halts the CPU before executing instructions of the user program. It is the recommended reset sequence 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 reset release, J-Link continuously tries to halt the CPU using a watchpoint. This typically halts the CPU shortly after reset release; the CPU can in most systems execute some instructions before it is halted. The number of instructions executed depends primarily on the 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 the start of the CPU is delayed after reset release.

Type 5: Hardware, halt with DBGRQ

The hardware RESET pin is used to reset the CPU. After reset release, J-Link continuously tries to halt the CPU using the DBGRQ. This typically halts the CPU shortly after reset release; the CPU can in most systems execute some instructions before it is halted. The number of instructions executed depends primarily on the 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 the start of the CPU is delayed after reset release.

Type 6: Software

This reset strategy is only a software reset. "Software reset" means basically no reset, just changing the CPU registers such as PC and CPSR. This reset strategy sets the CPU registers to their after-Reset values:

  • PC = 0
  • CPSR = 0xD3 (Supervisor mode, ARM, IRQ / FIQ disabled)
  • All SPSR registers = 0x10
  • All other registers (which are unpredictable after reset) are set to 0.
  • The hardware RESET pin is not affected.
Type 7: Reserved

Reserved reset type.

Type 8: Software, for ATMEL AT91SAM7 MCUs

The reset pin of the device is disabled by default. This means that the reset strategies which rely on the reset pin (low pulse on reset) do not work by default. For this reason a special reset strategy has been made available. It is recommended to use this reset strategy. This special reset strategy resets the peripherals by writing to the RSTC_CR register. Resetting the peripherals puts all peripherals in the defined reset state. This includes memory mapping register, which means that after reset flash is mapped to address 0. It is also possible to achieve the same effect by writing 0x4 to the RSTC_CR register located at address 0xfffffd00.

Type 9: Hardware, for NXP LPC MCUs

After reset a bootloader is mapped at address 0 on ARM 7 LPC devices. This reset strategy performs a reset via reset strategy Type 1 in order to reset the CPU. It also ensures that flash is mapped to address 0 by writing the MEMMAP register of the LPC. This reset strategy is the recommended one for all ARM 7 LPC devices.

Change Active Reset Strategy

See Changing J-Link Reset Strategy.