WICED: the time is very inaccurate

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
AxLi_1746341
Level 7
Level 7
10 comments on KBA 5 comments on KBA First comment on KBA

I found the system time is inaccurate, it's slower...

Here is how I test it: (Test with freeRTOS build)

1. The sntp sync will set and print the new time

   So I add below code to show the time before updating by sntp:

--- a/43xxx_Wi-Fi/libraries/protocols/SNTP/sntp.c

+++ b/43xxx_Wi-Fi/libraries/protocols/SNTP/sntp.c

@@ -318,7 +318,10 @@ wiced_result_t sync_ntp_time( void* arg )

     else

     {

         wiced_utc_time_ms_t utc_time_ms = (uint64_t)current_time.seconds * (uint64_t)1000 + ( current_time.microseconds / 1000 );

+        wiced_iso8601_time_t old_iso8601_time;

+        wiced_time_get_iso8601_time( &old_iso8601_time );

+        WPRINT_LIB_INFO( ("Old time is: %.27s\n", (char*)&old_iso8601_time) );

         /* Set & Print the time */

         wiced_time_set_utc_time_ms( &utc_time_ms );

2. Build snip.sntp_get_time with below changes:

A simple test is change TIME_SYNC_PERIOD to (1 * days) and check the timestamp output after 1 day.

3. A more practice test is adding below code to your real projects:

  sntp_start_auto_time_sync( TIME_SYNC_PERIOD );

What I observed is seconds to minutes diff shown by Old time and Current time.

0 Likes
4 Replies
Anonymous
Not applicable

I am using a ThreadX implementation on code that was ported from an earlier version of WICED to WICED 6.2. What I have seen is that ntp sometimes crashes our program. I am not sure if that is a problem with our port of the code or something in WICED or maybe a problem with running out of memory. However in examining the problem we have discovered a couple of bugs in WICED/internal/time.c. I fixed the two bugs and the code does not seem to be crashing that often anymore, but ntp can still sometimes crash, so there is something else going on. My boss was complaining that when he added code to our app to printf the UTC time every second, every 5-10 times that were printed we would see one wildly inaccurate time. He thought there was a multithreading issue and he was right.

The two functions that save and retrieve the millisecond UTC time have bugs in them. There is a thread safety issue and a problem when the 32 bit system tick time rolls over approximately every 47 days. Here are the two critical functions from time.c:

wiced_result_t wiced_time_get_utc_time_ms( wiced_utc_time_ms_t* utc_time_ms )

{

    wiced_time_t temp_wiced_time;

    uint32_t     time_since_last_reference;

    /* Update the UTC time by the time difference between now and the last update */

    wiced_time_get_time( &temp_wiced_time );

    time_since_last_reference = ( temp_wiced_time - last_utc_time_wiced_reference );// This will fail when the 32bit system clock rolls over to 0.

    if ( time_since_last_reference != 0 )

    {

        current_utc_time += time_since_last_reference;// This is not thread safe since utc_time_ms is a 64 bit number on a 32 bit MCU.

///// Also an increment operation is not thread safe.

//// Finally if this function partially completed and then another thread took over

//// using the same "last_utc_time_wiced_reference"

//// then the time would get added to "current_utc_time" twice and the time would jump ahead.

        last_utc_time_wiced_reference = temp_wiced_time;

    }

    *utc_time_ms = current_utc_time;

    return WICED_SUCCESS;

}

wiced_result_t wiced_time_set_utc_time_ms( const wiced_utc_time_ms_t* utc_time_ms )

{

    wiced_time_get_time( &last_utc_time_wiced_reference );

    current_utc_time = *utc_time_ms;// This is not thread safe since utc_time_ms is a 64 bit number on a 32 bit MCU.

    return WICED_SUCCESS;

}

I added a mutex and fixed the roll over problem, but as I say ntp still crashes on rare occasions although it seems to be crashing a lot less. I didn't like this logic involving the calculation of differences between the current system time and the last access time and then saving the current 32bit system tick time as the last access time for the next call to wiced_time_get_utc_time_ms(). I mention above that it is not thread safe, but in addition, a millisecond is a fairly large chunk of time to a computer, so you have significant round off error. By adding up the differences between each time the UTC time is requested, you are compounding the round off errors. For systems where UTC time is requested frequently, the UTC time will be less accurate than the system tick time. My preference would be to have a UTC clock that is just as accurate as the 32bit system tick time, so I completely rewrote the logic, but in reality the main thing you need is to use a mutex and that should fix all the big issues with the UTC clock. If you want to run your app for longer than 47 days, you will also need to fix the roll over issue.

0 Likes
Anonymous
Not applicable

Is this going to be resolved in the next update?

We sync the time using ntp every hour, but I get strange reports from user that might be related to this. Is there any way to test the rollover without waiting 47 days?

0 Likes

jasper wrote:

Is this going to be resolved in the next update?

We sync the time using ntp every hour, but I get strange reports from user that might be related to this. Is there any way to test the rollover without waiting 47 days?

It's actually 2 differnt issues related to time.

Whatever you mention is a bug in getting utc time implementation.

Another issue (as I point out in this thread) is regarding the timekeep in FreeRTOS build

(AFAICT, this is a regression after WICED upgrade to FreeRTOS-9).

I'm not sure if cypress will fix them in upcoming release because there is no cypress member involved in this thread.

However, the inaccurate time issue can cause many bad result, e.g. randomly disconnect - because there are many code paths calculate

the time-diff by comparing starting of an operation with current time. e.g. TLS handshake.)

0 Likes

Which clock source have you used for the STM processor? The time drift is significant when using HSI clock but reduced with HSE. Again an accurate external crystal should be used in your design.