Hi @richard-damon and @RAc
I did a bit more digging into the task’s ‘boot-up delay’ I mentioned.
First, I removed the delays from the relevant tasks and then I started a debug session.
The system doesn’t run past a certain point (when it enters a task that used to have a delay for the first time, I believe).
Here is the full call stack:
The debugger always stops me here in port.c (I started and stopped the processor a few times):
If I step one level up, I see my task:
Another level up:
Another level up shows that it is waiting on taskEXIT_CRITICAL():
Another level up shows it hasn’t exited vPortExitCritical():
The second last reference has no source code to refer to:
And then the final level on the call stack is a completely unrelated General Purpose Timer interrupt handler (used for FreeRTOS Runtime stats):
Update: I’ve paused it a few more times, and it always lands at the same place in pxPortInitialiseStack(). Sometimes the functions ‘higher’ in the call stack are different, but GPT2_IRQHandler() is always the highest function on the call stack, so this is probably where the issue lies?
Here is how the GPT2_IRQHandler() is set up:
And here’s what the related portion in FreeRTOSConfig.h looks like:
Please let me know if you have suggestions for what I should do next.