MCUXpresso IDE interfering with hardfault debugging?

[davenadler]

I'm trying to debug a hardfault.
When the fault occurs, two things happen:

• the very pretty hardfault window pops up in the IDE, but it doesn't actually show where the fault occurred (not so helpful), and
• the breakpoint I have set on my hardfault handler first line is encountered, and the debug window shows program stopped at the breakpoint.

However, I can't step into my code (which finds the correct stack pointer, then the instruction area where the fault happened). If I try to single-step into my (assembler) code, it doesn't work (IDE/debugger get confused and show 0xdeadbee and so on).

How can I make MCUXpresso allow my fault handler to actually execute?

Thanks!
Best Regards, Dave

PS: A complete example which will hardfault promptly (for LPC55S28-EVK) is now attached.

[Alice_Yang]

Hello davenadler,

Could you please give more information , which chip or board ? What about your project? How about a simple project ?

Regards,

Alice

[davenadler]

@Alice_Yang- The question is not specific to any particular part.

I have attached a complete example project above.

[Alice_Yang]

Hello davnadler,

There is fault information in "Faults" view:

The processor jumps to this fault when various bad things happen that it can't handle.

Read "Cortex M33 Devices Generic User Guide" from ARM, the chapter on Fault Handling.

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

Regards,

Alice

[scottm]

Hi Alice,

I'm reviving this thread because I'm having the same problem Dave is and I don't think it really got answered.

There's been a lot of hardfault troubleshooting advice over the years, including a lot of passing the buck to the ARM documentation, and some useful links to Erich's blog, but with the addition of the (relatively) new 'faults' view in MCUXpresso it's hard to sort out which advice is current and relevant.

I'm attaching a screenshot of what I get when there's any hardfault. I don't remember where this fault handler code came from; I think it was the ARM documentation. But as you can see, the faults view shows "No faults", PC shows the current position in the hardfault handler, and the only way I see to get any information out of it is to step through until I get to the C portion where it copies out the fault arguments - and then I've got to inspect PC and plug that value into the disassembly view to see where the fault happened.

What is the sequence supposed to look like? Keeping in mind that I've already read the generic ARM documentation. MCUX's fault handling is of course not documented there.

Why is it the start of the hardfault handler that the IDE stops on? Why does the IDE seem to not know that it's looking at a fault? If it doesn't know there's a fault, why did it stop there?

Thanks,

Scott

 

[ErichStyger]

Hi Scott,

What the IDE hard fault handler exactly does is not clear to me. In my understanding it reads the ARM registers similar to what probably your hard fault handler does too, but just displaying the information in a nice way.

In maybe 20% of the hardfaults I get that view is helpful, otherwise it does not show much information. Still, better than nothing for someone who does not have a hardfault handler installed like the one I discussed in Debugging Hard Faults on ARM Cortex-M | MCU on Eclipse.

So here is what I do to deal with hard faults:

- having custom hardfault handler installed. I'm using the one from https://github.com/ErichStyger/McuOnEclipseLibrary/blob/master/lib/src/McuHardFault.c

- if a fault happens, the handler shows PC and LR. In 80% of the cases either the PC or LR is pointing near the location where the problem is.

- this does not help much, I recommend to turn on McuHardFault_CONFIG_SETTING_DISABLE_WRITE_BUFFER which disables the write fault. Above handler code/module has a setting for it. See as well Debugging ARM Cortex-M0+ HardFaults | MCU on Eclipse for that topic of 'imprecise faults'

- in many cases the call chain in the debugger gives some ideas. In your screenshot I see it seems to be caused by your 'Audio' task: I would set a breakpoint at the beginning of the task and then step through the code to narrow down the area where it happens.

I hope this helps & good luck!

Erich