Recent Posts1
NXPTM M522XX, KINETIS and i.MX RT / Re: I sometimes have hard-faults but when they are ignored all work - what is going
« Last post by mark on March 08, 2026, 10:28:59 PM »Hi
Example: When peripherals are enabled (gated) and then used it is possible that between gating and it being ready there is a delay (in the synchronisation of clock domains) that means that the code using the peripheral will use it slightly too early.
What happens is that there is a hard fault. If the hard fault lands in a forever loop it fails. If the hard fault simply returns it then repeats (and works) and all is fine and it continues.
That is, there can be 'temporary' hard faults that are not really critical.
Often they can be avoided by using instruction / data barrier commands like
asm volatile ("dsb 0xf":::"memory");
asm volatile ("isb 0xf":::"memory");
which cause the processor to wait until the previous peripheral write operations have completed but this can be fiddly.
What I do is use a very simple hard fault handler that counts how often it happens, doesn't result in a loop and recovers (if it is a 'real'/serious hard fault it results in a hard fault interrupt loop anyway, which is very easy to debug as you just need to connect with a debugger and you see the exact code that is faulting (over and over again)).
volatile unsigned long ulHardFaultCounter = 0;
// Serious error interrupts
//
static void irq_hard_fault(void)
{
ulHardFaultCounter++; // hard faults are often recoverable so we count how many were detected for statistical reasons
}
I can always check the counter value to see whether it does every occasionally happen. If I prefer to 'clean' it up so that it doesn't I just set a break point on the increment line, let it run and see exactly where it takes place and then, if I want, I can add a barrier instruction (or similar - eg. adding some other code before accessing usually works) to exclude it. Recoverable hard faults are however not really worth worrying about as they have no negative side effects (that I ever experienced).
Regards
Mark
Example: When peripherals are enabled (gated) and then used it is possible that between gating and it being ready there is a delay (in the synchronisation of clock domains) that means that the code using the peripheral will use it slightly too early.
What happens is that there is a hard fault. If the hard fault lands in a forever loop it fails. If the hard fault simply returns it then repeats (and works) and all is fine and it continues.
That is, there can be 'temporary' hard faults that are not really critical.
Often they can be avoided by using instruction / data barrier commands like
asm volatile ("dsb 0xf":::"memory");
asm volatile ("isb 0xf":::"memory");
which cause the processor to wait until the previous peripheral write operations have completed but this can be fiddly.
What I do is use a very simple hard fault handler that counts how often it happens, doesn't result in a loop and recovers (if it is a 'real'/serious hard fault it results in a hard fault interrupt loop anyway, which is very easy to debug as you just need to connect with a debugger and you see the exact code that is faulting (over and over again)).
volatile unsigned long ulHardFaultCounter = 0;
// Serious error interrupts
//
static void irq_hard_fault(void)
{
ulHardFaultCounter++; // hard faults are often recoverable so we count how many were detected for statistical reasons
}
I can always check the counter value to see whether it does every occasionally happen. If I prefer to 'clean' it up so that it doesn't I just set a break point on the increment line, let it run and see exactly where it takes place and then, if I want, I can add a barrier instruction (or similar - eg. adding some other code before accessing usually works) to exclude it. Recoverable hard faults are however not really worth worrying about as they have no negative side effects (that I ever experienced).
Regards
Mark