A interrupt problem with PIC32

When I use xSemaphoreGiveFromISR in one of my ISR (ipl3), my code hangs. In RTOS viewer, the xTickCount is zero all the time and only shows 3 out of 8 tasks in the viewer. This topic could be discussed before. After searching and reading this forum, I am still not sure what would cause it and how to correct it. Could you give me the possible reasons that you can guess based upon my description? Or, let me know what else I can provide to solve it.  I’ll check with it tomorrow. Thanks.

A interrupt problem with PIC32

Is the priority of the interrupt equal to or lower than configMAX_SYSCALL_INTERRUPT_PRIORITY? Do you have stack overflow checking on?

A interrupt problem with PIC32

my configMAX_SYSCALL_INTERRUPT_PRIORITY is equal to 0x03, which is equal to the ISR priority level.
I’ll try to figure out if your 2nd question true or not tomorrow. Thanks for the reply.

A interrupt problem with PIC32

I set a break point inside the function vApplicationStackOverflowHook( void ), I did  not observe a break, so, I assume that there is no overflow happened.

A interrupt problem with PIC32

After days working on it, I found that my code hangs at _general_exception_handler. It always happen when the code running in function:
xQueueGenericSendFromISR
line:
if( pxQueue->uxMessagesWaiting <= pxQueue->uxLength )
after stepping off this line, my code ends up general exception. Any clue?

A interrupt problem with PIC32

Sorry, I changed “<” to “<=” in
if( pxQueue->uxMessagesWaiting <= pxQueue->uxLength )
but the same result.

A interrupt problem with PIC32

If the interrupt priority is correct, then I’m going for stack overflow or some other form of data corruption within the queue. It might be that the PIC is raising an exception before the stack overflow is checked. Have you written the ISR *exactly* as per the examples?

A interrupt problem with PIC32

PIC32 has a separate interrupt stack. Only the task stacks are checked for overflowing.

A interrupt problem with PIC32

one more update:
I checked the *pxQueue in Watch window. what I caught are when code stop at line:
if( pxQueue->uxMessagesWaiting < pxQueue->uxLength ) (it always can stop here, but here is the key)
then in watch window,
1. If the uxMessagesWaiting value is 0x00000000 and uxLength value is 0x00000001, my code will run fine.
2. If the uxMessagesWaiting value is 0x00000000 and uxLength value is 0x40976000, the code must end up general exceptioni. (this happen most of time).
In case 1, I type pxQueue->uxMessagesWaiting and pxQueue->uxLength in watch window, they both show value 0xA00038B0.
in case 2, they both show value 0x40976000
I am not able to interpret the phenomenon.

A interrupt problem with PIC32

>>Have you written the ISR *exactly* as per the examples?
I got not only one ISR using xSemaphoreGiveFromISR, but only one is not working. I use copy and paste technic to write my ISR, chen change parameters, so… >>PIC32 has a separate interrupt stack. Only the task stacks are checked for overflowing.
I doubled the configISR_STACK_SIZE, but seem not working.

A interrupt problem with PIC32

How to prevent interrupt which calls API function occurring before scheduler start? this might solve my problem.

A interrupt problem with PIC32

Seem that it is taken care by FreeRTOS automatically. Am I right?

A interrupt problem with PIC32

Provided you don’t change the interrupt bits yourself, then yes it should be taken care of.

A interrupt problem with PIC32

Inspect xSchedulerRunning from the exception handler to see if the scheduler was actually started before it crashed.

A interrupt problem with PIC32

xSchedulerRunning  value is 0x00000001 when I check at general exception handler point.