Application not starting up from reset (LPC1000)

I've been developing an application using CrossWorks for ARM on an LPC and it is all working with no problem.

However when I try and start the application by power cycling or resetting the target without assistance from CrossWorks the application does not start up. What am I doing wrong?

The most likely causes are:

• STARTUP_FROM_RESET has not been defined when assembling the startup code. Some versions of the ARM startup code won't start up the application from reset by default, this is to workaround problems with the ARM reset by allowing the debugger to reset the CPU and run programs from a known reset CPU state on each run. Not allowing the application to startup from reset also acts as a safety net if you accidently download a program in FLASH that crashes and prevents the debugger from taking control over JTAG rendering the target unusable over JTAG. To define STARTUP_FROM_RESET select the startup code in the the project explorer, right click, select Properties and then add STARTUP_FROM_RESET to the Preprocessor > Preprocessor Definitions project property.

• The LPC entering the ISP command handler mode rather than starting up the application. This could be caused by the following:

  • PIO0.1 (LP11xx and LPC13xx), PIO0.12 (LPC122x) or P2.10 (LPC17xx) low on reset, this is seen as a request to enter ISP command handler mode. Most LPC target boards have some method to control these signals.
  • An invalid exception vector checksum. Exception vector location 7 (0x0000001C) should contain the 2’s complement of the check-sum exception vector entries vectors 0 through 6. If you are using CrossWorks' default LPC startup code and you have not modfied any of the exception vector table or Link Patch Command project property then this should not be the problem as this has already been done for you.
• The application is trying to communicate with the host. If your program has calls to debug I/O functions (debug_printf, etc) then this can make standalone applications block as these functions expect to communicate over the debug interface with a host application.

If you don't think the cause is any of the above you can see what the LPC is doing by carrying out the following actions:

• Manually power-cycle or reset the target.
• Attach the debugger by selecting Target > Attach Debugger.
• Break the execution by selecting Debug > Break. The debugger should locate to the current instruction being executed, if the address of the instruction being executed is 0x1FFFxxxx then you are executing out of the boot block and it is likely the LPC is in ISP command handler mode.