Cortex M4 hard fault finding root cause on LPC4078 pc=0x0

Hello Andy Neil

yes, I've got the Definitive Guide, but it's for Cortex M3 instead M4 in my case?

Do you mean appendix E for troubleshooting hard fault?

Yes, the position of my screenshots is already in the hard fault, sorry that I didn't mention clearly.

I use LPCXpresso which is eclipse based and proposed to use by NXP for this µC. I don't know a window with call stack visible. I'd like to get some help analyzing the register values in hard fault handler.

E.g. pc is zero. What does that mean? 0x0 is _vStackTop of vector table.

As described in this guide

https://www.silabs.com/community/mcu/32-bit/knowledge-base.entry.html/2014/05/26/debug_a_hardfault-78gc

INVSTATE of CFSR 0x20000 is set to 1 as in my case. But when I switch to disassembler of the lr address I can't recognize any disbehavior.

I need to know what happened before. What would you propose as preferable way?

Hello Andy Neil

yes, I've got the Definitive Guide, but it's for Cortex M3 instead M4 in my case?

Do you mean appendix E for troubleshooting hard fault?

Yes, the position of my screenshots is already in the hard fault, sorry that I didn't mention clearly.

I use LPCXpresso which is eclipse based and proposed to use by NXP for this µC. I don't know a window with call stack visible. I'd like to get some help analyzing the register values in hard fault handler.

E.g. pc is zero. What does that mean? 0x0 is _vStackTop of vector table.

As described in this guide

https://www.silabs.com/community/mcu/32-bit/knowledge-base.entry.html/2014/05/26/debug_a_hardfault-78gc

INVSTATE of CFSR 0x20000 is set to 1 as in my case. But when I switch to disassembler of the lr address I can't recognize any disbehavior.

I need to know what happened before. What would you propose as preferable way?

Unknown said:

I've got the Definitive Guide, but it's for Cortex M3 instead M4 in my case?

So time to get the M4 edition, then!

But I think the Hard Fault handling is very similar between the two.

Unknown said:

I use LPCXpresso

So have you checked on NXP's forums to find out if it does have specific features to help you?

As I said, such things are pretty much standard - it seems unlikely that NXP would omit something so basic.

Unknown said:

I need to know what happened before.

If you can't work back from the information in the Hard Fault handler, then instrument your code to narrow down where the fault is happening.

Unknown said:

I don't know a window with call stack visible

https://www.nxp.com/design/microcontrollers-developer-resources/lpc-microcontroller-utilities/lpcxpresso-ide-v8-2-2:LPCXPRESSO?&tab=Documentation_Tab&linkline=Users-Guide

via

https://www.nxp.com/design/microcontrollers-developer-resources/lpc-microcontroller-utilities/lpcxpresso-ide-v8-2-2:LPCXPRESSO

If you got the paper copy of the book, it doesn't have the appendixes. Because the book is too big they moved the appendixes online on the companion website: https://booksite.elsevier.com/9780124080829/

From there you can download the appendixes: https://booksite.elsevier.com/9780124080829/appendices.php and the trouble shooting guide is appendix I: https://booksite.elsevier.com/9780124080829/downloads/APP-09.pdf

I haven't use NXP LPCXpresso for very very long time. However, if you can view the register window, you can see the LR (exception return), from there you can tell which stack pointer was used for exception stacking: If bit 2 of EXC_RETURN is 0, then check where MSP is pointed to. If it is 1, PSP was used for stacking.

Then locate the exception stack frame based on MSP/PSP, and look for the value of address offset 24 (decimal). This shows the PC value that was pushed to the stack.

You mentioned : <signal handler called>() at 0xfffffffd

I guess this is LR (EXC_RETURN) and is 0xfffffffd, so the fault is triggered in thread mode and was using PSP.

>What about CFSR=0x20000? (INVSTATE=1?)

As shown in appendix I of the book, the INVSTATE could be caused by:

1) Loading branch target address to PC with LSB equals zero.Stacked PC should show the branch target.

2) LSB of vector address in vector table is zero. Stacked PCshould show the starting of exception handler.

3) Stacked PSR corrupted during exception handling, so afterthe exception the core tries to return to the interrupted code inARM state

Combining with the stacked PC value, and disasseembly of the code, and the CFSR information, hopefully you can work out which of the causes mentioned above is the actual one.

Hope this helps.

regards,

Joseph

Hi Joseph Yiu

thanks for the information. After I activated the other fault possibilities with

SCB->SHCSR |= SCB_SHCSR_USGFAULTENA_Msk | SCB_SHCSR_BUSFAULTENA_Msk | SCB_SHCSR_MEMFAULTENA_Msk;

it hangs in UsageFault_Handler:

Does it mean, that HardFault_Handler() - call wasn't correct before?

Register values are (pc=0x00008128 is this function itself):

As you see lr is 0xFFFFFFFD which means PSP is used. At stack position 0x10008A08 of psp I see this

6th long word 0x00013421 seems to be valid flash address and I find in Disassembly:

Does it mean there's a problem with

Chip_CAN_Send(CANBUS_PERIPHERAL, CAN_BUFFER_1, pMsgObj);

call some lines above?

If yes, this function is called many many times and works solid before. How can I trigger this? (and what can I recognize when combining with CFSR INVSTATE=1?)

Regards,

Daniel

Hi Joseph Yiu

what is the correct stack frame layout?

In Cortex-M4 User Guide I find:

In case 7th byte is 0 I get a UsageFault with UFSR_INVSTATE=1, e.g.:

In case 7th byte is any other invalid address (this happens very rarely) I get a BusFault with BFSR_IBUSERR=1 (e.g. if PC is 0x14000000).

But you wrote the byte after PC, isn't that the 8th byte "xPSR" or what is the correct layout?

As you suggested I defined a global variable and set it to unique numbers in every interrupt: NVIC_ISER shows these enabled interrupts:

Enum LPC40XX_IRQn_Type in cmsis_40xx.h extracts it (set bits in ISER[0] and [1]) to these interrupts:

5: UART0_IRQn

10: I2C0_IRQn

22: ADC_IRQn

25: CAN_IRQn

26: DMA_IRQn

38: GPIO_IRQn

But what about these 3 FreeRTOS-Interrupts which are implemented, too?

#define vPortSVCHandler SVC_Handler
#define xPortPendSVHandler PendSV_Handler
#define xPortSysTickHandler SysTick_Handler

Everytime I get the UsageFault (or very rarely BusFault) my variable is set to 26 DMA_IRQn and PendSVHandler was used recently. I checked by a counting variable at begin and end of DMA_IRQHandler() and PendSVHandler() if there were run completely last time and yes, the counting-variables in DMA_IRQHandler() are the same. PendSVHandler() is a bit complecated because of the assembly code inside, the 2nd variable stays at 0.

What would you suggest, what could cause setting the stacked PC to 0? How can I check if possibly DMA_IRQHandler() some time has a stack corruption?

Is it correct that USFR=INVSTATE-Bit-Set is caused by corrupt stacked PC=0?

www.freertos.org/Stacks-and-stack-overflow-checking.html

Joseph Yiu Thank you for all the support. Fortunately I don't need to examine more of the ISR's, DMA handler etc. It's good to know to get support in this forum if I get similar errors in future.

www.freertos.org/FreeRTOS-MPU-memory-protection-unit.html

However, many FreeRTOS projects doesn't enable the MPU. Enabling the MPU require you to define the memory regions for each tasks (and share data variable) and the MPU region alignment requirements in Armv7-M make it a bit more complicated.  This is much easier to do in Armv8-M processors (e.g. Cortex-M23, Cortex-M33).

regards,

Joseph