Hi
I have always just used the basic
static void irq_hard_fault(void)
{
}
The reason is that it codes to just a call with a return. When a hard fault occurs (sometimes it is good to have the watchdog disabled so that it doesn't reset too quickly) it goes to this handler and returns immediately. It then performs the same operation that caused the fault and calls the handler again: this repeats forever. Therefore, one just needs to pause the debugger and step once and the instruction causing the fault is visible. Other details are superfluous because the instruction is clear.
I suggest you try this and see whether it is in fact simple to see the cause (and PC) of a hard fault when using the debugger.
The various hard fault handlers could be useful for capturing the details to be logged somewhere in running systems that allow post analysis although my experience is that often such faults are due to memory being overwritten that only happen infrequently. Sometimes the fault is a zero pointer jump causing a hard fault - in such cases the cause of the fault is not visible (the hard fault just shows code trying to execute at 0 or use a crazy value, but not why). In these cases trace would be useful so that the hard fault could cause a trace trigger and then the sequence that 'led up to it' can be seen. It however still doesn't mean that the fault is necessarily visible since memory corruption errors can cause failures to occur a long time later too....
Regards
Mark
