Posted on April 21, 2013 at 02:07While it might be convenient to ponder on silicon issues causing your problem, this is usually not the case. The hardware is well validated, the internal timing well characterized, and critical paths well known. Things still apt to bite you would be issues in the flash, or prefetching paths, where the waits states are insufficient or clocks are too fast. These would typically present as gross failures, other design issues would be encountered by other people.
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.
The resource rich developer would use hardware trace to map the route to the failure, the poorer one would output telemetry, walk back the stack and call trees, and use handlers that output useful diagnostics.
If you still think things are random, and unrelated to anything your code is doing, start looking at the supplies, the clocks, the PLL stability. Check currents and temperature. Check soldering and mechanical issues.
