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