Using periodic timer in MQX

[RichardR]

I am trying to use the periodic timer in MQX to call back to a function that sets an event every 100ms. I use _timer_start_periodic_every(callbackfunction, NULL, TIMER_KERNEL_TIME_MODE, 100).  It appears to work great for some indeterminate time frame.  At some point, it appears to start running the MQX timer task nonstop, never allowing lower priority tasks that are ready to run to do anything.

Ultimately, I'll be setting the time interfval to 1 second, hence the name of the event bit.  I have gone through and disable all other tasks except the Idle task so as to make sure there was no interference from them.  Has anyone seen a similar issue?  Am I doing something wrong in the setup?

Here is the code that sets up the timer, and handles it, as well as the call back function.

   _timer_start_periodic_every(AnalysisPeriodicNotify, (pointer)NULL, TIMER_KERNEL_TIME_MODE, 100L);

   while (TRUE)
   {
      if (_lwevent_wait_ticks(&analysisEvent, ANALYSIS_ONE_SECOND_BIT, FALSE, 0) == MQX_OK)
      {
         wakeEvents = _lwevent_get_signalled();
         
         if ((wakeEvents & ANALYSIS_ONE_SECOND_BIT) != 0)
         {
            _lwevent_clear(&analysisEvent, ANALYSIS_ONE_SECOND_BIT);
            AnalysisPeriodicHandler();
         }
      }
   }
}

static void AnalysisPeriodicNotify( _timer_id timer_id, pointer dummyPtr, uint_32 seconds, uint_32 milliseconds )
{
   (void)dummyPtr;
  
   _lwevent_set(&analysisEvent, ANALYSIS_ONE_SECOND_BIT);
}

Thanks in advance,

RIchard

[RichardR]

I left out the top of the man task that is being awakened every 100ms, here it is:

static LWEVENT_STRUCT analysisEvent;

void AnalysisTask( uint_32 parameter )
{
   uint_32 wakeEvents;
   
   result = _lwevent_create(&analysisEvent, 0);
   if (result != MQX_OK)
   {
   }  

[MarkP_]

Hi,

Code seems to be OK.

At MQX3.7 timers were OK, haven't yet tested them at MQX3.8.

Have you tested the mode TIMER_ELAPSED_TIME_MODE?

Manual says:

"mode [IN] — Time to use when calculating the time to expire;

one of the following:

TIMER_ELAPSED_TIME_MODE (use _time_get_elapsed() or _time_get_elapsed_ticks(),

which are not affected by _time_set() or _time_set_ticks())

TIMER_KERNEL_TIME_MODE (use _time_get() or _time_get_ticks())"

~Mark

[RichardR]

I'll give that a try and see if it makes any difference.

[RichardR]

It behaves identically.  After some indeterminate time frame, in this case it was about 9000 times through the 100ms loop, the MQX timer task just starts running continuously, not yielding to any other tasks.

[RichardR]

Further testing, if I modify the code as below, but leave in the peridic timer setup, which now calls a function that does nothing but return, it still hangs.

   _timer_start_periodic_every(AnalysisPeriodicNotify, (pointer)NULL, TIMER_ELAPSED_TIME_MODE, 100L);

   while (TRUE)
   {
      if (_lwevent_wait_ticks(&analysisEvent, eventBits, FALSE, 10) == MQX_OK)
      {

If I comment out the call to _timer_start_periodic_every(...), it runs without any issue.

No other task in the project uses any form of _timer_startxxxxx.

[DavidS]

Hi All,

I tested this back with MQX3.6 on ColdFire.  Here is the code snippet:

  _timer_id       PollTmr;

  TIME_STRUCT mqx_time;  //DES system time structure variable
 

  _time_get(&mqx_time);  //DES get current system time

   PollTmr = _timer_start_periodic_at(
        PollTimerNotification, //DES notification function to call when timer expires.
        0,       //DES no data pointer used
        TIMER_ELAPSED_TIME_MODE, //DES elapse mode
        &mqx_time,     //DES start time
        (uint_32)5000);    //DES elapes time in ms (5000ms = 5s)

    if(PollTmr)
     printf("\n_timer_start_periodic_at ERROR\n");

I'll put it back on the to-do list but if you get it going sooner please let us know.

Hope this helps.

Regards,

David

[RichardR]

It behaves identically using what you posted.  I also added explicitly initializing the timer with a larger stack.  IAR claims that only 15% of the timer task stack is being used, but it is still hanging, in this case after about 12000 periodic notifications.

[MarkP_]

Tested in Kwikstik with attached file. Works OK, no halt problem.

Tasks has 'jam'-loops, simulating excessive CPU load.

~Mark

[RichardR]

If I remove most of my other tasks, I can get it to run without issue.  I am working on figuring out specifically which task(s) are causing the problem, although none of them use timers other than _time_delay(), and timeouts in system calls waiting on events and such.  CPU usage is low, my Idle task runs just fine right up until the problem occurs, at which point the very high priority MQX Timer task runs continuously.

[RichardR]

Right now it's looking like an issue with the USB virtual comm device tasks and the MQX timer.  When I disable those tasks, leaving all other tasks running, the problem goes away.  We are using the MQX USB device library, and basing our virtual comm handling on the example code supplied with MQX.

[RichardR]

In particular, it appears to be an issue with the transmit task for the USB virtual com device.

[RichardR]

It also appears that I don't have to actually be transmitting anything, just have the TX task created seems to cause the problem.

[RichardR]

It appears that it is not even the TX task, just having the task that calls USB_CDC_Periodic_Task periodically is enough to cause the problem, even with the USB TX and RX tasks not running.

[RichardR]

It appears that the issue only comes up when I have an active connection to the virtual com port.  No data being sent or received, just an open connection.

[RichardR]

So to summarize...

Using MQX periodic timer to generate an event on a periodic basis, with the USB_CDC_Periodic_Task call enning peridoically (using _time_delay between calls), and having an an open connection to the virtual com port with not data being transmitted or received is what appears to cause the MQX timer task to run continuously after a semi random period of time.

As far as I can tell, if I change any one of those conditions, the problem does not occur.  If I use _time_delay instead of the MQX periodic timer, my timing is wrong, but the problem goes away.  If I remove the task that calls USB_CDC_Periodic_Task, the problem goes away, or if I do not open a connection to the virtual com port, the problem goes away.

[DavidS]

Hi Richard,

Are you using the TWRK60n512 hardware?

Which version of IAR? 6.10/6.20/6.30?

I believe thread said MQX3.7.  Correct?

Any other info I'm not asking please pass along :smileywink:

Can you post the project?  Or if need be we can take off line.

Regards,

David

[RichardR]

I am using a board of our own design with the K60 processor.

IAR 6.30.

MQX 3.7.

I cannot post the project.

One more point of interest, changing the priority of the MQX timer task from the default 1 to 8 makes the problem go away.

[RichardR]

Oh, and at priority 8, the timer task is still the highest priority task in the system.

[RichardR]

I've had this running for 3 hours or so now which is far longer than I've been able to run it in the past with the only change being the MQX timer task priority.

[RichardR]

It looks like changing the priority of the timer task corrected the issue for us in two completely different K60 projects, both ran overnight without any issue.  I'd love to understand why that made a difference, being as the timer task is still the highest priority task in the system at priority 8.