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.

RTOS/CC3220MODA: Issues with Clock Sync in the new SDK 1.60.00.04

Genius 3100 points
Part Number: CC3220MODA

Tool/software: TI-RTOS

Using the example application in the demo folder (local_time in SDK 1.60.00.04), I was able to retrieve NTP time successfully. However my MQTT secure connection does not work due to connection failure to broker. It works fine if I use my old NTP code, which makes me believe that the clock sync is not setting the date & time properly.

Debugging the clock_sync library shows that the date_time structure accepts Month in 0 to 11 and the year is the number of years after 1900 as opposed to the earlier version where the month and year is adjusted in code. Moreover I was also unable to recompile the clock_sync library.

Appreciate if someone can urgently look into this issue.

  • Hi Zac,

    By "old NTP code" are you meaning it is using the library from a previous SDK?

    Best,
    Kevin
  • Hi Kevin,

    Yes, with some dirty tweaks the example from the old sdk (AWS IoT NTP example) works in the new SDK.
    Have someone successfully executed the new SDK NTP library ? As mentioned above, I was able to fetch the time, however the system time never got updated. I have tried changing the configuration in the clock librart, however it din't help.

    Thanks
    Zacson
  • Team,
    Have anyone successfully used the new SDK NTP library to get time and connect to an Mqtt server ? If yes, please provide the details / steps followed.

    Thanks
    Zac
  • Team,

    Further debugging shows that the SNTP time was getting fetched correctly from the NTP servers using the Clocksync_get().
    But the time was not getting saved on the device as persistent data.

    On going through the Clock_sync.c class, I found that we needed to set the CLOCKSYNC_PARAM_UPDATE_NWP to 1.
    Hence, I tried to use the ClockSync_config() with the values as ClockSync_config( CLOCKSYNC_PARAM_UPDATE_NWP, 1). But on test runs, the date on the device was saved with year as 118 and month as 1. (when it should have been February 2018).

    So, I went back to the clock_sync.c file and found that in ClockSync_update(void) function, the nwp time was set incorrectly. Not sure if this is a bug in the implementation, but as a fix I copied this portion of code from the ClockSync_update(void) and modified these lines & added them under the Clocksync_get() invocation point.

    /* check for NWP update */
    if (ClockSync_CB.updateNwp == 1)
    {
    /* convert the local time to tm struct */
    ClockSync_convert(netSecs,&netTime);
    
    nwpTime.tm_day = netTime.tm_mday;
    nwpTime.tm_mon = netTime.tm_mon; / HERE I ADDED 1
    nwpTime.tm_year = netTime.tm_year; // HERE I ADDED 1900
    nwpTime.tm_hour = netTime.tm_hour;
    nwpTime.tm_min = netTime.tm_min;
    nwpTime.tm_sec = netTime.tm_sec;
    sl_DeviceSet(SL_DEVICE_GENERAL, SL_DEVICE_GENERAL_DATE_TIME, sizeof(SlDateTime_t), (uint8_t *)(&nwpTime));
    }
    



    Moderators please review this fix, or let us know if there is any other way of handling it, (ie. Setting the NTP time on device so that we can fetch it through sl_DeviceGet().)

    Thanks,
    Zac.

  • Hi Zac,

    Are you using the new clock sync library within an example from the AWS plugin? If so, the AWS plugin hasn't been validated with this library yet, so there may be an issue there. It was last validated with SDK version 1.40.

    I haven't had a chance to investigate the ClockSync_update function usage. With the local time example working properly, the correct time should be able to be set.

    Best,
    Kevin
  • Hi Kevin,

    I am not using the AWS plugin example, rather I am using the local time example which has the new clock sync library.

    Appreciate your support.
    Thanks
    Zac
  • Hi Zac,

    Oh, OK. I see what you're talking about. It's the format of the tm structure within "time.h"

    struct tm 
    {
        int tm_sec;      /* seconds after the minute   - [0,59]  */
        int tm_min;      /* minutes after the hour     - [0,59]  */
        int tm_hour;     /* hours after the midnight   - [0,23]  */
        int tm_mday;     /* day of the month           - [1,31]  */
        int tm_mon;      /* months since January       - [0,11]  */
        int tm_year;     /* years since 1900                     */
        int tm_wday;     /* days since Sunday          - [0,6]   */
        int tm_yday;     /* days since Jan 1st         - [0,365] */
        int tm_isdst;    /* Daylight Savings Time flag           */
    #if _AEABI_PORTABILITY_CHECK
        int __extra_1, __extra_2;            /* ABI-required extra fields */
    #endif
    
    };

    Best,

    Kevin

  • Any update on this issue ?

  • Team,

    The new clock sync library in 1.60.00.04 is not functional in setting the system time correctly unless the above work around is applied. This also make is less useful and adds unnecessary complexity.
    Would appreciate if TI can look into this and make it functional out of the box.

    Thanks
    Zac
  • An appropriate fix in the SDK may be required to resolve this issue.
  • Hi Zacson,

    This will be fixed in the next SDK release. Please use your work around for the time being.

    #define CLOCKSYNC_BASE_YEAR             (1900)
    
    nwpTime.tm_day  = netTime.tm_mday;
    nwpTime.tm_mon  = netTime.tm_mon + 1;
    nwpTime.tm_year = netTime.tm_year + CLOCKSYNC_BASE_YEAR;
    nwpTime.tm_hour = netTime.tm_hour;
    nwpTime.tm_min  = netTime.tm_min;
    nwpTime.tm_sec  = netTime.tm_sec;

    Thanks,

    Kevin

  • Hi Kevin,

    Thanks for the update. I am already running my code with the fix.
    Could you please let me know the date by which the SDK would be released with the fix?

    Thanks
    Zac
  • Hi Zac,

    The SDKs are released on a quarterly basis. Q1 is scheduled to end at the end of this month.

    Best,
    Kevin
  • Hi Kevin,

    SDK 2.10.00.04 got released on 19th March, however I don't see this solution in the change log. Could you please check and confirm whether the fix has been included in 2.10.00.04 ?

    Regards,
    Zac
  • Hi Zac,

    Yes, I can confirm that the change was made to clock_sync.c in SDK 2.10.00.04. Please make sure you have the SDK selected in the products tab if you're using CCS.

    C:\ti\simplelink_cc32xx_sdk_2_10_00_04\source\ti\net\utils\clock_sync.c

    However, you are correct, I do not see the change noted in the change log or release notes. Looking into this.

    Thanks,
    Kevin