gigglergigger wrote on Friday, October 23, 2015:
I have a Cortex app with about 15 tasks each with various i/o queues. I’ve enabled stack checking in config and asserts - no issues.
I have a highest priority task RS485 receiving and sending data to a CAN bus queue. The task that receives this CAN data is lower priority than the sender but the sender is filling the queue slow.
I am seeing data order is changing. All the queues use xQueueSendToBack(…)
sent to CAN queue:
80 ed 11 42 37 54 4c 20 31 38 37 39 36 20 20 20 20 20 20 4a
actually received over CAN bus:
80 ed 42 37 54 4c 20 31 38 37 39 36 20 20 20 20 20 20 4a 11
It seems very consistent. The queue size is larger than 32 CAN frames. There is timing data in the frames that I’ve missed out, so the above is just some characters.
This is the basic CAN sender task (simplified) and queue.
while(1) {
// wait here until we get some data to send
if(xQueueReceive(gxCANData.txQueue[1], &msg, portMAX_DELAY)) {
xISO11898Send(LPC_CAN2, &msg, eCANTXBLOCK_WAITFREE);
}
}
The sender in it’s simplest form is basically doing:
for(ucI=0;ucI<ucNFrames;ucI++) {
xQueueSendToBack(…, frame[ucl], portMAX_DELAY )
}
If I break point in the for(…) loop above, I can see the correct order data.
My CAN analyser shows frames where the squence is out of order.
Strangely I cannot check the queue in the CAN sender task to see if the order there is different. If I breakpoint xQueueReceive(…) I only get 1 entry with first character. However the tasks all still function and send and receive data if I disable the break point to take data from other tasks that are lower or at the same priority. The other tasks using the bus still work sending data. The queue is larger than data being sent in this case and all sends should block waiting for queue space anyway, i.e. send to back with portMAX_DELAY.
Any suggestions?
Regards
dc