FreeRTOS Support Archive

The FreeRTOS support forum can be used for active support both from Amazon Web Services
and the community. In return for using our software for
free, we request you play fair and do your bit to help others! Sign up
to receive notifications of new support topics then help where you can.

This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.

xTaskNotifyWait hangs all tasks

I have an issue with xTaskNotifyWait if using xTicksToWait parameter with value different than 0. If I set the time to wait to non 0 value the RTOS gets stuck in vPortEnterCritical (according to what I can see from debuging). However, the issue seems to be more complicated than that. It seems that the problem occurs only when the xTaskNotifyWait is called at a specific time after the vTaskStartScheduler is started.I am using the xTaskNotifyWait with non 0 wait value. However, only in one specific tasks it causes the RTOS to get stuck. Furthermore, I can actually avoid this issue by putting some artificial loop that eats some CPU cycles away before xTaskNotifyWait is called.
Meaning:
This does work:

xTaskNotifyWait hangs all tasks

We are using a "hybrid" of both since TI does not have FreeRTOS version for the specific MCU model and their RTOS versions are fairly outdated.
This is the first time when we have run into such problem.

xTaskNotifyWait hangs all tasks

The behaviour seems really weird taking into account that it works in some places and does not work in others. Maybe you might have some rough guess what might be causing the issue or how we could try to track it down?

xTaskNotifyWait hangs all tasks

Managed to fix this myself. Just FYI if someone runs into a similar problem:
We were using older version of portASM and how portENTERCRITICAL() is used. chaging portENTERCRITICAL and portDISABLE_INTERRUPTS to map into SWIs in the new portASM file did the trick. TI seems to have updated their HALCoGen files :)