Difference between revisions of "J-Link Reset Strategies"

From SEGGER Wiki
Jump to: navigation, search
(Strategies for Cortex-M devices)
(Type 0: Normal)
Line 14: Line 14:
 
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.
 
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).
 
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 strategy does the following steps:
+
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 the VC_CORERESET in the DEMCR .
 
# 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 .
 
# Reset the core and peripherals by setting the SYSRESETREQ bit in the AIRCR .
 
# Reset the core and peripherals by setting the SYSRESETREQ bit in the AIRCR .

Revision as of 12:44, 7 July 2021

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.
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.



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.

J-Link Commander

https://wiki.segger.com/J-Link_Commander#Using_J-Link_Command_Strings

Eclipse

https://wiki.segger.com/Eclipse#Using_J-Link_Command_Strings

Generic

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

Example 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;
}