What Causes Hard Fault

[jeremyanderson]

I'm using the FRDM_K66 board and running the FreeRTOS Uart Demo project.  I've been able to modify it receive data from an external source and to recover from ring buffer overrun.  This is my typical use case since the application will come up on a live bus that could be generating a steady stream of data and we need to obtain sync by parsing until we see the synchronization pattern.  What I've observed though is that if I start the application on a quiet bus and then start the data stream I end up in the HardFault_Handler ISR.  I don't see how to trace back from this though I can set breakpoints and figure it out eventually.  I'm just curious since it is not clear to me what events are bound to this interrupt number.  Any remarks or commentary would be helpful.

[BlackNight · Accepted solution]

Hi Jeremy,

there are multiple reasons for hard faults on Cortex-M, the most common ones are trying to write to a read only location, or access a peripheral which is not clocked.

Another reason exists for the Kinetis series: there is a memory boundary at address 0x2000'0000. Technically, the SRAM is segmented and not continuous. If using FreeRTOS or any other kind of application you are not allowed to place objects across this memory boundary, otherwise you very likely will run into a hard fault too. The problem is described in Using Multiple Memory Regions with the FreeRTOS Heap | MCU on Eclipse  (check out the discussions on that article too). If you want to use the memory in both memory segments, then have a read here: Using Multiple Memory Regions with the FreeRTOS Heap | MCU on Eclipse.

What worked for me best to detect the location of a hard fault is using software or hardware trace or a custom hard fault interrupt handler, see Debugging Hard Faults on ARM Cortex-M | MCU on Eclipse .

I hope this helps,

Erich

[jeremyanderson]

Thank you Erich.  This has been quite helpful to me though I've apparently stumbled into an obscure problem.  I copied your solution for the HardFault_Handler and followed the pc back to a function in which interrupts are enabled.  The problem always shows up about the same place in the interrupt enable function even if I rearrange the statements.  I conclude from this that the problem has already happened by the time we call the function.  I'm simulating a bus master using the console on my PC and found that the the bit sense of the PC and the FRDM board are opposite so I set RXINV in S2 and TXINV in C3 at initialization time.  Everything works fine except for the above-described problem that I hit a hard fault if I start the demo application on the FRDM before starting the data on the PC console.  If I start the data on the PC by starting my script before I start the demo application the FRDM board, everything works fine..  In practice this is not going to be a problem because my application is going to come up monitoring its own transmissions, but I'd like to understand why this is happening.  Thanks again for the help with this matter though.  You've probably saved me hours of trouble with the memory segmentation warning alone.