Posted on May 17, 2011 at 09:50I found the answer on Rowley's website:
With a lot of ARM CPUs it is not possible for the debugger to reset the target and maintain control of it over the JTAG interface, this means that a program will run for a period of time after reset before the debugger can stop it which leaves the CPU in an undefined state.
We've started adding to the startup code of ARM CPUs that exhibit this behaviour some code that prevents the CPU starting up from reset, the advantage of doing this is that it allows the debugger to reset the CPU and run programs from a known reset CPU state on each run. It 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. The obvious disadvantage of doing this is that your application will not startup without the debugger.
This mode of operation can usually be disabled by defining the C preprocessor definition STARTUP_FROM_RESET when compiling the startup code, however doing so will mean that a reset carried out by the debugger will leave the processor in an undefined state which can cause your application behave unpredictably.
If you want to debug your application with STARTUP_FROM_RESET defined you should not allow the debugger to carry out the reset, instead you should manually reset the target and attach the debugger to the running program using Debug > Attach Debugger rather then using Debug > Start Debugging or Debug > Reset And Debug.
