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:
The LPC entering the ISP command handler mode rather than starting up the application. This could be caused by the following:
P0.14 low on reset, this is seen as a request to enter ISP command handler mode. Most LPC target boards have some method to control this signal, check that P0.14 is low on high on reset.
An invalid interrupt vector checksum. The reserved ARM interrupt vector location (0x00000014) should contain the 2’s complement of the check-sum of the remaining interrupt vectors. If you are using CrossWorks' default LPC startup code and you have not modfied any of the interrupt vector table then this should not be the problem as this has already been done for you.
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 not booting from the correct memory on reset. If the LPC2000 you are using has an external memory interface check that the BOOT pins are configured so that the CPU will select the correct memory to boot from on reset (usually internal FLASH).
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 selecing Debug > 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 0x7FFFxxxx then you are executing out of the boot block and it is likely the LPC is in ISP command handler mode.