cancel
Showing results for 
Search instead for 
Did you mean: 

How can I analyze the reason of a randomly called HardFault_Handler()

RockfordC64
Associate II

Hello Community,

I have a STM32L051R6T6 CortexM0+ MCU on an customer Board and I#m developing an application for it in CubeIDE and C++, using HAL-Driverlib. It's reading from 2 UARTS by interrupt, verifying the data, converts it to telegram-objects and puts them into an queue. The main cycle processes both queues (which are pointer arrays for my telegram-objects) and logs the actual status to a LPUART.

Randomly my app runs into HardFault_Handler(). When I enlarge the heap, it seem to happen a little bit later. When I look into the call stack, the HardFault is signaled in a new or a delete operation (different ones, not the same everytime). So it looks like I have a memory leak or something similar.

I triple checked my code, added counters for new and delete([]) operators. I cant find any problem. Allocated memory is freed again.

It would be nice, if I could ask somehow for the actual allocated heap size, to be more sure, that I dont run out of heap memory.

I also tried to use CubeProgrammer, because it has got an Hard fault detection and analyzer. Loaded the same elf file to MCU, (Also looked for SCB->CCR register because of SCB_CCR_UNALIGN_TRP Flag. IDE says its on, CubeProgrammer says its of with the same elf file running). But the Hard fault detection doesnt trigger, when the Hard fault happens (I know this because of the logging and a LED on the board). So maybe I'm using it wrong.

Is there a way to analyze the Hardfault_Handler in CubeIDE. What information can I read from the registers or other statuses ? Is there a way to debug the memory better, like I know from Microsofts magic numbers in debug mode?

Or should I leave from using std-classes (std::string and std::queue at the moment)?

10 REPLIES 10
ONadr.1
Senior III

PavelA has right. If I have so small amount of memory, I use pure C and dont use dynamical memory alocation. It cause, that code isnt so clear, but can run for years without memory fragmentation problems. It's something for something .....