• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 32 subscribers
  • Views 1789 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TM4C129XNCZAD: How does the Unix time epoch get set when running with the (IAR) debugger

sjf
Intellectual 296 points
Part Number: TM4C129XNCZAD
Other Parts Discussed in Thread: SYSBIOS

I am working with the DK-TM4C129X, and am using IAR with the I-jet JTAG for debug.

I am working through how to initialize the system time within TI-RTOS so that when I call the C library "time" function from time.h, it returns the seconds since 1970 with somewhat reasonable accuracy. The system time would be set based on a command that is received over one of the UARTs.

Just for kicks, I called the time function, and printf-ed the result with the following:

    time_t my_time = time(NULL);
    
    printf("time: %s\r\n", ctime(&my_time));

To my surprise, the time printed out the console was very accurate relative to the time on the laptop that I am developing on. This was originally surprising since there is no hardware or battery on the DK-TM4C129X which keeps track of time. Obviously, the IAR debugger must be settings the time based on laptop time, and if I run the application without the I-jet JTAG attached, the same code above shows "Wed Dec 31 23:59:59 1969", which is what I expected.

Is there any explanation for how system time is initialized through the debugger, and is it actually the TI-RTOS plug-in that does this initialization? I recognize that this may be a question to ask IAR, but I did not initially see anything in the IAR tool or the documentation on this topic. I am curious because I am trying to do exactly what the debugger currently does, and would like to see how it is done.

FWIW, within TI-RTOS it appears the way to set the system time is through the Seconds_set function. I have not explicitly included the Seconds module within my TI-RTOS .cfg file, so I was wondering whether this is included implicitly through another module, or whether the debugger is using some other method altogether to set the system time.

Thanks in advance.

  • 0
    Guru 13040 points

    sjf,

    I'll write here more for the purpose of tracking the thread. This behavior is unexpected to my knowledge as well, and I'm curious to see the reply.

    Are you really implying you never sent the time setting via the UART? And is that the only way into the setting, inside YOUR code?

    Or is maybe IAR debugger assuming that the value "appears to be close to 1970, and hence this MCU needs to have epoch adjusted"?

    I once wanted to implement some sort of automated macro which would record the compiled time and date, so that I could track the firmware version on devices from those variables. That was back in MSP430 and IAR, and there was a solution for that - but the variable/value was written in the code prior to compiling, not magically sent to the MCU.

    regards

    Bruno

  • 0
    Guru 92251 points

    sjf said:
    I have not explicitly included the Seconds module within my TI-RTOS .cfg file, so I was wondering whether this is included implicitly through another module, or whether the debugger is using some other method altogether to set the system time.

    Found Using C standard library time and clock functions on the IAR web site, which describes how time information can be provided when running under the debugger.

    I haven't checked how the IAR debugger does this, but CCS has the CIO mechanism where when a program is running under the debugger calls to run time library functions such as time() read the time from the host by causing the target to halt on a breakpoint, the CCS debugger then gives the host time to the target and the target is resumed by the debugger. Note that the target can be halted for tens of milliseconds when making such calls due to stopping at a breakpoint and then being automatically resumed by the debugger.

    Whereas when the target is not running under the debugger the time won't be set.

    Presumably IAR implements something similar. 

  • 0 in reply to Chester Gillon
    TI__Guru**** 158795 points
    Hi Chester,
    Thanks for providing the information!
  • 0 in reply to Chester Gillon
    Intellectual 296 points
    I think this is the answer. The IAR website linked above (Using C standard library ...) says that time is available when the debugger is attached (but does not explain where the time comes from), and in looking through some of the source code provided with IAR, there is a folder that contains code used when semihosting is enabled. Within this folder, there is a source file containing an implementation of the time() function which appears to retrieve the local PC time from the debugger infrastructure.

    So this is now all clear. Thanks for your answer.
  • 0 in reply to sjf
    Guru 26105 points

    Hi,

    I have a different opinion in this case, so one question: will your application always be umbilically linked to debugger/semihosting or not? if not, where will come the right date/time and how(if you need to be inside your application/project)? did you checked the board in another computer, without IAR/debugger? 

  • 0 in reply to Petrei
    Guru 117850 points

    Hi Petrei,

    This thread has grown long - Chester has (again) provided the "heavy lifting" - and IIRC - poster intends to, "borrow/model the code methods of IAR" - to add this capability to his project - when the, "umbilical is severed!"

    Poster's success - or lack thereof - would be nice to know & appreciated...

  • 0 in reply to Petrei
    Intellectual 296 points

    No, my application will not need the debugger/jtag during normal operation, and with the debugger disconnected, time() returns -1.

    The current date and time information will be provided in a command received from another system over UART or Ethernet. Once the command is received, the date and time is converted to seconds since 1/1/1970 by using the mktime function, then the Seconds_set function is called to set the time within TI-RTOS:

    #include <ti/sysbios/hal/Seconds.h>

    #include <time.h>

    void set_system_time(struct MyCmd* cmd)
    {
        time_t time_seconds;
        struct tm time_info = {0};

        time_info.tm_year = cmd->datetime.year - 1900;
        time_info.tm_mon = cmd->datetime.month - 1;
        time_info.tm_mday = cmd->datetime.day;
        time_info.tm_hour = cmd->datetime.hours;
        time_info.tm_min = cmd->datetime.minutes;
        time_info.tm_sec = cmd->datetime.seconds;

        time_seconds = mktime(&time_info);

        Seconds_set(time_seconds);
    }

    Before using the Seconds_set function, the Seconds module has to be added to the TI-RTOS .cfg file:

        var Seconds = xdc.useModule('ti.sysbios.hal.Seconds');

    The documentation for the Seconds module says that a specialized time() function should be linked into the application that should return seconds since 1/1/1970 based on the value set by the Seconds_set function, but this is currently not working for me. The time function currently returns -1, which suggests that the time() from the IAR runtime is being linked in. For now, I'm using the Seconds_get function to get time, but this is not optimal since I am trying to reuse a lot of code which make use of the time() function, and I'd rather not have to make changes to this code.

  • 0 in reply to sjf
    Guru 26105 points

    Hi,

    sjf said:
    but this is currently not working for me

    For you to know: CCS/TI uses time epoch of Jan 1, 1900, while IAR/others uses Jan1, 1970, so possible problem(s). However, Tiva has several routines in Tiva/utils/ustdlib.c & .h files, with time epoch also 1970.

    (PC/Microsoft time epoch is Jan 1, 1601 !!!). You need to have a timer with resolution 1 second set to work independently of UART/Ethernet...