I'm working with FreeRTOS 7.5.3 on a RZ A1 (Renesas, ARM Cortex A9 core). I'm working with configUSE_PREEMPTION 1 . After some times (it can be 5 sec or 30 min), only the idle task is running. I've looked in tasks.c file and in xTaskIncrementTick() function, the value xNextTaskUnblockedTime is OxFFFFFFFF and is never set again. vTaskSwitchContext() is never called again. I don't get why this is happening. Thank you to let me know if someone have any idea from what it can be.

Which compiler are you using? Is it an official port?

One possibility is a simple deadlock in your application - where every task is waiting indefinitely for another task that is in turn waiting indefinitely for something else. Other than that...have you read the "my application does not run what could be wrong" page of the FAQ, which will cover things such as:

Do you have configASSERT() defined to trap common errors (can't remember what is covered by the RZ port)?

Do you have the malloc failed hook defined (in case of memory leak)?

Do you have stack overflow checking turned on.

Most importantly - Are you sure all your interrupts that are using the FreeRTOS API have a priority below the maximum API call interrupt priority?

Regards.

The tasks are not waiting for each other. configASSERT is defined as recommended by FreeRTOS. There is no memory leak. There is no stack overflow detected either. The priority are fine . And yes, it's an official port.

We need to determine where the tasks are and may be able to use an IDE plug-in for that. Which IDE are you using?

Regards.

I currently use DS-5, but on this version, there is no plug-in for FreeRTOS, Renesas provide the IDE E2Studio which has the Stateviewer plug-in by Wittenstein, but when the tasks stop and only the idle task is running, the stateviewer stop to update itself. When I watch for the global variables (used by FreeRTOS), all the task are in DelayedTaskList (exept of the idle task which is in the ReadyTaskList).

Regards

DS-5 does have a FreeRTOS plug-in, which was created by ARM themselves. I believe it ships as standard with DS-5.

If all the tasks are in the delayed lists can you determine which call placed them in the delayed list? If the next unblock time is set to 0xffffffff then it was presumably a blocking function call (such as an attempt to receive from a queue, or an attempt to read from a semaphore) that had an infinite block time (portMAX_DELAY).

Regards.