PIC32MZ Assert/exception in vListInsertEnd()

jmmag wrote on Tuesday, November 04, 2014:

As a preface, I had typed up a lengthy post describing my methods for diagnosing this problem, but lost it without warning when the page navigated to the ‘CodeHilite’ documentation. So I apologize in advance if this initial post does not seem as detailed (or marked-up) as what it would have been.

Anyway, I have been encountering issues when sending messages from a DMA ISR to a task queue via xQueueSendFromISR(). The address error exception occurs at this line:

pxIndex->pxPrevious->pxNext = pxNewListItem;

and when debugging I see that the stack is indeed overflowing, but have tried a number of things to address the issue (increasing stack, configMAX_SYSCALL_INTERRUPT_PRIORITY, etc.) without much success. Any help would be appreciated.


edwards3 wrote on Tuesday, November 04, 2014:

The PIC32 port uses configISR_STACK_SIZE in FreeRTOSConfig.h to size the stack used by interrupts. Have you tried increasing that?

jmmag wrote on Tuesday, November 04, 2014:

Yes, I stopped at 8k; furthermore all of my ISR variables are either global or static and the queue element is only 4 ints in size. I have found a few different threads that deal with similar issues, but none seem to match mine exactly. Although, this post seems to describe my situation of the exponential stack usage, but the ISR flags aren’t reset until after xQueueSendFromISR() finishes. So there should be no chance for recursion, at least above the hood.


rtel wrote on Tuesday, November 04, 2014:

There are two ways of defining interrupts on the PIC32. One uses the compiler syntax to get the compiler to generate the interrupt entry code, the other uses an assembly file wrapper to switch stacks on interrupt entry in order to save a lot of RAM. Which method are you using?

Regards .

jmmag wrote on Tuesday, November 04, 2014:

I am using the latter method of wrapping the InterruptHandler into the assembly InterruptWrapper just like all of the demos supplied by FreeRTOS & Microchip.

Another point worth mentioning is that the issue goes away when I decrease the interrupt frequency. Is it possible for an ISR to yield to its own interrupt if one happens before portEND_SWITCHING_ISR() exits? Perhaps I shouldn’t be clearing the interrupt flag until I know for sure that the ISR has exited.

rtel wrote on Wednesday, November 05, 2014:

On a lot of architectures it would not be possible for an ISR to yield
to its own interrupt, but I’m not sure on the MIPs. It depends on the
interrupt controller implementation.