Recent

This Page

User

Debug Connection Issues

The way that the debug/reset circuitry is connected up in NXP's ARM7-based LPC2xxx family of MCUs can lead to issues with connecting to these parts using the Code Red IDE and debug probes (this affects tools from other vendors too). Typically, ARM7 connection problems are reported by the Code Red IDE in one or more of the following messages:

These errors indicate that the Code Red IDE was unable to gain debug control of the microprocessor. This can happen for the following reasons.

Excessive JTAG probe speed

250 KHz is the default JTAG speed Red Suite uses for ARM7. In practice, allowable rates are dependent on the core clock. Adaptive clocking is available for those chips which support RTCK. Refer to your processor User's Manual for this information. Adaptive clocking may not be available if your application has reprogrammed the RTCK pin as GPIO, or the reset pin state is not RTCK. NXP ARM7 variants which support RTCK are:

LPC22xx

LPC23xx

LPC24xx

LPC21xx

If adaptive clocking is not available, the general rule for Maximum JTAG speed is one sixth (1/6) the core clock frequency. The frequencies used by the ISP firmware can vary across families, so refer to the documentation. As an example, a safe JTAG speed for the LPC2148 (no RTCK) when booted into the ISP is below 2000KHz. Red Suite offers a "Configuration Option" to preset the NXP ARM7 core clock frequency in the project Debug Configuration.

The name of this setting is "Crystal (XTAL) frequency and PLL value" and the input format for this information is XTAL,FREQ

As an example, if your ARM7 board has a 12 MHz crystal, and the desired core clock frequency is 50 MHz you'd enter:

12000,50000

An internal Red Suite algorithm will attempt to setup the core clock as close as possible to the value requested.

Note that if an attempt to connect at a particular JTAG speed fails, follow-on attempts at lower speeds may fail. Should this happen, cycle the power to the ARM7 and Red Probe in the sequence documented above.

Use of RESET

A side effect of the vector catch option is to pull nSRST. In some circumstances, Red Suite may not be able to establish a debug connection to the part after it comes out of reset. In some cases, this is related to the default reset timings. Should you set the ARM7 "Vector catch" configuration to 'true' (not recommended), you may need to experiment with the following options as a "Miscellaneous" configuration entry:

-rd=ddd Reset delay time in milliseconds after nSRST release

Note: This is a stablize period before debug connect.

-rh=hhh Reset hold time in milliseconds for nSRST assert

As an example, the following "Miscellaneous" configuration entry:

-rh=50 -rd=100

ensures a reset "hold" time of 50 milliseconds, and a reset "delay" time of 100 milliseconds.

The Red Suite reset default values vary according to the ARM family:

ARM7: Default hold: 250 ms Default delay: 50 ms

ARM9: Default hold: 250 ms Default delay: 50 ms

CM0: Default hold: 50 ms Default delay: 0 ms

CM3: Default hold: 50 ms Default delay: 0 ms

Other

Invalid PLL

NXP documents allowable ranges for the PLL output frequency (Fcco). Outside this range, the part is not guaranteed to operate. PLL setup is often part of the boot sequence, so Red Suite may not be able to establish debug halt before the PLL setup code executes and is effectively locked out.

Errata regarding the advertised (documented as 275 - 550 MHz) upper Fcco limit has been issued for the LPC2364, LPC2366, LPC2368, and LPC2378*. There is no known workaround. The errata states the PLL output (Fcco) is limited to 290MHz. The Code Red ARM7 startup code accounts for this errata, so keep it in mind if you change the default configuration.

Disabled JTAG

The pin budget of a particular part can sometimes require a deployed application to reprogram one or more JTAG pins as GPIO for application use. Therefore, a debug connection cannot be established once the part has booted user code.

The first part of the solution is to boot the chip into the NXP ISP command handler. The ISP guarantees a stable operating state once it gains control of the part. You'll then need to set a "Stop on startup at" breakpoint in your project Debug Configuration to stop the part before the faulty PLL setup is performed. The Code Red label/symbol for startup is "start", "_start", or "_mainCRTStartup"**. For this purpose, it's not necessary to communicate with the ISP through UART0.

Details on ISP use can be found in the applicable NXP User's Manual and vendor documentation for your board, On a typical evaluation board, both a RESET and ISP push button are present. To boot into the ISP, each button is pushed simultaneously, and RESET is released before the ISP push button. As the part comes out of reset, the ISP firmware reads the state of the pin connected to the ISP push button. If the pin is LOW, the ISP boots into its own command handler. Otherwise, it reads the value of the check word in user flash, and branches to user code if valid. If your custom board has no provision for an ISP push button, you'll need access to the ISP pin used so it can be held to ground when releasing reset.

Code Read Protection (CRP)

An application may use one of the three CRP levels for security reasons. The CRP level is reflected in a word pattern programmed at the CRP offset in the flash vector table, and becomes effective only after a power cycle. The NXP User's Manual covers these details for the parts which offer CRP.

Depending on the CRP level in use, booting into the ISP may or may not be an option to recover debug.