SNVS/RTC can I use the lower 15 bits to improve system time accuracy?

[craigdenson]

The I.MX6 rtc driver shifts the SNVS RTC value right by 15 bits when setting the system time at startup, and the systohc implementation also truncates to seconds. Is there any reason the driver could not be patched to take advantage of the lower 15 bits? If so, is there some place I could get a better explanation of exactly how to interpret the value of the SNVS RTC register values?

[gusarambula]

The RTC implementation indeed truncate it to seconds as this is the smallest unit of time used on the clock structure so there is not a function that allows for smaller intervals per se.

You would need to have a modified time structure that allows for fractions of a second although this is not usually used on RTC implementations.

[craigdenson]

Understood. This would require patches to linux' hctosys.c systohc.c rtc.c rtc-proc.c, rtc-snvs.c, rtc-dev.c and a standalone re-implementation of hwclock to avoid patching busybox's hwclock.

What I'm not sure about though, is how to interpret the value of the lower bits in the SNVS_LPSRTCLR register that get shifted out by the linux rtc_hctosys (and not set by systohc)

any help you can give me there would be much appreciated. The fact that it's 15 bits and we have a 32kHz oscillator is suggestive, but not sufficient.

[gusarambula]

While I couldn’t find more insight on the details on how the RTC driver works, you may use all bits of the timer as these are all working during regular operation (you may see that the whole timer is checked twice when reading to ensure an appropriate reading, this is covered in section 57.8.2 ‘RTC Value Read’ of the i.MX6D/Q Reference Manual).

As a general rule 32768 cycles of the RTC clock increase the timer one second if using the recommended 32.768 kHz crystal. However, you may increase accuracy by making readings of the RTC more often than this. You should not have any problem using the whole RTC clock bits.