Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training




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 ]    [ Sitemap ]    [ ]




Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

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

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

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

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists