ISP Reset over debug

显示  仅  | 搜索替代 

ISP Reset over debug

12,493 次查看
Senior Contributor I

The need for ISP Reset

It is possible to download an image into the flash on a target that will then prevent any further debug access or connections. The classic cases of this are that the image contains code that :

  • Sets the MCU clocks up "incorrectly".
  • Enables a watchdog timer.
  • Puts the MCU into a very low power mode.
  • "Switches off" some, or all of the multiplexed debug pins (JTAG/SWD).

If the MCU comes out of reset and executes such code before the debugger can take control of the system, then the debugger will not be able to make a succesful debug connection. With LPCXpresso IDE, this will result in errors such as:

  • RedlinkAPI: Wire Ack Fault - target connected?
  • 02: Failed on connect: Ep(01). Target marked as not debuggable

LPC MCUs typically features 1 or more "ISP" pins which are read by the built-in bootloader at reset which determine whether the image in flash should be executed or not. This means that it is typically possible to recover a target with a "bad" image programmed into flash by triggering an "ISP reset" where appropriate ISP pin(s) is pulled as the board is reset, often by means of a push button.

LPC-Link2 hardware support for ISP Reset

LPC-Link2, in both standalone form and the on-board version on LPCXpresso V2/V3 boards, have a signal called ISP_CTRL coming out of the LPC-Link2 debug MCU (LPC43xx). This is connected to pin 7 of the SWD connector in the case of the standalone LPC-Link2 and directly to the target MCU in the case of the LPCXpresso V2/V3 boards.  The ISP_CTRL signal thus provides a way for the debug tool to emulate having the ISP push button pressed. This may allow a debugger to regain debug control of the target in some circumstances.

In the case of the standalone LPC-Link2, the target board being connected to will need to have pin 7 of the SWD connector wired to the appropriate ISP signal of the MCU on the target board. Many boards do not currently implement this though, as the standard ARM spec for the Cortex 10-pin SWD connector has this pin as a "key".


  • In some circumstances an ISP reset of an already active system may not be sufficient to allow the debugger to regain control. In very low power modes for some MCUs (e.g. deep power down), it may be necessary to trigger a WAKE interrupt or even to do a Power ON ISP reset (i.e. power the board up with the ISP button depressed) in order to recover.

LPC-Link2 firmware support for ISP Reset

In order to use the ISP Reset hardware functionality, LPC-Link2 CMSIS-DAP firmware version V5.134 (as provided in LPCXpresso IDE v8.0.0 and LPCScrypt v1.6.0)  or later is required. This firmware implements the CMSIS-DAP “DAP_ResetTarget” target specific command, allowing any debugger which supports this CMSIS-DAP command to force a target ISP reset.

LPCXpresso IDE support

LPCXpresso IDE v8.0.0 and later will automatically invoke a "redlink server" command (wireispreset) when starting a debug connection to an LPC-Link2, which triggers a call to the CMSIS-DAP "DAP_ResetTarget" command in the firmware. This will cause the debug connection to only be started after an ISP reset has been triggered - assuming that the target hardware supports this.

This behaviour can be disabled by unticking the workspace preference ...

  • Window > Preferences > LPCXpresso > Redlink Options > Pull ISP on reset (on LPC-Link 2)

ISP Reset with the LPCXpresso IDE GUI and command line flash programmers

In order to allow an ISP reset connection to be made when using the LPCXpresso IDE's flash programmers directly (either from the GUI or via command line), a redlink server script is provided to trigger this. To use this:For the GUI flash programmer:

  • Add the script "ISPResetConnect.scp" to the "CMSIS-DAP Options - Connect Script" box within the dialog.

For the command line flash programmer:

  • Add the option "-ConnectScript=ISPResetConnect.scp" to the crt_emu_cm_redlink command that you are using to program your flash

Known Restrictions

LPC18xx / LPC43xx

Due to errata in the implementations of LPC18xx and LPC43xx parts, the LPC-Link2 ISP reset functionality may not be able to recover such parts when they have been put into low power modes.


The LPC-Link2 ISP Reset functionality does not work with LPCXpresso1549 Rev. B boards. It does work with Rev. C boards. A debug ISP Reset will not be able to recover a system in Deep power down mode.


A debug ISP Reset will not be able to recover a system in Deep power down mode.

Related FAQs

标签 (2)
标记 (3)
1 回复

4,050 次查看
Contributor III

Is there anything that can prevent ISP mode from working?  We believe we have a hardware/software state that approximately 3% of our units in the field (roughly 1K units) are experiencing, and being returned to use because the processor appears to have no internal frequency content (as verified with spectrum analyzers and near field EM probes.  It appears our back door with ISP over USB0 using lpcscrypt is not able to recover these bricked units in the field that appear to not have any clocks running at all in them.  I stumbled upon this article because they also cannot be debugged, and while I completely understand that part, I do not understand why they also cannot be recovered over ISP.  It seems the bootloader should always be able to be executed by strobing ISP at reset and asserting the appropriate boot cfg resistors.  Is there something else that I'm missing?  

The units can be recovered manually if VBAT is disconnect and all power removed, but this is not always feasible to the customer since it involves opening up the case and removing/reinserting the PCB that the LPC4367 is on.

0 项奖励