Regaining debug access to target MCU

[lpcware-support]

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

• The image contains code that sets the MCU clocks up "incorrectly".
• The image contains code that enables a watchdog timer.
• The image contains code that puts the MCU into a very low power mode.
• The image contains code that "switches off" some, or all of the multiplexed debug pins (JTAG/SWD).

If you do this, then there are a couple of possible ways to try to recover debug access to the MCU (depending upon the MCU being used).

Once you have managed to recover debug access to the MCU, the first thing that you should do is overwrite the image in flash with one that sets the system up in a safe manner, so that future debug connections will be successful without the need to recover debug access again. You would normally use the in-built flash programmer to erase the flash.

Boot into ISP mode

The first thing to try to recover debug access is to boot into the ISP bootloader. This is normally controlled by the state of ISP pin(s) as the MCU comes out of reset.

Note : Recent versions of LPCXpresso IDE support the resetting of the target MCU via LPC-Link2 for certain target boards. For more details see the FAQ: ISP Reset over debug

For most parts, there is a single ISP pin. The procedure is then to GND the ISP pin, assert RST, then remove the GND to ISP pin. Once in the ISP bootloader, the target clock configuration is stable, and the debug pins are in their default state - you should be able to start a debug connection.

Note that the actual location of the ISP pin(s) will depend upon your target MCU. For example:

• P0.1 - for LPC11xx and LPC13xx

• P2.10 - for LPC17xx

Note that for certain MCUs, booting is controlled by two ISP pins. For more details, please consult the user manual for the MCU being used.Many off-the-shelf development boards will actually provide an 'ISP" button (in many cases doubling up as an external interrrupt button). For example the LPC1768 on the RDB1768 development board can be placed into ISP mode by:

1. Press and hold the ISP button.

2. Whilst still holding down the ISP button, press and release the RST button.

3. Release the ISP button.

"Vector catch" option in debugger

"Vector catch" is an option in the LPCXpresso IDE that makes subtle changes to the way the debugger handles reset when connecting to a target. The default setting varies between MCUs, and we set the default to the one that will allow a successful connection the majority of the time.

Generally you should never need to worry about its value. But in some circumstances, changing the default vector catch setting can sometimes allow the debugger to regain control over a target that has become locked to normal, default behavior debug connections - mainly if booting into the LPC MCU's ISP mode (as detailed above) is not possible for some reason.

Note : On MCUs where we enable the vector catch option by default, this method of debug connection recovery is generally not possible.

To enable "vector catch" for the currently selected build configuration...

1. Right click on the project in the Project Explorer view

2. Select "Launch Configurations -> Open current launch configuration" from the context sensitive menu.

3. Click on the "Debugger" tab, then set the "Vector catch" entry to true.

For more information on launch configurations, please see the FAQ "Launch Configuration Menu".

Vector Catch - Detailed description

The LPCXpresso IDE debugger "vector catch" option was designed to drive the connection sequence through additional steps while connecting debug. A successful debug connection requires AP access to the private bus. If the vector catch option is used, the debugger attempts to connect debug, then enables the Cortex CPU's reset vector catch and issues a VECTRESET or SYSRESETREQ signal. If the "Reset Handling" debug configuration option is not VECTRESET, then the SYSRESETREQ is used. Post Cortex CPU reset vector catch, the stub attempts to validate AP access on the private bus before proceeding with other setup. So, the main benefit of the "vector catch" option is the part gets reset during the initial debug setup.

[mark_derlo]

1. Great advice - it helped me today : here is what happened to me today. After I tried to start DEBUG session, I got this:

    02: Failed on connect: Ep(01). Target marked as not debuggable

I encountered this problem with my (now 13 years old !) LPCXpresso 'LPC1769 Rev B, 2010' dev board:

PS. I do not understand what 'Pull ISP on reset (on LPC-Link 2)' would actually do if I tried that

So I forced a short circuit to GND two pins: RESET pin (connector J6 - pin 4) and ISP pin (connector J6 - pin 51).

Then turned the power on. Then I disconnected RESET pin from GND and then ISP pin from GND and ... I built my code and was able to start DEBUG session under Xpresso IDE (v 8.2.2).

---

2. I also followed your link : ...FAQ: 'ISP Reset over debug', but I do not understand what would it actually do if I de-select "Pull ISP on reset (on LPC-Link 2)".
I am scared to muck around with that so that I might lock the MCU again !

---

But I am so happy that I did not have to investigate the FlashMagic solution etc.etc .