PIC32MZ SemaphoreGiveFromISR() causes exception

pbjork wrote on Thursday, June 05, 2014:

PIC32MZ2048ECH100, FreeRTOS0.8b, MPLABX 2.05, XC32 compiler v1.31.

Exceptions occur after several thousand successful ISR cycles exclusively in uxListRemove(), called from xTaskRemoveFromEventList() (which is several call levels down from SemaphoreGiveFromISR()). Either general or TLB exceptions may result. The pxEventList->uxNumberOfItems seems to be corrupted (or becomes very large), resulting in a null pxItemToRemove->pvContainer passed to uxListRemove(), which causes the exception.

I try to read the number of items to see if it is growing slowly, or just suddenly explodes, but it seems to go from typically 1 to a very large number suddenly.

Any ideas?

tlafleur wrote on Thursday, June 05, 2014:

Just a note. I’m not using. xTaskRemoveFromEventList

tlafleur wrote on Thursday, June 05, 2014:

I’m using the same processor with 8.0 Xc1.31, mplab 2.10 have not had an issue with that function.

Pic32mz2048ech. Rev a3

pbjork wrote on Thursday, June 05, 2014:

If you’re using SemaphoreGiveFromISR then that will eventually call xTaskRemoveFromEventList.

Yes, RevA3 on the processor.

BTW, this code was working on a PIC32MX part before I ported it to PIC32MZ.

rtel wrote on Thursday, June 05, 2014:

Are you 100% sure the interrupt that is calling xSemaphoreGiveFromISR() has a priority at or below the priority set by configMAX_SYSCALL_INTERRUPT_PRIORITY? Do you have configASSERT() defined? If so then that should trap an incorrect interrupt priority provided you are using a recent version of FreeRTOS (you say you are using FreeRTOS 0.8b, I don’t know what that is).

Regards,
Richard Barry.

pbjork wrote on Thursday, June 05, 2014:

Oh, sorry, it’s FreeRTOS version 8.0.0 that was supplied with Microchip’s Harmony 0.8b framework.

pbjork wrote on Thursday, June 05, 2014:

Oh, sorry, it’s FreeRTOS version 8.0.0 that was supplied with Microchip’s Harmony 0.8b framework.

Ouch. For some kind of test I reset configMAX_SYSCALL_INTERRUPT_PRIORITY from 6 down to 3, then forgot to move it back, I have several interrupts up to level 6. I’ll change it back and test.

I’ll also look into configASSERT(). I haven’t used it yet. Thank you Richard, for your prompt reply.

Paul

pbjork wrote on Thursday, June 05, 2014:

So far so good. Problem appears to have gone away, at least over a test length about 10 times as long as what it took the exception to be thrown before.

Good call.