Application not starting up after reset (AT91SAM7)

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

However when I try and start the application, either by power cycling or resetting the target manually, my application does not start up. What am I doing wrong?

Please check the following common causes:

STARTUP_FROM_RESET not 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.

Target is configured to boot from ROM and enter SAM-BA Boot Assistant

• You are using an AT91SAM7X, or AT91SAM7XC and it is configured to boot from ROM and enter SAM-BA Boot Assistant on reset. This behaviour is controlled by general-purpose NVM bit 2, you can set this bit by writing 0x5A00020B to the MC_FCR register - see the AT91SAM7X/AT91SAM7XC user guides for more information.

Target is configured to enter Fast Programming mode

• You are using an AT91SAM7S, AT91SAM7X or AT91SAM7XC and your target is configured to enter Fast Programming mode on reset rather than starting your application. This behaviour is controlled by the TST, PA0, PA1 and PA2 pins - see the AT91SAM7 user guides for more information.

Target is trying to communicate with the host

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

I've checked all that and I'm still not seeing any life

If you've checked all the above above then you can see what the CPU is doing by carrying out the following actions:

• Manually power-cycle or reset the target.
• Ensure your JTAG adapter is connected to the target and is connected in the IDE.
• Choose Target > Attach Debugger to attach the debugger to the target.
• Choose Debug > Break to stop the processor executing. The debugger should locate to the current instruction being executed so you can diagnose the problem.