Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem


Loading

Porting problem: It's scheduled always the same task

Posted by pippopappo0 on February 11, 2014

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


Porting problem: It's scheduled always the same task

Posted by rtel on February 11, 2014

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.


Porting problem: It's scheduled always the same task

Posted by pippopappo0 on February 11, 2014

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


Porting problem: It's scheduled always the same task

Posted by pippopappo0 on February 17, 2014

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


Porting problem: It's scheduled always the same task

Posted by pippopappo0 on February 17, 2014

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


Porting problem: It's scheduled always the same task

Posted by davedoors on February 17, 2014

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.


Porting problem: It's scheduled always the same task

Posted by pippopappo0 on February 17, 2014

yes you're right...

I'm able to start task2...then it switch to task1...but it remains looped...and no other ticks


Porting problem: It's scheduled always the same task

Posted by pippopappo0 on February 17, 2014

yes you're right...

I'm able to start task2...then it switch to task1...but it remains looped...and no other ticks


Porting problem: It's scheduled always the same task

Posted by pippopappo0 on February 20, 2014

Solved!!

The problem was on my ISR handler.


[ Back to the top ]    [ About FreeRTOS ]    [ Privacy ]    [ Sitemap ]    [ ]


Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

NXP tweet showing LPC5500 (ARMv8-M Cortex-M33) running FreeRTOS.

Meet Richard Barry and learn about running FreeRTOS on RISC-V at FOSDEM 2019

Version 10.1.1 of the FreeRTOS kernel is available for immediate download. MIT licensed.

View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.


Careers

FreeRTOS and other embedded software careers at AWS.



FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Espressif ESP32

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Renesas

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS

Xilinx Microblaze and Zynq partner