taskYIELD not working from Idle Task

Kernel
,
1

Hi ,
I have recently ported my source code from STM32f407z to STM32F469II. I am seeing some unusual behaviour as my code is stuck in the idle task at

       #if ( ( configUSE_PREEMPTION == 1 ) && ( configIDLE_SHOULD_YIELD == 1 ) )
        {
            /* When using preemption tasks of equal priority will be
             * timesliced.  If a task that is sharing the idle priority is ready
             * to run then the idle task should yield before the end of the
             * timeslice.
             *
             * A critical region is not required here as we are just reading from
             * the list, and an occasional incorrect value will not matter.  If
             * the ready list at the idle priority contains one more task than the
             * number of idle tasks, which is equal to the configured numbers of cores
             * then a task other than the idle task is ready to execute. */
            if( listCURRENT_LIST_LENGTH( &( pxReadyTasksLists[ tskIDLE_PRIORITY ] ) ) > ( UBaseType_t ) configNUMBER_OF_CORES )
            {
                taskYIELD();
            }
            else
            {
                mtCOVERAGE_TEST_MARKER();
            }
        }

It looks like it is not able to yield the idle task.
Otherwise, it is stuck at:

static void prvCheckTasksWaitingTermination( void )
{
    /** THIS FUNCTION IS CALLED FROM THE RTOS IDLE TASK **/

    #if ( INCLUDE_vTaskDelete == 1 )
    {
        TCB_t * pxTCB;

        /* uxDeletedTasksWaitingCleanUp is used to prevent taskENTER_CRITICAL()
         * being called too often in the idle task. */
        while( uxDeletedTasksWaitingCleanUp > ( UBaseType_t ) 0U )

I have referred many forum posts regarding this issue and tried different things.
I am not using tickless IDLE and have enable pre-emption and yield from Freertosconfig.h
Here’s my config files for reference.
Also, to mention I am running HTTPS client on Ethernet. and ran into hard fault a few times before in the EMAC task. after changing priority and stack size I was able to overcome that.
But what should be the Idea priority for network tasks?

FreeRTOSConfig.h (5.8 KB)
FreeRTOSIPConfig.h (23.1 KB)

2

One possible reason is memory corruption.

Usually EMAC task is run at a higher priority than the application tasks and IP task.

Can you try to disable parts of your application in order to isolate the problematic part?

3

To add to Gaurav’s answer above, the priority of the EMAC task should be like so:
priority(EMAC task) > priority(IP task) > priority(application task).

@ashvajit were you able to step through the code to figure out which statement is exactly causing the issue? If you have debugger in the system, you should give that a try so that we can get more information and help you further.

Thanks

4

To add to Gaurav’s answer above, the priority of the EMAC task should be like so:
priority(EMAC task) > priority(IP task) > priority(application task).

I always like to emphasise that all other tasks are free to run at any priority. Provided that higher-priority tasks don’t occupy the CPU for long periods of time.

5

I have isolated all of the task and found out that it was due to my HTTPs task it was the problem.
I have increased stack size and after that it was not stuck anymore.
Also, I have changed my task priorities according to your recommendation,
with #define configMAX_PRIORITIES (12)
I have kept

#define  ipconfigIP_TASK_PRIORITY			9
#define  niEMAC_HANDLER_TASK_PRIORITY		10

#define RTOS_System_Priority        5
#define RTOS_FS_Priority            7
#define RTOS_HTTPS_Priorty          8
#define RTOS_LED_Priority           4
#define RTOS_SOUNDER_Priority       4
#define RTOS_MONITOR_Priority       5
#define RTOS_PROXIMITY_Priority     6
#define RTOS_CALIBRATION_Priorty    8
#define RTOS_COMMUNICATION_Priority 5

I am not observing any issues since then.

Thanks, :smiley:

6

That assignment is ok if network throughput is the primary concern of the system. However, a side effect of this setup is that high network activity (deliberately adverse as in, for example, DoS attacks or designed, for example in network management systems that attempt to reach all nodes in a subnet frequently via ARP requests) may starve the rest of the system.

When I worked in security, some systems would fail certification because, say, a door controller could not make an offline access decision for being starved by the network. In such systems, it may be the lesser evil to starve the network in favor of functionality and thus put the priority of network related tasks below some application tasks (in rare cases that may even be tasks that perform network communication).

2 Likes