Keil Logo

Debug

The Debug section controls the connect and reset behavior, cache options, and download options that are applied each time a debug session starts.

Target Driver Setup — Debug

The Connect & Reset Options controls how µVision establishes a connection to the target device.

The Connect selection controls what happens when the µVision debugger connects to the target device.

  • Normal — just stops the CPU at the currently executed instruction after connecting.
  • with Pre–reset — applies a hardware reset(HW RESET) before connecting to the device.
  • under Reset — holds the hardware reset(HW RESET) signal active while connecting to the device. You may use this option when the user program mistakenly disables the JTAG/SW interface.

Reset after Connect, if enabled, performs a reset operation as defined in the Reset drop-down list (see below), after connecting to the target. If disabled, the debugger just stops the CPU at the currently executed instruction after connecting.

The Reset selection controls the target device reset operation. All reset options apply to Cortex-M processor-based devices, are available in JTAG and SWD mode, and halt the CPU after the reset.

  • Normal — selects one of the reset methods based on the target device and might perform some special handling if necessary. For example, when devices have a ROM bootloader that needs to run after reset and before the user application is started. Specifically, if the debug interface is disabled after reset and needs to be enabled by the ROM bootloader.
  • Core - performs a reset of the Cortex-M core only by setting the VECTRESET bit. On—chip peripherals are not reset. For some Cortex—M devices, this reset method is the only way they may be reset. However, in most cases this method is not recommended, because 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.
  • ResetPin - J-Link pulls its RESET pin low to reset the core and peripherals. Normally, this causes the CPU RESET pin of the device to go low as well, resulting in a reset of the CPU and peripherals. This reset method will fail if the RESET pin of the target device is not pulled low.
  • Connect under Reset - connects to the target while keeping Reset active. This is the recommended method for STM32 devices, and has been designed for cases where communication with the core is not possible in normal mode.
  • Halt after Bootloader - selects one of the reset methods based on the target device, but (contrary to Normal) the bootloader is always executed. Use this method for MCUs/CPUs that have a bootloader located in ROM and which needs to run at first, after reset. When using this method, the bootloader runs after reset, the target is halted immediately after the bootloader and before the target application starts. This is the recommended reset strategy for LPC11xx and LPC13xx devices.
  • Halt before Bootloader - performs a reset of the core and peripherals, and halts the CPU immediately after reset. The ROM bootloader is NOT executed.
  • Kinetis - performs a reset via strategy Normal. Resets the core and peripherals, and halts the CPU immediately after reset. After the CPU halted, the watchdog is disabled, because the watchdog runs after reset by default. If the target application does not feed the watchdog, J-Link loses connection to the device.
  • ADI Halt after Kernel - performs a reset of the core and peripherals by setting the SYSRESETREQ bit. The core can perform the ADI kernel (which enables the debug interface), but is halted before the first instruction after kernel execution. This ensures that no user application code is performed after reset.
  • Core and Peripherals - J-Link tries to reset both, the core and peripherals by setting the SYSRESETREQ bit. VC_CORERESET in the DEMCR is also set to ensure sure that the CPU is halted immediately after reset and before executing any instruction.

     

    This type of reset may fail if:

    • J-Link has no connection to the debug interface of the CPU because it is in a low power mode.
    • The debug interface is disabled after reset and needs to be enabled by a device internal bootloader. This would cause J-Link to lose communication after reset since the CPU is halted before it can execute the internal bootlader.
  • LPC1200 — On NXP LPC1200 devices, the watchdog is enabled after reset and not disabled by the bootloader, if a valid application is in the flash memory. Moreover, the watchdog keeps counting if the CPU is in debug mode. When using this reset method, J-Link performs a reset of the CPU and peripherals, using the SYSRESETREQ bit and halts the CPU after the bootloader has been performed and before the first instruction of the user code is executed. Then, the watchdog of the LPC1200 device is disabled. This reset method is guaranteed to work only on "modern" J-Links (J-Link V8, J-Link Pro, J-link ULTRA, J-Trace for Cortex-M, J-Link Lite) and if a SWD speed of min. 1 MHz is used. It should also work for J-Links with hardware version 6, but it can not be guaranteed that these J-Links are always fast enough in disabling the watchdog.

The Cache Options improve the performance of the µVision Debugger during target debugging by caching target memory areas in the PC memory. By default, caching options are enabled to get maximum performance.

  • Cache Code — informs the debugger that the downloaded program code will not change. When this option is set, µVision never reads the program code from the target system. Disable this option if you are using self—modifying code or if you suspect that your program code is being overwritten.
  • Cache Memory — determines whether memory displays are updated during a program stop. When this option is set, the debugger does not update memory displays until the next single step, procedure step, or go command executes. Disable this option if you want to see the actual memory content (e.g. the data content of memory mapped peripherals) when the debugger is halted.

The Download Options control the downloading of code to the target system when the debugger starts.

  • Verify Code Download compares the content of the target memory with the application program loaded in the debugger for each new debug session. Enable this option to ensure program correlation between the image loaded in target system and the image loaded in the µVision debugger. This prevents debugging the wrong code when working with various targets or more instances of µVision.
  • Download to Flash — downloads code to all memory regions. When disabled, the debugger does not download code to the Memory Address Ranges defined under Flash Download Setup.
  Arm logo
Important information

This site uses cookies to store information on your computer. By continuing to use our site, you consent to our cookies.

Change Settings

Privacy Policy Update

Arm’s Privacy Policy has been updated. By continuing to use our site, you consent to Arm’s Privacy Policy. Please review our Privacy Policy to learn more about our collection, use and transfers
of your data.