USB not working in hard fault handler

[Anand m]

I am trying to dump stack trace from hard fault handler using usb, but the usb not working in hardfault handler.

Any one please help me to know why usb not working in  hard fault handler, if there is a way to use usb in hard fault handler

[Imen.D]

Hello @Anand m ,

Can you please share more details on your issue? Which hardware using ?

Did you check registers? Are you able to breakpoint in hardfault?

Try increase stack size.

Imen

[waclawek.jan]

Hardfault is an interrupt of the highest priority. As USB runs using interrupts, those interrupts cannot be invoked until you leave the hardfault handler. Whether that's a good idea, is up to you to decide.

JW

[Anand m]

Thanks for your replay , i am just a beginner

I am using stm32L4 series, is there any way to run usb inside the hardfault handler

[Anand m]

Thanks for your replay , i am using stm32L4 series and i increased the stack size but it not working inside hard fault

which register i need to check?

[Anand m]

I am able to put break point inside hardfault handler

[waclawek.jan]

> is there any way to run usb inside the hardfault handler

Not really (the long answer is, that it's not impossible, but with effort which is far beyond reasonable and far beyond capabilities of not only beginners).

Also, hardfault means that something went wrong, and you don't know, what went wrong. So, you don't want to run anything complicated in the hardfault . And USB *is* very, very complicated.

Better way is to have simpler means to communicate, e.g. through UART. Best is to use a debugger connected through SWD, such as STLink.

JW

[Pavel A.]

Or even save the debug info to SRAM, then do software reset (SRAM usually survives it) and send it out early in your program.

[Tesla DeLorean]

As Jan points out this is a bit of a gross-failure, and shouldn't happen in a normal system. If you exit the Hard Fault Handler into something else, at that point the interrupts should work again. Unless say it failed inside a USB interrupt.

You can put in sanity checking for pointers, etc, and have those report prior to critical failure, or as Pavel suggests report post-failure then next time you come up.

More practically use a regular serial / uart to spit out failure statistics. Again probably not going to be able to use interrupts / buffering in the normal sense.