ULINK: RESET BEHAVIOUR ON PHILIPS LPC2000 DEVICES

Information in this article applies to:

ULINK USB-JTAG Adapter
ULINK2 USB-JTAG Adapter
µVision Debugger for ARM

QUESTION

When I use the RESET command during ULINK debugging in the µVision Debugger, the LPC2000 peripherals are not set to the RESET state defined in the data sheet. And, it appears that the Debugger starts executing the user application.

How can I perform a true device RESET?

ANSWER

Yes. The µVision RESET button is a true device RESET (using the Chip Reset pin on the JTAG connector). However, the ARM Embedded ICE typically does not allow stopping immediately after a RESET (only some devices support such a feature).

On the Philips ARM devices, a JTAG halt command must be issued to stop program execution after a RESET. ULINK attempts to issue this command to stop the device immediately after RESET, but due to the serial nature and the high execution speed of the LPC2000 devices, it is likely that the startup code is already executed and peripherals are initialized.

In any case, ULINK sets the program counter back to zero (in the RESET case). In this way, you may track the initialization code, but some of that initialization code may already be executed.

There are the following solutions to this problem:

You may use the Keil µVision Simulator during driver development. The Simulator stops after RESET and allows correct debugging of initialization sequences.
You may query a flag in the startup code and set this flag to zero. Unless you enable the flag via the debugger, the code execution will not continue. In this way, you may debug the initialization code of your application using the ULINK USB JTAG-Adapter. Below is a simple example that you may use at the beginning of main:
```
void main (void)  {
  int volatile startup = 0;

  while (startup==0);    // set startup to 1 in the debugger to continue execution
    :                    // rest of your main program
```

You may use a delay loop of about 0.3 Sec at the beginning of main with gives the debugger enough time to get control over the CPU:

void main (void)  {
  unsigned long volatile start;  // volatile avoids loop optimization

  for (start = 0; start < 10000000; start++) {
    ;    // wait for debugger connection (about 0.3 sec)
  }

IMPORTANT NOTE

When testing programs in RAM (by modifing the PC), the device may still execute existing code in the on-chip Flash ROM. Therefore it is important that you erase the Flash or program an endless loop into the on-chip Flash ROM.

MORE INFORMATION

Refer to Reset Sequence in the ULINK® User's Guide.
ARM Getting Started User's Guide

FORUM THREADS

The following Discussion Forum threads may provide information related to this topic.