Application not starting up from reset (SAM3)

I've been developing an application using CrossWorks for ARM on a SAM3 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 target is configured to boot from ROM and enter SAM-BA Boot Assistant. This behaviour is controlled by the general-purpose NVM bit 1 and 2 (bit 2 is SAM3U4 only) - see the SAM3 user guides for more information. Note that if you are using the CrossWorks SAM3 FLASH loaders to download the program, these bits should be set correctly for you when the loader starts up.

• The target is configured to enter Fast Programming mode on reset rather than starting your application. This behaviour is controlled by the TST, PA0 and PA1 pins on the SAM3S and TST, NRSTB and FWUP pins on the SAM3U. See the SAM3 user guides for more information.
• The board you are using does not have an external oscillator fitted and the startup code is configuring the processor to use an external oscillator (the default). If you are using the new SAM CPU support package you can set the Build Options > Use On-Chip RC project property to Yes to make the startup code use the on-chip oscillator.

• 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 SAM3 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 so you can diagnose the problem.