“1. My first task is running properly. But context switch is not happening even though I have given vTaskDelay in the first task.
When I give higher prority to the second task, that task is getting executed continuously and it is not context switching to the first task. Please note that #define configUSE_PREEMPTION is set as 1 for me and I'm using the interrupt vector table auto-genrated by codewarrior.
Context switching happens in two ways, from an interrupt (like the tick interrupt) and when a task yields. Calling vTaskDelay() will cause the task to yeild internally within the delay function. You have verified that your task is starting to run, but have you verified that the context of the task is correct when it starts to run, and have you verified that your yield implementation is working?
Start without using any API functions and configUSE_PREEMPTION set to 0. Then have two tasks that have the following structure:
volatile uint32_t ulVar1 = 0, ulVar2 = 0;
void vTask1( void *pvParameters )
for( ;; )
void vTask2( void *pvParameters )
for( ;; )
Running this code without preemption should show ulVar1 and ulVar2 being incremented at the same rate as the two tasks yield to each other.
Once you have that running correctly you can add in the API calls.
“2. Inside the vTaskIncrementTick() function, first time it is going to the ++xTickCount; section and it is getting incremented, but from the next interrupt it is always going to the ++uxMissedTicks; section of the code.
That would imply that uxSchedulerSuspended was non zero, but your code is not suspending the scheduler anywhere by calling vTaskDelay(), which would then imply that uxSchedulerSuspended was getting corrupted somewhere. Can you see when uxSchedulerSuspended is written to?
“( Here I'm getting a strange behaviour: If I'm putting a delay after the interrupt enable part of prvPortSetupInterrupts( void ) function,”
I don't know what that function is, as it is in your port layer, but generally interrupts would be disabled when the port layer is starting the first task.
“3. I double checked the timer interrupt and it is running continuously and generating an interrupt at every 1ms which is calling the vTaskIncrementTick.
If you are getting stuck in a task even though it has called vTaskDelay() then it is doubtful that the tick interrupt is your problem (yet) as vTaskDelay() should call taskYIELD(), but that is evidently not yielding.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.