A interrupt problem with PIC32

wne1 wrote on Wednesday, January 20, 2010:

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.

edwards3 wrote on Wednesday, January 20, 2010:

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

wne1 wrote on Wednesday, January 20, 2010:

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.

wne1 wrote on Thursday, January 21, 2010:

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.

wne1 wrote on Friday, January 29, 2010:

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?

wne1 wrote on Friday, January 29, 2010:

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

davedoors wrote on Friday, January 29, 2010:

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?

woops_ wrote on Friday, January 29, 2010:

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

wne1 wrote on Friday, January 29, 2010:

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.

wne1 wrote on Friday, January 29, 2010:

>>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.

wne1 wrote on Friday, January 29, 2010:

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

wne1 wrote on Friday, January 29, 2010:

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

edwards3 wrote on Friday, January 29, 2010:

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

edwards3 wrote on Friday, January 29, 2010:

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

wne1 wrote on Friday, January 29, 2010:

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