System stack switch sequencing (PIC32)

myserious wrote on Tuesday, March 15, 2011:

Richard & Crew

Could you clarify the sequence of operations for ISRs to use the system stack when the ISR uses the Queue FromISR functions that need that trailing “if (hiPriTaskWaiting)” check? 

Until we get our hands on the OpenRTOS USB Device stack, we’re using the Microchip device stack, which is a pretty big ISR - especially as it hooks down into our code which drops the incoming char (or buffer) on a queue in the interrupt context.  So we’re motivated to switch stacks when it is running to avoid having to have that much room on 10+ other tasks. 

It seems that the first step is to “wrap” the ISR from an assembly file like this:

	jal 		USBDeviceTasks
	.end vUSBInterruptHandler

of course with the interrupt mapped in the .C file like this:

#pragma interrupt vUSBInterruptHandler ipl3 vector 45

In the actual C that is called (in this case, the Microchip USB device ISR-not-as-an-ISR function


), there is no special coding until we do the enqueue… where we record if a high priority task is waiting.

Here’s where it gets interesting.  At the end of that C function, we of course add:

portEND_SWITCHING_ISR( xSwitchRequired );

Now, is that really correct?  we’re calling the yield but we have’t “unwrapped” in the assembly wrapper the portRESTORE_CONTEXT, so we’re yielding whilst the stack is switched to the system stack. 

Are there any issues there?  We seem to be getting some odd behaviour when we take this approach and we’re trying to ensure we understand the proper flow so as not to chase ghosts.

The Serious Team

rtel wrote on Tuesday, March 15, 2011:

If you follow the instructions in the “interrupt service routines” section of this page:

and copy the example in the demo that that page documents, then FreeRTOS will automatically handle switching to an interrupt/system stack for you.  It is also explained in the FreeRTOS PIC32 tutorial book.