Task never called

Kernel
1

Hi,
I am trying to port the CORTEX_R4_RM48_TMS570_CCS5 demo to another TI processor (AWR1642, which is also an R4 ). Further more, I am using the most recent TI compiler (TLS 18.12.14).

I now have the Scheduler running (I call xTaskGetSchedulerState in the TickHook. The Scheduler state is switching between Suspended and Running). The Timer Interrupt is also running (xTickCount is incrementing). But the Sender and Receiver Tasks out of the basic “Blinky” Example are never called. I added a Handle for those tasks and the ucNotifyState is always 0.
I tried increasing the heap and stack, nothing changed.
pxCurrentTCB is always “TMR SVC”…
Can anyone point me in the right direction?

2

It is common for the timer service task to have the highest priority in the system (configMAX_PRIORITIES - 1), and so be the first task to start - but it should soon see it has nothing to do and block, yielding to the next task.

For now I would recommend starting with something even simpler. Set configUSE_TIMERS to 0 in FreeRTOSConfig.h so the timer task doesn’t start, and configUSE_TIME_SLICING to 0 so the tick interrupt does not cause the tasks to switch. Then create two tasks as follows:

volatile uint32_t ulTask1Count = 0;
volatile uint32_t ulTask2Count = 0;

void vTask1( void *pv )
{
	for( ;; )
	{
		ulTask1Count++;
		taskYIELD();
	}
}

void vTask2( void *pv )
{
	for( ;; )
	{
		ulTask2Count++;
		taskYIELD();
	}
}

Create the tasks at priority 1 so the Idle task doesn’t run either.

Now put a break point at the top of each task and start the scheduler.

Each task should perform one increment of their variable, then yield to the other task. You can step through the Yield function to see what it does to get more information, then report back if need be.

Once you have the yields working you can remove the call to taskYIELD() from each task and set configUSE_TIME_SLICING to 1 - then both tasks should still run but switch from one to the other in the tick interrupt rather than by manually yielding to each other.

After that you should have manual yielding and yielding in the interrupt tested in isolation of each other.

3

Hi Richard,
thanks a lot a for your help. I followed your steps exactly and all worked nicely. Both Task Counters are incrementing in all steps.
Than I went back to configUSE_TIMERS set to one with those 2 tasks and the behavior is again as descriped in my first post.
But: Your comment that the timer task often has the highest priority I did some experiments with that.
configTIMER_TASK_PRIORITY = 1, Task1 and Task2 = 2: Tasks are executed, but I think not the timer (CurrentTCB is always Task1 or Task2)
With all priorities set to 2: Task1 and Task2 are executed once, than no more. CurrentTCB is IDLE
configTIMER_TASK_PRIORITY = 4, , Task1 and Task2 = 2: Tasks are never executed, CurrentTCB is TMR SVC

4

Could it be that the stack for the Timer Service task is to small and it is crashing the system? or maybe something is misconfigured and it is hitting an assert?

5

I have defined configASSERT and it is never hit, neither are vApplicationMallocFailedHook and vApplicationStackOverflowHook. I also watched the Stacks manually for each mode and they are large enough

I have one more observation (Tmr SVC with highest priority, Task1 and Task2 at same priority):
I created a Software Timer (with the example given in https://www.freertos.org/FreeRTOS-timers-xTimerCreate.html ) with a period of X. No tasks are called until X (i can see that xNextTaskUnblockTime is X) is reached for the first time. After X, all tasks are working as expected (xNextTaskUnblockTime is < X, with the period of the tasks i configured). If the timer has deactivated the reload functionality, again no tasks are called.

How is it possible that a Software Timer is necessary for tasks not relying on a Software Timer?

6

After getting more familiar with our processor, the problem became obvious and I must ask myself why this wasnt checked before:
The portYIELD_WITHIN_API() macro and vPortYeildWithinAPI interrupt function needed to be implemented differently as the regarding registers and their behavior changed.