Posted on March 14, 2014 at 12:15Debuggers are invasive, they set up a number of features and settings within the processor in order to function. Absent a debugger it is suggested you provide some diagnostics via a serial port or GPIO(s)
Most probably reason for failure would be that peripheral clocks are not being enabled in your code that the debugger was setting up, basically assumptions about initial conditions. Or there are some timing dependencies that get skewed by the debugger breaking in, or it's simply crashing or stuck in a loop somewhere.
Would suggest you use an effective Hard Fault handler that can output diagnostic information. That you add some stand-alone code at several check-point locations, including the ResetHander (in assembler) to indicate via a GPIO/LED, or USART, the arrival a key points of your code. You need to ascertaining if
any of you code (or code paths) are functioning, and just how far it gets. Then use bisection to focus on the specific code causing problems.
If it's not executing any of your code (and you can control the first instructions that get executed), then you need to examine the flash image, and what's being written to memory. And for basic things like the state of the BOOTx pins, and NRST
