Hello, I have an application running on a PIC32 and is hanging in the vListInsert, right by the big comment with suggestions for fixing issues :)

The application will run for a while, and work fine, until it seems to somewhat randomly hang in this function.

Here is my summary:

* Micro: PIC32MX795F51L
* Compiler: C32
* Version: v7.1.1
* Standard Demos work

Steps I have taken:
*Made sure configCHECK_FOR_STACK_OVERFLOW = 2 and I have provided the vApplicationStackOverflowHook function, nothing ends up in there
* Checked the uxTaskGetStackHighWaterMark for all of the tasks, they seem to have plenty of stack space left
* Checked the interrupt priorities, as far as I understand, they look OK to me. Here is what they are set at:

#define configMAX_SYSCALL_INTERRUPT_PRIORITY0x03
#define configKERNEL_INTERRUPT_PRIORITY0x01

This application uses interrupts for CAN communication, here is their priority settings:

INTSetVectorPriority(INT_CAN_1_VECTOR, INT_PRIORITY_LEVEL_4);
    INTSetVectorSubPriority(INT_CAN_1_VECTOR, INT_SUB_PRIORITY_LEVEL_0);
    INTEnable(INT_CAN1, INT_ENABLED);

When it hangs, the call stack can be traced back out to this line:

CANMessage_STR * message_PTR;
portBASE_TYPE status;

status = xQueueReceive(xQueueHandleCANSend, (const void *) &message_PTR, (2/portTICK_RATE_MS));

Sorry I forgot to ask an actual question... Does the interrupt priority setting look OK? What would be my next thing to check? From reading other posts regarding this issue, it looks like some corruption of memory could be to blame somewhere in the application?

I'm looking at serial.c in the standard demo as a reference. The function it calls to set the interrupt looks quite different to the one you are using so I guess the microchip API has changed since the demo was written. I would say though that if INT_PRIORITY_LEVEL_4 sets the interrupt priority to 4 then that could be your problem. If the CAN interrupt calls FreeRTOS functions then the priority needs to be 3 or lower. I have no idea what the sub priority is.

Also, are you entering the interrupt through the assembly code wrapper as described on the web page, and shown in the example I'm looking at?

Thanks, that did the trick. I have read and re-read the page talking about the interrupt priority, but I somehow got my head turned around reading about the Cortex M3 inverted priority order and thought 4 was lower than 3.... Thanks again!