2024-04-22 10:22 AM
This was a tricky bug to find. I am doing context switching. Everything seems to working well until a context switch happens while one of my tasks has called a different function. Specifically, HAL_GetTick(). To be clear the switch is happening while I am in HAL_GetTick(). As I am stepping through everything seems to be fine. The CONTROL register is in thread mode, PSP is pointing to the thread stack. MSP is pointing to my handler stack. LR is pointing to the area HAL_GetTick() was called from. Upon return to the task, PSP suddenly points to the MSP stack. The CONTROL register is still in thread mode and the code proceeds normally, but as soon as I call HAL_GetTick() again, a hard fault is thrown.
The fault doesn't happen if a context switch doesn't happen inside a function that the task has called.
Yes, I am disabling interrupts when entering the SysTick and PendSV interrupt routines.
I am running on a STM32 Nucleo-144
2024-04-22 04:56 PM
Use FreeRTOS or RMX or other available RTOS.
2024-05-06 02:47 PM
Neither. I am writing my own.
2024-09-18 09:36 AM
So I finding a more serious issue which may be related. My PendSV handler calls a context switch function (written in C) after it saves registers (written in assembly). I am finding that after a couple switches, that the xPSR T-bit is getting cleared right before returning to the PendSV handler. This, of course causes a hard fault. This should never happen. I don't know if it is in the code or is the debugger is causing it.