Hardfault During Interrupt

[hryan]

Good Morning,

I wanted to post this on the off chance it helps a neophyte like me dealing with the same problem. My main method looks something like this:

int main() {
USBDriver usb();
// Make some tasks
vTaskStartScheduler();
}

usb responds to interrupts and buffers the results into circular buffers. A task polls these buffers periodically. After the scheduler starts, one of these interrupts fires and a INVSTATE hard fault gets thrown.

Investigating the problem, I first suspected something with the interrupts. No luck. Then I noticed that parts of the usb object were becoming corrupted. Finally, I landed on the forum post below: (can’t link it, but you should be able to search with the partial)

freertos_Main_stack_pointer_reset_when_starting_the_scheduler_e5a776c1j.html

Essentially, it looks like FreeRTOS reclaims the main stack when it starts up (at least on the M3 and M4 cortex ports, probably others too).

Watch out,
Hill

[richard-damon]

Yep, that is a documented part of the Cortex-Mx ports. (and perhaps some other ports), the “main” stack is reset and reused as the ISR stack, so your setup code should not put objects on the main stack. Make the static or global objects.

[hryan]

Hi Richard,

Thanks for adding some context. I am probably blind, but where is this documented? I’d like to check there in case there are some other things I missed.

Best Wishes,
Hill

[richard-damon]

I would need to search for it again, but I think it is in the port itself. There may be a page on this, but it is a common topic on the forum.

[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…

[hs2 (Hartmut Schaefer)]

And see FreeRTOS FAQ My application does not run, what could be wrong?
3. main() stack

[hryan]

This is great. Thank you for the additional information. I focused mainly on the Debugging Hard Fault & Other Exceptions page and the Running the RTOS on a ARM Cortex-M Core page when I was trying to debug this. I humbly suggest that 3. mentioned by hs2 be added to the debugging hard fault page.