Stack trace after handler HardFault

Norbert,

I see that you also posted this question to the TM4C device forum, where Chester has provided some good suggestions. In addition, you may find this application report helpful, it has recommendations for diagnosing and dealing with faults.
http://www.ti.com/lit/an/spma043/spma043.pdf

Hi,

thank you for the reply, I checked the guide you pointed out, and tried to use as well without success. Following the guide, I see the followings:
* Checking the NVIC_FAULT_STAT register, I'm in IMRECISE fault.
* Copy - paste the current value of SP into the Memory Browser window, I see the value on the position of PC in the stack: 0001B860
* Copy - paste this into Disassembly window, I see the following (the PC points to the next line of "vPortEnableVFP()" label):
vPortStartFirstTask():
0001b84c: F64E5008 movw r0, #0xed08
0001b850: F2CE0000 movt r0, #0xe000
0001b854: 6800 ldr r0, [r0]
0001b856: 6800 ldr r0, [r0]
0001b858: F3808808 .word 0x8808f380
0001b85c: B662 cpsie i
0001b85e: DF00 svc #0
vPortEnableVFP():
0001b860: F64E5088 movw r0, #0xed88
0001b864: F2CE0000 movt r0, #0xe000
0001b868: 6801 ldr r1, [r0]
0001b86a: F4410170 orr r1, r1, #0xf00000
0001b86e: 6001 str r1, [r0]
0001b870: 4770 bx lr
service::outbound::OutputEvaluator::evaluateBranchTimeOutOn():
0001b872: B500 push {lr}
0001b874: F1AD0D14 sub.w sp, sp, #0x14
0001b878: 9000 str r0, [sp]

As you see, there are three methods, 2 of them are from FreeRTOS port and the last one is one of mine. Checking carefully the evaluateBranchTimeOutOn, I don't think that it can cause Fault, but be sure, I commented out the inside of it. It didn't solve my problem, IMPRECISE hard fault raised again.
Furthermore, I checked the another two methods as well, they are used only at startup (I don't deploy threads at run).

Can anybody help me, how should I discover the root cause of fault?

Regards,
Norbert

Norbert Toth said:

Following the guide, I see the followings:
 * Checking the NVIC_FAULT_STAT register, I'm in IMRECISE fault.

As noted by the guide the IMRECISE fault means the fault occurred on a previous instruction. What is the hex value of the following:

- Memory Management Fault Status (MFAULTSTAT)
- Bus Fault Status (BFAULTSTAT)
- Usage Fault Status (UFAULTSTAT)
- Bus Fault Address Register (FAULTADDR)

Hi,

the values are:
* the first three is mapped together, they value is: 0x00000400 (IMRPECISE fault)
* the bus fault address register: 0xE000EDF8

Regards,
Norbert

Norbert Toth said:

the values are:
* the first three is mapped together, they value is: 0x00000400 (IMRPECISE fault)
* the bus fault address register: 0xE000EDF8

OK, the bus fault address register isn't valid in this case.

Looking back at the original code sequence, in which the IMPRECISE fault occurred when the PC was at 0001B860, the preceding instruction was svc #0, i.e. a Supervisor Call:

Norbert Toth said:

0001b85e: DF00 svc #0
vPortEnableVFP():
0001b860: F64E5088 movw r0, #0xed88

Does the program have a SVC Handler installed in the interrupt vector table?

Hi,

yes, I checked it, the correct handler address is there.
Nevertheless, I need to wait for some seconds and numerous execution period (my application executes its task periodically) that isn't a fix number to getting into HardFault ISR so I don't understand what's happening and why is it so late...

Regards,
Norbert

Norbert Toth said:

Can anybody tell me (is there anybody who has solid experience?) how can I dump the actual state stack just before the HardFault exception raised?

I took the FreeRTOS full demo for the Cortex-M4F based MSP432 and caused one task to generate a hard fault after a period of time, to be able to test dumping the stack state.

The screen shot of dumping the stack state prior to the HardFault is:

The Memory Browser shows the stack starting from 0x2000ff98, which was the stack pointer inside the faultISR Hard Fault handler, where faultISR is the default which just contains an infinite loop.

The Core Registers in the Registers View were manually edited to contain the values prior to the Hard Fault:

- PC set to 0x00008BCE taken from the contents of faultISR SP+0x18
- SP set to 0x2000FFBC taken as faultISR SP+0x24

Once the PC and SP had been set, the Debug view showed the stack backtrace prior to the Hard Fault. The stack backtrace shows the expected values based upon where the hard fault was deliberately injected, by the ulGetRunTimeCounterValue function reading from address 0xf0000000 - CCS has correctly shown the source code line which dereferences the bad_ptr to cause the hard fault.

This shows that CCS 6.1.1 can correctly show the actual stack state prior to a hard fault, when the PC and SP values are taken from the values saved on the stack prior to the hard fault.

Norbert Toth said:

Nevertheless, I need to wait for some seconds and numerous execution period (my application executes its task periodically) that isn't a fix number to getting into HardFault ISR so I don't understand what's happening and why is it so late...

OK, I would suspect something like insufficient stack space or a bug where memory is overwritten leading to the Hard Fault.

Also, a debug attempt above showed the vPortEnableVFP() function which showed up as the PC value prior to the Hard Fault. From looking at the FreeRTOS demo vPortEnableVFP() is only called when the FreeRTOS scheduler is started. i.e. wouldn't expect vPortEnableVFP() to appear on the stacktrace after tasks had been running for some seconds. Maybe worth another attempt to get the stack backtrace after the Hard Fault to verify that the stack was decoded correctly.