Hi.

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:

~~~~ volatile uint32_t blaa; for (blaa = 0; blaa < 0xFFFFFU; blaa++) {

    }
    for (;;)
    {
        if (pdTRUE == xTaskNotifyWait(0U, UINT32_MAX, &task_notify_value, portMAX_DELAY))

~~~~

This does not work:

~~~~ for (;;) { if (pdTRUE == xTaskNotifyWait(0U, UINT32MAX, &tasknotifyvalue, portMAXDELAY)) ~~~~ I am running FreeRTOS 8.2.0 on Texas Instruments TMS570LS033x

Thanks for any help in advance.

I think TI distribute their own FreeRTOS version that has MPU support - are you using that? Or the version from the FreeRTOS download without MPU support?

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.

Its difficult to support code that is created by a third party - but in general terms, I cannot think of any reason for the symptom you are reporting - and have not heard of it before.

Task notifications are a relatively new feature, so is it possible they have not added MPU support for them?

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?

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 :)