ARM Technical Support Knowledge Articles

RESET BEHAVIOUR ON PHILIPS LPC2000 DEVICES

Applies to: ULINK USB-JTAG Debugger

Answer


Information in this article applies to:


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:

  1. You may use the Keil µVision Simulator during driver development. The Simulator stops after RESET and allows correct debugging of initialization sequences.
  2. 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
    
  3. 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

SEE ALSO

Article last edited on: 2008-09-18 04:51:36

Rate this article

[Bad]
|
|
[Good]
Disagree? Move your mouse over the bar and click

Did you find this article helpful? Yes No

How can we improve this article?

Link to this article
Copyright © 2011 ARM Limited. All rights reserved. External (Open), Non-Confidential