STM32 gets stuck in HardFault_Handler loop

I am working on developing a custom version of the hardware using the same STM32F405 but also using the DRV8323.

I had gotten everything working nicely using the V4 firmware. I’ve migrated to RC0.5.1 and managed to also get the system work with 2x drv boards and the stm32.

The problem is if I try to use just the STM32 with no drv boards attached (something that makes testing of the hardware easier).

If I flash, it succeeds, and then I try to access the odrivetool via the native usb interface. It locks up on simple commands like odrv0.

I’ve gone into the debugger in VSCode and the problem seems to be with the vTaskDelete() at the end of odrive_main().

Once this is called, the system seems to hard fault (it is getting stuck in the get_regs while(stay_looping).

Commenting this out showed an issue with uxTaskGetStackHighWaterMark().

I’m unable to decipher what is happening. I’ve also tried setting the axis_count to 0 without any effect.

I’m hoping you can help me figure out what is causing this to happen so I can continue my debugging.

Thanks in advance,
Matt

after a long search, I believe that the issue was caused by optimizations. Modifying tupfile.lua to always use -O0 seems to have solved the bug.

Lines 143 and 145

Found the idea from: STM32F100RCT MCU + STM32CubeMX project: prvPortStartFirstTask() crash - FreeRTOS

Hmm. Was it using -fLTO? Because -O3 shouldn’t cause any issues but LTO can.

No, -Og (for debug) and -O2 w/o debug
(forked from the 0_5_1 Release from sept 2020)

Hi…Perhaps you get an interfere with bit that you have accidentaly designed as empowered, however don’t have a controller for in your ISR. So your code may function admirably until you get an equality blunder or an outlining mistake or invade or a FIFO flood or comparable. So all works out in a good way until you either get some misleading commotion on the sequential information lines or you get a CPU top that causes you to bomb your continuous prerequisites.

Hi Jens,

I went back through my code and re-built it up from the 0.5.1 release. I think I had one of the structs incorrectly initialized/defined (leading to some sort of null pointer). Now I’m able to build using the default optimization settings.

All seems to be aOK!