POSIX clock_gettime() is discontinuous

[d3zd3z]

The implementation of clock_gettime() when called with CLOCK_MONOTONIC is non-monotonic (it jumps backward) about once a second after the first time that the k_cycle_get_32() counter wraps. On the FRDM-K64F, this means the result is incorrect after about 35 seconds, and is never correct from then on.

The problem is that the k_cycle_get_32() is used mod sys_clock_hw_cycles_per_sec. Unless the hw cycles per sec is a power of two, the overflow will not occur on a second boundary. This effectively means that this sub-second value is completely meaningless after the counter wraps the first time.

I can suggest two solutions, a short-term and a better fix:

1. Use the lower precision 'ms' value from `k_uptime_get() to set the nanosecond field. The value will be less "accurate", but a less accurate number is still more useful than a completely meaningless value that is currently used.
2. Longer term, keep a proper 64-bit counter by watching the k_cycle_get_32 counter, noticing overflows, and using them to increment an upper-32-bit counter. It might be best to just have a k_cycle_get_64() counter, and use that for the monotonic time.

[d3zd3z]

Putting a little more thought into this, this is actually a bit harder. If implementing 2 above, we would need to make sure that we didn't read the counter in between it wrapping and the upper bits being set. It would probably take coordination with the IRQ handler, which would make accesses slower.

Perhaps 1 is the best solution. At least for TLS use of the time, the clock only needs to be accurate to within a few minutes, and certainly not more accurate than 1ms.