Hello, I’m trying to port FreeRTOS (V8.0.0:rc2) on PPC. The OS starts and I’m able to reach the higher priority task (the first one it find). Unfortunately it seems that it continuosly loops inside and no other task is executed. When the tick interrupt occurs, the scheduler start again the same task. Do you have hints to solve this behavior? Regards, Pippo

I’m afraid there are just too many things to suggest that could be the cause, so I would recommend building up your port one step at a time. The first thing to do would be get two tasks yielding to each other, and check that works correctly. Don’t use or even configure a tick interrupt at that point. Once you have two tasks that can call taskYIELD() to alternate their execution, then start to think about how to generate and process the tick interrupt. The code that selects which task to run is outside of your port layer, and that is known to be functionally correct (as far as can be ascertained – the same code is run with more than 30 ports anyway) so if you are getting the same task selected all the time then the problem is almost certainly in the port code. Regards.

I’ve done the trial you suggest. Task1 and Task2 with same prio. Scheduler starts Task1…then a taskYIELD() is called. At this time Task2 executes…but even if a taskYIELD() (inside task2) is called…there is no chance to switch back on Task1 again…. …investigation on going… Regards

Hello, taskYIELD() works properly!!! I’ve discovered the problem…I haven’t any scheduling!! The tick interrupt doesn’t work because the irqs are disabled by the vTaskEnterCritical and not correctly re-enabled by the vTaskExitCritical when the xTaskCreate is called (note that at this point the scheduler doesn’t run). The sequence is: xTaskCreate(…)_ vTaskStartScheduler(); Below I’ve copied the two functions:

if ( portCRITICALNESTINGIN_TCB == 1 )

void vTaskEnterCritical( void )
{
    portDISABLE_INTERRUPTS();

    if( xSchedulerRunning != pdFALSE )
    {
        ( pxCurrentTCB->uxCriticalNesting )++;
    }
    else
    {
        mtCOVERAGE_TEST_MARKER();
    }
}

endif /* portCRITICALNESTINGIN_TCB */

/———————————————————–/

if ( portCRITICALNESTINGIN_TCB == 1 )

void vTaskExitCritical( void )
{
    if( xSchedulerRunning != pdFALSE )
    {
        if( pxCurrentTCB->uxCriticalNesting > 0U )
        {
            ( pxCurrentTCB->uxCriticalNesting )--;

            if( pxCurrentTCB->uxCriticalNesting == 0U )
            {
                portENABLE_INTERRUPTS();
            }
            else
            {
                mtCOVERAGE_TEST_MARKER();
            }
        }
        else
        {
            mtCOVERAGE_TEST_MARKER();
        }
    }
    else
    {
        mtCOVERAGE_TEST_MARKER();
    }
}

endif /* portCRITICALNESTINGIN_TCB */

It’s clear that with the scheduler off, none will execute the portENABLE_INTERRUPTS() macro. is it correct?? Of course, if I insert this macro into the xPortStartScheduler inside the port.c, it works properly. I think this is the non correct way…(I force an enable…) Do you think I have a problem somewhere into my portable code (or some wrong define) or I’ve discovered a little bug?? Regards, Pippo

Really, I also find a portDISABLE_INTERRUPTS() into vTaskStartScheduler before xPortStartScheduler function is called. So that, it is seems that before the call to the vPortStartFirstTask(), a portENABLE_INTERRUPTS must be invoked (into the portable section). Do I have understood well? Please help me 🙂 Regards, Pippo

Your port layer should create an initial stack that contains a complete context for each task. Part of that context is the interrupt state, which should be set to enabled. Then when you restore the initial context of the task interrupt get enabled automatically. You definitely don’t want to change any of the other interrupt enable/disable code as FreeRTOS keeps interrupts disabled between starting to create tasks and starting the scheduler.

yes you’re right… I’m able to start task2…then it switch to task1…but it remains looped…and no other ticks

yes you’re right… I’m able to start task2…then it switch to task1…but it remains looped…and no other ticks

Solved!! The problem was on my ISR handler.