AnsweredAssumed Answered

How to solve MQX RTCS_time_get() problem?

Question asked by Kari Sipinen on Sep 26, 2012
Latest reply on Oct 1, 2012 by Kari Sipinen



I'm working on project that uses K53 and MQX 3.8.0 with CW C++.

I have done diff with the MQX 3.8.1 and looks like there is no changes to the code that seems to be problematic.


Problem I'm seeing is that for some reason RTCS_time_get() function ( _time_get_elapsed() ) can return values from the past.


Early on when I was trying to bring up our custom board couldn't get DHCP messages going out. Reason was that messages did seem to timeout prior they even went out. During that time I noticed that for some reason timedelta from the calculation below was sometimes negative.

From TCPIP_task()

timeafter = RTCS_time_get();

timedelta = (timeafter - timebefore);


Which, I believe, made timedelta being huge positive number -> that made all the possible event timers to trigger.  And hence DHCP packet was never getting out since it timed out immediately.

To fix that I added code that would make timedelta being 0 in case timeafter was smaller than timebefore. That got us nicely forward during those crucial days of the board bringup.


Now I'm revisiting RTCS portion since we are seeing some extra RTCSERR_TCP_CONN_ABORTED errors. And when tracking down that one looks like same thing happened again in ticker.c

   newtime = RTCS_time_get();

   elapsed = newtime - tcp_cfg->lasttime; /* get elapsed msecs... */

   tcp_cfg->lasttime = newtime;


After reviewing the code from (PSP) ti_elapt.c I was just wondering what would be the best solution to my problem?

Think it all comes down to underlying calls to _time_get_elapsed_ticks() and PSP_NORMALIZE_TICKS() calls.


Since our Debug output is using  _time_get_elapsed_ticks() from various threads with different priorities.

And it looks like we are getting very interesting time stamps.






2191.015:[3,T=0x10006] <-- This would affect negative time. Note this is within one thread!!!