Hello Community, I’ve been using FreeRTOS for a while now on my project and I have to say I love it. Tough i’m facing a bug which is killing me. My code contains a large amount of code, about 80 files and use several microchip stack and run about 10 tasks. The problem is that about 2-3 times a day, the chip will go into an address error interrupt and I haven’t really been able to find out what was the source of the problem. I believe that this error occur at the moment of an interrupt because I’ve been able to reduce the occurrence of the crash be using DMA transfer in one UART which reduce the interruptoin by a factor of 80. I’ve been reading a lot of example and and forum thread about it, but it seem to always have different approach about how to handle interrupt, whether use or not the taskYield, specifically on the PIC24EP. An other point is the interrupt nesting. It is currently enabled and I haven’t tested disabled. I’ve seen some thread about it without really an answer whether it should be kept enable or not. This is the way I’m currently handling my DMA interrupt. I use a queue instead of a semaphore for previous code compatibility bot it does the same job.

c

void attribute((interrupt, autopsv)) _DMA1Interrupt(void) { char val = 55; IFS0bits.DMA1IF = 0; // Clear the DMA1 Interrupt Flag xQueueSendFromISR( RS485Queue, &val, NULL ); } Some example from the RTOS library shows no task yield after the interrupt. – Shall I add the yield into each interrupt ?

c

void attribute((interrupt, autopsv)) _DMA1Interrupt(void) { char val = 55; portBASETYPE xTaskWoken; IFS0bits.DMA1IF = 0; // Clear the DMA1 Interrupt Flag xQueueSendFromISR( RS485_Queue, &val, &xTaskWoken); if( xTaskWoken ) taskYIELD(); }

• Shall I disable Nested interrupt ?
• Shall I add more stack space in my tasks ? I’m not a specialist of processor stack and the way RTOS works at the stack level. If two interrupt happens at the same time then the current running task would need bigger stack size ? Might my problem be related of having two interrupt (or more) at the same time and having nested interrupt use more task space than it is actually defined ?

Thanks for your help

Some example from the RTOS library shows no task yield after the interrupt. – Shall I add the yield into each interrupt ?

If you have the yield then, if writing to the queue caused a task to unblock and the unblocked task has a priority equal to or above the priority of the current task, then the interrupt will return directly to the unblocked task. If the unblocked task has urgent processing to perform, including if the unblocked task is completing the actual interrupt processing, then that is what you should do. If that is not the case then you can leave out the yield and the task will get selected at the very latest in the next tick interrupt.

Shall I disable Nested interrupt ?

As I recall the PIC24 only has a partial interrupt nesting model that does not allow interrupts that use the RTOS API to nest anyway. Is you DMA interrupt running with a priority equal to the priority of the tick interrupt? As it is using the RTOS API you must ensure this is the case. Double check the information in the “RTOS port specific configuration” section of the PIC24 documentation page.

Shall I add more stack space in my tasks ?

At least during development ensure you have the stack overflow hook defined. You can also check the free stack space manually in the debugger (because the stack is filled with 0xa5 when it is created) or using the uxTaskGetStackHighWaterMark() function.