Hardfault During Interrupt

[karahulx (RAHUL KAR)]

Cortex-M MCUs have a main stack (MSP register) and a process stack (PSP register). The latter is used for tasks stack managed by FreeRTOS. The main stack is used by ISRs.
You create the USBDriver instance on the main stack and start FreeRTOS.
Hence the object living in the main stack might and likely will be corrupted as soon as an ISR runs.

Hence make the instances e.g. global or static as mentioned before to avoid their corruption.

Edit. This is also found multiple times in the forum and few instances here:

Main stack pointer reset when starting the scheduler

rtel wrote on Friday, January 02, 2015: It has always been done this way, and is especially important on devices which only have a few K of RAM. I think the original Cortex-M ports were created on devices with 2K or RAM, in which case it was extremely important to re-use all the RAM that was not intended to be used after the scheduler has started. Once the scheduler has started main() no longer exists. There is no way back to it and no way of [directly] referencing memory on its stack [which…

M4 port stack corruption

Here are few ideas to start off with: Are you sure your interrupt can complete in the shorter time allotted when the rate increases to 500Hz (would have thought so, but worth asking). The Cortex-M ports re-use the stack that was allocated to the main() function as the interrupt stack once the scheduler has been started. That means the size of the interrupt stack is set by your project’s linker options, so the kernel has no [easy] way of knowing if it overflows. If you faster interrupt ra…