AnsweredAssumed Answered

MQX scheduler starts misbehaving after running for a short time

Question asked by Andrew Clegg on Feb 11, 2015
Latest reply on Feb 16, 2015 by soledad

I am building a data logging system using MQX on a TWR K60F120M board. Data is mapped as external memory using flexbus, and it is signalled that it is ready by an interrupt line. The software interrupt copies the data into MQX memory, and this is then picked up by an MQX task. The task packages up a set of samples into a data block, and sends it via the msgq interface to another task which writes it to SD card. A third task prints out status information every second, using _time_delay. I have been experimenting with different data rates, with interrupts ranging from 200 to 2000 per second.


I am experiencing a problem where after several minutes of running, something in the scheduler seems to break. The SD card task calls _msgq_receive(qid, 0) which should wait until a message is ready and then return it, however after a few minutes it starts returning immediately with the 'message not available' error code and a null message. I had similar problems when I was using _lwsem_wait - even with timeout set to 0, it would immediately return from the 'wait' call without actually obtaining the semaphore. Finally, my status information task gets stuck in the _time_delay function, never returning from the call. All this makes me suspect that the problem is with the MQX scheduler itself. I am not using time slicing, and I have the most recent versions of MQX and CodeWarrior.


I have noticed that the higher the interrupt rate, the quicker this happens. If I set it to the lowest (200 per second), it can run for hours or days before breaking. However if I set it much higher (1000 or 2000), it will only run for seconds or minutes. Using the task aware debugging, I have checked that stack overflows are not occurring.


If anyone else has seen this problem, or can point me in the right direction to diagnose it, I would be very grateful.