Why am I getting a hard fault (KV11)?

[lancefisher]

I'm working on a BLDC motor project and am trying to test some algorithms on a FRDM-KV11 board with KDS.  I'm stuck right now because I'm getting a hard fault in the PEX_RTOS_INIT function called from PE_low_level_init().  The hard fault occurs on a push instruction that's putting r4-r7 plus the link register.  That instruction is the first one of a compiler support function labeled "_udivdi3" (address 0xa48) and the the previously executed instruction is a bl to this function at address 0x668.  The MSP is the only stack pointer being used and it's pointing to RAM at an address (0x20002fa0) that's long word aligned (lower 2 bits = 0).  RAM exists at that address as evidenced by being able to display it's contents in a Memory Monitor window.

The hard fault results in the transfer of execution to the default interrupt handler with the xPSR = 0x41000003 (the '03' in the lower bits indicates a hard fault occurred).

I can see no reason for this hard fault to occur but it consistently does happen except that one time after disconnecting everything and restarting KDS.  After that the entire PE_low_level_init function executed normally several times (along with the rest of the program) but when I made a small change to my code (added two lines in the FTM1 IRQ handler) it went back to generating the hard fault on the same instruction as before.  Subsequent attempts to get it working again by disconnecting everything and restarting KDS has had no effect.

I'm using a J-Link SWD adapter for debugging and powering the board via the micro USB connection to the board.  I've also tried powering the board VIA a FRDM_MC_BLDC shield and get the same result.

The attached zipfile should contain everything needed to recreate the project in KDS.  NXP.zip contains some motor control library files which are referenced by the project but are not actually used (yet).

[lancefisher]

I discovered that KDS had selected the wrong part for the debugger.  The debugger was configured for a MKV10 rather than a MKV11 and when I fixed that the problem with the unexpected hard fault went away.  I don't understand how having the wrong but similar part selected in the debugger would cause a hard fault when executing a single instruction from and referencing valid locations in SRAM and Flash though.

[ankulikova164]

I would check also the memory map with your compiler. If you're trying to access a memory location out of bounds, the processor will generate a MemFault exception. If MemFault handler is not set, the exception will be automatically 'promoted' to HardFault tutuapp.

[mjbcswitzerland]

Lance

Please upload the binary file that you are loading to the board. it is usually possible to see the reason for a hard fault happening by loading the binary to the board and connecting to it with a debugger (a map file may help point to the code cause but the binary should be enough to see why).

If you continue to have problems contact me on skype "M_J_BUTCHER" so that you can show me your screen and I'll walk you through identifying the case. Don't worry, I give free 40 minute remote desktop training/debugging and this should be easily enough.

Regards

Mark

http://www.utasker.com/services.html

[lancefisher]

The .elf and .map files are in the zip file I attached to the Community post but I attached them to this email as well.

[mjbcswitzerland]

Hi Lance

I am sorry but I can only find an 8k SRAM part to test on and from the binary file I generated from the .elf file I see it using 16k RAM and thus I can't run it.

Regards

Mark

[lancefisher]

Do you have access to a FRDM-KV11Z eval board? I’ve ordered a second board in the hopes that this is actually a problem with the one I’m using. I’m also having two other issues with this board which I purchased a couple weeks ago from DigiKey.

One is that when debugging and/or using Freemaster with the onboard OpenSDA USB connection the connection drops frequently. For that reason I switched to using a J-Link adapter connected to J13. The FRDM-KV11Z Evaluation Board Users Guide says to cut the trace under J11 which disconnects the path between the signals named SWD_CLK_TGTMCU and SWD_CLK_KV11 but with that path opened the J-Link cannot communicate with the KV11 MCU. This is not surprising given that with that cut the SWD Clock from J13 is no longer connected to the SWD clock pin on the MCU (U4 pin 22). This makes me suspect that a different connection needs to be cut and perhaps that’s the source of my hard fault issue. FWIW, there are other errors in the Users Guide as well, for instance the Cortex Debug connectors J13 and J19 are specified to have 20 pins not 10 and in more than one place the onboard target is called a KV10 rather than a KV11.

According to the schematic cutting jumper J7 would actually isolate the KV11 SWD clock from the Open SDA uC (U6) but it also appears that there are drivers in that path which can (and should) be disabled when the OpenSDA interface isn’t being used. It’s also hard to imagine how any disturbance of the SWD clock signal could cause a hard fault at a consistent address/instruction.

-lance

[mjbcswitzerland]

Hi Lance

I have more than 60 FRDM and TWR boards but unfortunately not the FRDM-KV11Z (I have put it on my shopping list for the next time I am purchasing).

The closest that I have is the FRDM-KV10Z which I was hoping would be adequate, but it is a small SRAM part: http://www.utasker.com/kinetis/TWR-KV10Z32.html

I was wondering whether you may have an uninitialised variable because sometimes it would run - a random value could give random results.

Regards

Mark

[lancefisher]

Do you need me to change the processor to a KV10Z32? You can do this yourself with the files I posted.

-lance

[mjbcswitzerland]

Lance

I couldn't build because
PE_low_level_init.h
is not found.

Regards

Mark

[lancefisher]

Did you run the Generate function first?

-lance

[mjbcswitzerland]

I don't know whether I can do it because the project warns me that there is a component from KDS1.2 being used that is not compatible with KDS3.2.0 that I am using - then PE aborts with an error. (???)

P.S. I tend to prefer to work from a binary because swapping KDS  projects is not always straightforward and sometimes takes more effort that actually finding a problem.

[lancefisher]

Mark,

The attached zipfile contains the generated source files as well as a copy of the project source files. I also removed all references to the two unused motor control libraries. If you import the project from these files you should be able to build the project without having to generate the PE source.

-lance

[mjbcswitzerland]

Lance

I also didn't understand the error message but that is what KDS told me.... [in the meantime I actually think that it was due to an absolute path in the project not matching my installation but I already had moved to the second project].

With the new project I had errors due to not being able to find mlib.a and pclib.a but could change some absolute paths in the project to match where I put these, so it now builds.

I modified the linker script so that it runs on my smaller KV10 and it looks to be OK [it spends a lot of time in the FTM interrupt handler], but I had to disable the watchdog (DISABLE_WDOG) otherwise the watchdog was resetting the processor somewhere during the initialisiation sequence.

Check that you don't have strange effects due to the watchdog (as I first had) and if you still have problems I think that I would need to look at your debugger rather than running it on my board (where I don't see other issues).

Regards

Mark

[lancefisher]

Your reply doesn’t make a lot of sense to me. I’m running KDS 3.2 as well and AFaIK the components are part of SDK, not KDS. I’m using SDK 1.3.0 which is the latest version that supports PE for this part. Perhaps you meant that you can’t build because you don’t have SDK 1.3 installed? If so all you’d need to do is install that. I can supply all of the generated source and object files if you can’t get PE to work.

-lance

[lancefisher]

I believe the project will run with the smaller RAM but if this is a processor bug the problem might not exist in a KV10. I know that a processor bug is unlikely but I have uncovered them before. I don’t think an uninitialized variable could be the cause for several reasons:

1. The only code executing up to the fault is generated by Processor Expert.

2. I traced the problem to the execution of a single machine instruction and the only use of variables (actually registers) by that instruction is that they are being pushed onto the stack, therefore the value of the variables shouldn’t have any effect on the generation of a fault.

3. All RAM is cleared when the processor is power cycled.

4. When the problem temporarily went away, I trapped on the same instruction that was causing the fault and the conditions were identical with those found at that instruction when the fault was occurring.

At the lowest level I’d like to know what could cause a hard fault when executing a push instruction with the MSP pointing to a valid long word address in RAM that exists. As far as I can tell, according to the NXP and ARM documentation that should not happen.

-lance