Event not waking up a Task after being set from an ISR

Hello,

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?

The FreeRTOS version used is 10.3.1.

Thanks in advance

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?

Sure.

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.

Microcontroller: STM32L4A6ZG
Compiler: gcc-arm-none-eabi-6-2017-q2-update-win32

Is there anything unusual about your system, such as are you using tickless idling, or a C++ wrapper?

No C++ wrapper. Tickless idle is planned but not used just yet as well.

Thanks

Do you have configAssert defined to catch interrupt priority issues, and stack checking turned on? those can cause some intermittent issues.

Do you have configAssert defined to catch interrupt priority issues, and stack checking turned on? those can cause some intermittent issues.

configAssert isn’t turned on.

configCHECK_FOR_STACK_OVERFLOW is set to 2, is that what you referenced?

If configAssert isn’t enabled, you could have an interrupt priority (or some other) issue that is corrupting the kernel’s data.

Yes, configCHECK_FOR_STACK_OVERFLOW 2 was the sort of stack checking I was referring to.

There seem to be interrupt priority issues going on, thanks for your help. I’ll go through them before anything else.

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:

I’ve changed the priority so it has a higher number (so less urgent) than ucMaxSysCallPriority, and the issue never showed up again.

According to richard-damon the problem would have corrupted the kernel’s data and triggered the issues reported.

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.

1 Like