• State TI Thinks Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 401 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

AM62A7: RTC runs at a frequency of 32552, time is inaccurate

Fadong XUE Fadong XUE
Prodigy 160 points
Part Number: AM62A7


Tool/software:

Hello，teams

    We are attempting to provide a clock source for RTC without using an external crystal oscillator with a frequency of 32768. The final use is an internal clock source with a frequency of 32552.

    Testing time accuracy on Linux system, RTC time is slower than actual time, with a total duration of 422 seconds, which is approximately 27 seconds slower.

    Is there any way to deal with this phenomenon, and are there any compensation parameters that can be adjusted.

Best regards,
XUE Fadong
  • 0
    TI__Guru** 105560 points

    Hello,

    It will take me a couple of days to circle back to your thread. Please ping the thread if I have not replied by Monday.

    Regards,

    Nick

  • 0
    TI__Guru** 105560 points

    Hello XUE Fadong,

    How are you using the RTC in your design?

    I do not think the hardware is capable of correcting a 32552 Hz clock

    There is a drift adjustment feature built into the hardware, and it does look like the rtc-ti-k3.c driver is saving the non-32768 clock rate into variable priv->rate_32k.

    The driver function ti_k3_rtc_set_offset would be where the offset should be applied. It does not look like that function is getting called by the probe function, so you would need to manually call set_offset if you wanted to try to correct the counter.

    However, I do not think that the hardware is capable of dealing with a clock frequency difference as large as (32768-32552)/32768 = 0.66%.

    Why?

    The RTC_COMP register is used to apply a number of periods to the counter value every 4096 seconds. Based on the Linux driver, we see that the most number of periods that can be added to the counter or removed from the counter are 

    /* Min and max values supported with 'offset' interface (swapped sign) */
#define K3RTC_MIN_OFFSET                (-277761)
#define K3RTC_MAX_OFFSET                (277778)

    So how many periods do we get of 32768 Hz in 4096 seconds? 134,217,728 periods
    How many periods with 32552 Hz in 4096 seconds? 133,332,992

    So every 4096 seconds, you would need to add 134,217,728 - 133,332,992 = 884,736 periods in order for your counter value to match the actual time.

    But 884,736 > 277,778. So the hardware cannot make an adjustment that large.

    Regards,

    Nick