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:
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.
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:
Press and hold the ISP button.
Whilst still holding down the ISP button, press and release the RST button.
Release the ISP button.
"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...
Right click on the project in the Project Explorer view
Select "Launch Configurations -> Open current launch configuration" from the context sensitive menu.
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".
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.