Strictly necessary cookies are on by default and cannot be turned off. Functional, Performance and Tracking/targeting/sharing cookies can be turned on below based on your preferences (this banner will remain available for you to accept cookies). You may change your cookie settings by deleting cookies from your browser. Then this banner will appear again. You can learn more details about cookies HERE.
Strictly necessary (always on)
Functional, Performance and Tracking/targeting/sharing (default off)
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:
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.
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.