Application not starting up from reset

I've been developing an application using CrossWorks for ARM 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?

Please check the following common causes:

• 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 target is starting a bootloader or booting from another memory source from reset. Make sure the target is configured to boot from the correct memory source - this is often configurable on the target board, see the board and target user guides for more information.

• 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.

• The target is being held in reset by the target interface device. Some target interface devices may hold the target in reset when not in use - try disconnecting the device.

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

• Manually power-cycle or reset the target.
• Attach the debugger by selecing Target > Attach Debugger.
• Break the execution by selecting Debug > Break. The debugger should locate to the current instruction being executed.