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, configMAXSYSCALLINTERRUPT_PRIORITY, etc.) without much success. Any help would be appreciated.

Thanks, Jon

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

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.

Jon

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 .

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 portENDSWITCHINGISR() exits? Perhaps I shouldn't be clearing the interrupt flag until I know for sure that the ISR has exited.

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.