Posted on April 27, 2013 at 15:33Well assume it's not a problem with the USART.
The processor stacks some of it's context, other data remains in current registers, and within the core. When it faults it does very specific things, and in order to determine what was going on you need to wind that back. Knowing where the code faulted, and the registers at the time you can make some educated guess about why that might have occurred. If you don't understand the flow of your code you can add checkpoints to confirm addresses or variables. A grasp of assembler will be helpful.
You need to review the TRM (Technical Reference Manual) for the core, along with Joseph Yiu's book on the Cortex-M3. Look at some of his Hard Fault Handler code examples.
Let's assume your problems are like most others, hard faults tend to catch gross errors, not subtle ones of logic or algorithms. As such they should be a lot easier to pin down and resolve. You need to understand where in your code they occurred, and what you were doing at the time. The predominant cause of hard faults are broken/invalid pointers, out of scope accesses, stack corruption, and the stack and heap colliding with each other. These can be tracked with asserts, or validation of structures at key points or periodically, adding guard zones and checking them. Expect the points of failure to be similar, either occurring at the same places (ie use of particular subroutines, or code), or while doing the same things (ie returning from a subroutine, use of particular pointers).
If the failure point appear random, consider if they occur immediate after an interrupt service, if those services exceed the available resources at the time, or interact with other tasks. Instrument the interrupt entry/exit so you can place them in the time line of the failures.
