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.

AM3358: RTC CLK_32KHz From PLL accuracy

Part Number: AM3358

Customer uses CLK_32KHz from PLL for RTC, but find the RTC time is not accuracy, some board count ahead, some boards count behind, from TRM, the divider would provide a accurate 32.768KHz clock, so the RTC time should also be accurate. Is it the nature of counting RTC with the clock from PLL? or something else?

The 48-MHz clock is further divided by a fixed /2
divider and a fixed /732.4219 divider to create an accurate 32.768-KHz clock for Timer and debounce use.


 


  • What is the accuracy they are trying to achieve with the RTC?

    Regards,
    Paul

  • Paul,

    As customer did not manually configure RTC clock source, thought it is default internal RTC32KCLK from PLL, actually read back register RTC_OSC_REG, value is 0x48, RTC clock sourced from external 32KHz, Seems it is configured in UBoot although did not find the code location.

    Now the problem is the RTC calendar ahead or behind real time several minutes every 24-hours. sometimes just after calibrate the time, it drift 3-4 seconds after 2 minutes.

    RTC connection as below:

    Did further experiments:

    Remove external 32-KHz crystal, with the same software, after each power cycle, the RTC still can count, but calendar start from a fixed/default date 13-1-1 0:0:0.

    reinstall the 32KHz crystal, calendar keep on counting, did not change to default date after power cycle, just drift several minute every 24 hours. 

    I found a similar post as below, but it use 32K_aux_clk, and did not post the detail method on how to solve it.

    https://e2e.ti.com/support/processors/f/791/t/877709

  • It sounds like they have noise coupling into their 32kHz crystal circuit as described in Advisory 1.0.30 of the AM335x Silicon Errata.

    Several customers found this problem is hard to solve on the 32kHz crystal circuit since the signal transitions though the switching threshold so slowly. Most of these customers were able to resolve the issue by selecting the PLL as the RTC clock source.

    The high frequency crystal circuit has a much faster voltage change which makes this issue less likely to occur.

    So they need to switch the RTC clock source or resolve the noise coupling on their PCB.

    Regards,
    Paul

  • Paul,

    If use PLL clock source for RTC, then it can't support RTC only mode (keep calendar during power off). right?

    Maybe worth to try 32KHz oscillator instead of crystal?

  • Using a 1.8V LVCMOS 32.768kHz oscillator should resolve the issue if it is caused by noise coupling into the crystal circuit.  They could easily prove this is the case by removing crystal components and modifying a few systems to source the RTC from an external 32.768kHz LVCMOS source.

    Regards,
    Paul

  • Paul,

    Finally we figured out it is due to software use Linux system time other than hardware RTC, on each power on, software read RTC time then use system time to count, so result in drift. 

    Thanks.