xTaskNotifyWait hangs all tasks

ringolds wrote on Thursday, December 10, 2015:

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, UINT32_MAX, &task_notify_value, portMAX_DELAY))

I am running FreeRTOS 8.2.0 on Texas Instruments TMS570LS033x

Thanks for any help in advance.

rtel wrote on Thursday, December 10, 2015:

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?

ringolds wrote on Thursday, December 10, 2015:

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.

rtel wrote on Thursday, December 10, 2015:

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?

ringolds wrote on Thursday, December 10, 2015:

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?

ringolds wrote on Friday, December 11, 2015:

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