vTaskSwitchContext not working on PIC32

kg4ysn wrote on Tuesday, September 16, 2008:

Hey all,

I posted a message the other day regarding problems with the PIC32 and the MPLAB SIM environment.  As I poked around some more, it turns out that the problem may be more involved.

Within a single time slice, prvIdleTask performs as expected – the PC works down through the function to vApplicationIdleHook and then loops.  I was able to confirm this by toggling some GPIO pins and watching them with an oscilloscope.

During the evaluation of line 1699 in tasks.c, a “sltiu v0,v0,2” instruction is issued.  The next command should be “bne v0,zero,0x9d0014f4.”  However, the PC instead jumps to 9FC0_1200, which is the location for portSAVE_CONTEXT from ISR_Support.h.  So I’m guessing that some kind of timer triggered off an asynchronous event, and we’re now entering vTaskSwitchContext.

vTaskSwitchContext processes through, and as portRESTORE_CONTEXT is called, we end with our "ERET" instruction at 9D00_4B78.  But instead of jumping back to where we were at 9D00_14F4, we jump right back to portSAVE_CONTEXT and begin the process anew.  This continues ad infinium, causing the simulator to crash (due to a spurious error related to "sd ra,-1(ra)" being processed as NOP) and the real PIC32 board to hang.

The full contents of FreeRTOSConfig.h are below.  Anyone have an idea on how to solve this one?  Is this a bug in v5.0.3, or is it a user error?


#define configUSE_PREEMPTION            1
#define configUSE_IDLE_HOOK                1
#define configUSE_TICK_HOOK                0
#define configTICK_RATE_HZ                ( ( portTickType ) 1000 )
#define configCPU_CLOCK_HZ                ( ( unsigned portLONG ) 80000000UL ) 
#define configPERIPHERAL_CLOCK_HZ        ( ( unsigned portLONG ) 40000000UL )
#define configMAX_PRIORITIES            ( ( unsigned portBASE_TYPE ) 5 )
#define configMINIMAL_STACK_SIZE        ( 400 )
#define configISR_STACK_SIZE            ( 500 )
#define configTOTAL_HEAP_SIZE            ( ( size_t ) 28000 )
#define configMAX_TASK_NAME_LEN            ( 8 )
#define configUSE_TRACE_FACILITY        0
#define configUSE_16_BIT_TICKS            0
#define configIDLE_SHOULD_YIELD            1
#define configUSE_MUTEXES                1
#define configCHECK_FOR_STACK_OVERFLOW    2
#define configQUEUE_REGISTRY_SIZE        0

#define configUSE_CO_ROUTINES             0
#define configMAX_CO_ROUTINE_PRIORITIES ( 2 )

#define INCLUDE_vTaskPrioritySet        1
#define INCLUDE_uxTaskPriorityGet        1
#define INCLUDE_vTaskDelete                0
#define INCLUDE_vTaskCleanUpResources    0
#define INCLUDE_vTaskSuspend            1
#define INCLUDE_vTaskDelayUntil            1
#define INCLUDE_vTaskDelay                1
#define INCLUDE_uxTaskGetStackHighWaterMark    1

#define configKERNEL_INTERRUPT_PRIORITY        0x01


rtel wrote on Wednesday, September 17, 2008:

Exiting one interrupt then entering another is not necessarily an error - this could be a legitimate execution patter especially if interrupts are nesting.

It is my understanding the the simulator is a bit ‘limited’ when it comes to PIC32.  I’m sure it will be improved.

Which hardware are you using/do you have access to an Explorer 16?  Ideally can you confirm that you have the demo as provided in the FreeRTOS.org download running before making any modifications?

If you have different hardware, then can you try a simple LED flashing example first - see http://www.freertos.org/porting-a-freertos-demo-to-different-hardware.html .

The PIC32 port is being used on some quite complex projects so I am as confident as I can be that it is sound, but obviously I cannot guarantee it.  I too have used it quite extensively.

Have you checked that you are not overflowing your stacks?


kg4ysn wrote on Wednesday, September 17, 2008:

Hi Richard,

Thanks for the posting.  There definitely wasn’t any overflowing of stacks; I used an LED-style example to do debugging to determine if this was the case.

After comparing against the demo code, I found that I had missed a tiny #pragma config declaration.  Once I corrected that, the timers seemed to fire off correctly, and context switching worked as expected.  So chalk this one up to user error.  :slight_smile:

Thanks for taking the time to look into it!