Posted by Tekkon on December 27, 2011
I have an application running on the LM3S8962. The CANBus interrupt service routine grabs the incoming CAN message and calls xQueueSendFromISR() to send out the message to CANRx_Task, which is dealing with processing CAN message. The application runs very good in the first 20 minutes, the CANRx_Task can receive the message and process it immediately. But after 20 minutes, the task has been blocked due to the xQueueSendFromISR() returns errQUEUE_Full in the CAN_ISR. I tried to bump up the queue size from 40 to 80, still got the problem. Can anybody give me some advice how to implement xQueueSendFromISR() for the CANBus ISR and Task, and avoiding errQUEUE_FULL?
Posted by MEdwards on December 27, 2011
When the task unblocks, does it take out all the messages that are in the queue, or just 1? Is the priority of the task that drains the queue high enough? Have you looked at how many messages are in the queue as the application runs to see when they start backing up? Are you yielding using portEND_SWITCHING_ISR in the interrupt handler to make sure the task that drains the queue runs as soon as possible?
Posted by Richard Damon on December 28, 2011
My first guess is that there may be a problem with how you have defined your interrupt routines and you are corrupting the queue structure. Make sure that the priority of the interrupt task is proper for the port (I am not familiar with this family). Also, make sure that the task does NOT call a FromISR routine to get the data.
The 20 minute time period really sounds like it is something "random" causing the problem, and a bad interrupt nesting might be a cause.
Another possibility is that for some reason the CANRx_Task is hung up on some other call and not able to get back to reading from the queue. Are there any other blocking calls that it makes that could do this?
Also, do you use the heap in your program during run time? One problem with this is that if you are not careful, sometimes your program will run out of memory due to leaks or fragmentation and cause things to hang up.
Posted by Tekkon on December 28, 2011
Thank you guys for your help. The queue turns into full all in a sudden, I I guess that's something in the task that messed up the queue structure. After I turned off the application layer callback function(which call the upper level function to process received CAN message) in the CANRx_Task, the CAN_ISR, the queue and the task is running good so far(almost 6 hours).
Currently, the CAN interrupt is the only ISR has been enabled, and has been set to a high priority at 1. And the CAN_ISR is the only source to block/unblock the CANRx_Task. The CANRx_Task also has the highest priority.
Posted by Richard on December 28, 2011
“Currently, the CAN interrupt is the only ISR has been enabled, and has been set to a high priority at 1.”
Please read item three here: http://www.freertos.org/FAQHelp.html It sounds like your priority configuration is incorrect unless you have configMAX_SYSCALL_INTERRUPT_PRIORITY also set to (the equivalent of) 1.
...and read the "Interrupt Service Routines" section of the documentation page that goes with your port.
Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2015 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.