New to this forum, hi all!
xTaskNotifyWait does not suspend the calling task, but returns immediately with timeout, although timeout is set to portMAX_DELAY.
This appeared recently and it is the first time I experience that. My application is 2 years old, always worked and remained unchanged. I just recompiled (updated toolchain) and → boom.
STMCubeMX, STMCudeIDE, STLINK debugger.
Any ideas?
XTaskNotify doesn’t take a timeout parameter and isn’t defined to block for anything. What makes you think it should?
If the notified task has a higher priority than the notifying task (and it was waiting for that notification) the system should switch to it, but otherwise xTaskNotify is SUPPOSED to just return and the task continue.
Sorry, typo, xTaskNotifyWait of course. Changed the title.
Perhaps something has previously notified the task and that notification is still pending? You may want to clear any pending notifications by first doing a wait with a 0 block time. Maybe you have a race condition.
I already do this. Stepping thru the FreeRTOS code shows there are no notifications pending. prvAddCurrentTaskToDelayedList is executed as well as vListInsertEnd therein. portYIELD_WITHIN_API(); is called thereafter. All looks fine, but xTaskNotifiyWait then proceedes and returns false.
Btw, I forgot: STM32L4
Can you put a breakpoint at PendSV Handler and verify that the control switches to PendSV Handler when portYIELD_WITHIN_API(); is called? Is it possible that interrupts are disabled somehow? Do you have configASSERT defined?
You can also try disabling/commenting out parts of the functionality to find out the problematic part of code.
xPortPendSVHandler is never executed. I deliberately enabled interrupts for a test (portENABLE_INTERRUPTS()), configASSERT is defined and 1.
I hoped there was something known so I do not have to get into the painful stuff (commenting out etc…).
You aren’t in a critical section are you?
I’ve used FreeRTOS on similar parts with no problem
configASSERT is not a flag and must be defined as code.
See the documentation also for useful examples.
I know. Mixed it up with configASSERT_DEFINED. configASSERT is defined, disables interrupts amd loops forever.
No, I’m not.
Me too, that’s why I am gobsmacked. There is something going on. Unfortunedly I am by no means a RTOS expert and NVIC is a nightmare to me.
vPortEnterCritical and vPortExitCritical are nicely paired to a certain point where vPortEnterCritical is never called again.
Btw, I noticed uxCriticalNesting is alternating between 0xaaaaaaaa and 0xaaaaaaab.
Is that ok?
That does not seem okay and seems like a memory corruption. You can define a variable right next to uxCriticalNesting and set a data breakpoint on that. Chances are that that corruption is more than just uxCriticalNesting and you’ll be able to catch it right when it happens.
That’s what I thought, too. But then I checked the code, it is initialized to 0xaaaaaaaa.
Ok, guys, thanks for your effort so far.
I will do some more debugging and RTOS reverse-engineering to get a feel of that all.
I’ll turn back to the forum after that.
Thanks again!
But gets set to zero when the scheduler is started could there have been an issue starting the scheduler?
You are genius. The scheduler was not started yet. Don’t ask why, the answer is too embarassing. But I learned a thing or two in the process.
Thanks.
Let’s just say you aren’t the first to make that mistake. 
Sigh But I thought, after all those years, I would do better 
I still sometimes curse at not being able to program a dev board, only to later realise I hadn’t turned it on, especially if moving from hardware that took power from the debug interface.