AnsweredAssumed Answered

HardFault in callFlashRunCommand

Question asked by Kevin Novinger on Nov 21, 2018
Latest reply on Nov 27, 2018 by Mark Butcher

I'm working on a K64 project with MCUXpresso and i'm having issues with an intermittent HardFault.  I say intermittent as it comes and goes based on various code changes.  It is, however, very consistent once it occurs.  It is also dependent upon optimization (i.e. does not occur when debugging with the default Debug config but does occur when using the default Release config).  

With the help of a few other forum and blog posts...

 

https://mcuoneclipse.com/2012/11/24/debugging-hard-faults-on-arm-cortex-m/

https://www.freertos.org/Debugging-Hard-Faults-On-Cortex-M-Microcontrollers.html

https://community.nxp.com/thread/306244

www.keil.com/appnotes/files/apnt209.pdf

 

...i've managed to at least see what instruction is causing the hard fault.  What I could use now is some help deciphering the status registers captured in the hard fault handler.

 

When the hard fault breakpoint hits, this the state everything is in...

 

 

From here, I used stacked_lr (0x76ad) to locate the instruction prior to the break...

 

 

At this point, i'm running under the assumption that the fault occurs when accessing the FTFE (FTFx = 0x40020000) register with callFlashRunCommand.

 

Looking at the values of the hard fault status registers and comparing to the register definitions found in the Keil appnote, I see that bit 17 of the _CFSR is set, which means an invalid state.  Specifically...

 

Based on this information, I find the PC contains 0x20001274.  Looking at this location, I find the following...

 

 

From this, I'm assuming the issue is the first instruction of s_flashRunCommand.

 

As this is part of the flash driver, I'm not sure what all is going on here.  Regardless, I must have either an array out-of-bounds and/or a pointer referencing the wrong address somewhere due to the fact it will work with one code modification but not another.  So, as I make changes I'm just moving the problem around.  That said, it's become very difficult to track down as one change may make it seem the problem is corrected while another, unrelated (one would think) change makes it surface.

 

If I could get some help deciphering what the register snapshot is telling me, I would appreciate it.

 

Some relevant details...

 

MCUXpresso IDE version 10.2.1

Kinetis MK64FN1M0xxx12

Custom Hardware

 

As for the SDK, I'm using v2.4.2, however, due to another issue with flash swap (SWAP does not work from UPPER on SDK 2.4.1 flash driver), I've downgraded the flash drivers to version 2.1.0.

Outcomes