I’m having an issue where one of my task is still considered as blocked by the scheduler even if the event it’s waiting on has been set, from an ISR (then the timer service).
Here is an image summarising the happy path and the failure when it happens.
The Timer Service has the highest priority, and actually we can see it is doing what is expected. What I don’t understand is why the task will not be unblocked after the event it’s waiting on is set. Is there any configuration I could have missed?
Grateful if you can confirm a few things for me so we can help you with this issue.
Your post shows a trace that is working correctly and a trace that is working incorrectly. Am I right in concluding then that the issue you report does not happen every time, but just occassionally?
Which microcontroller and compiler are you using, including the compiler version.
Is there anything unusual about your system, such as are you using tickless idling, or a C++ wrapper?
Your post shows a trace that is working correctly and a trace that is working incorrectly. Am I right in concluding then that the issue you report does not happen every time, but just occassionally?
Yes indeed, the issue doesn’t happen everytime. It usually happens within 5 to 60 seconds, with this sequence happening 8 times per second.
Which microcontroller and compiler are you using, including the compiler version.
The problem never occurred after fixing the interrupt priority issues, thanks again!
For somebody dealing with the same issue:
I’ve defined config assert with the following:
#define configASSERT(x) if (0 == (x)) for(;;){}
The assert triggered straight away: the priority number allocated to my application ISR was too low (higher urgency), using a debugger I could see it hanging there:
Yes, you get corruption because you break the critical sections used in the code to protect updates from getting interrupt by something else that is updating something related. Which is bad, and very random.