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 :
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:
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, 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".
Note:
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 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 ...
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:
For the command line flash programmer:
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.
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.