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.

System time jump problem and AM335x Advisory 1.0.30

Hello,

In 2013, there was a problem of "System time jumps to 131072 sec ahead suddenly"
under AM335x+linux-3.2.0-psp04.06.00.11.
I asked about this problem in e2e Linux forum, and found that this phenomenon happens due to
AM335x Silicon errata Advisory 1.0.30.

e2e.ti.com/.../1765642

Now I need to ask more about the time jump problem and Advisory 1.0.30.

How was the Advisory 1.0.30 found ?
Was the Advisory 1.0.30 found because some user encountered the time jump problem and then
they found that the electrical noise of OSC caused the time jump problem ?
I have to explain a relation between the time jump problem and Advisory 1.0.30 to my customer technically.
Does the flip-flop in the AM335x tend to catch the noise ?

Rgards,
Takeshi Matsuzaki

  • Hi,

    I will ask the factory team for explanation.
  • The oscillator input buffer has a switching threshold voltage where the output will change states as the voltage applied to the input crosses the threshold.  The voltage applied to the oscillator input buffer is a slow changing sinusoidal signal when using a crystal circuit as the reference clock.  Noise coupled to this slow slew rate signal may cause the output of the oscillator input buffer to toggle several times as the signal slowly crosses the switching threshold.  If this occurs, the internal clock signal will think these unexpected toggles are real clock toggles.  However, these unexpected toggles are much higher in frequency than the real clock toggles.  These much faster toggles will violate internal circuit timing and in some cases may cause the circuits to perform unexpected operations.  For example, portions of the RTC counter circuit may see these fast toggles and respond properly while other portions of the RTC counter circuit do not see the fast toggles.  In such a case, the RTC counter may not function as expected and do very unpredictable things like counting backward.

    If this happens, any internal circuits being clocked from the oscillator output may perform unexpected operations.  In most cases the DPLLs acts like a filter and circuits being clock from the DPLLs never see these unexpected toggles.  We saw one case of a DPPL performing an unexpected operation while debugging this issue, but as mention above any circuit being clocked from the oscillator could perform unexpected operations when excess noise is coupled to the oscillator input signal.

    This issue is completely eliminated if you use a fast slew rate clock source like you get from an LVCMOS clock source.  It is also much harder to cause this issue on the Master oscillator vs the RTC oscillator because the slew rate of the 19.2 MHz - 26 MHz oscillator is much faster than the 32.768 KHz oscillator.

    Regards,
    Paul

  • Hi Paul,
    Thank you for explaining in detail.

    I know it's difficalt to answer clearly, but may I ask you more ?

    The DMTimer1_1ms can get a clock from RTC oscillator, Master oscillator and from a DPLL output.

    When DMTimer1 get a clock directly from RTC oscillator or Master oscillator, and if OSC noise
    occuers(Advisory 1.0.30), DMTimer1 may work wrong like jumping 0x20000, is it right?

    When DMTimer1 get a clock from DPLL, and if OSC noise occuers, DMTimer1 may work wrong too but
    it may be less than getting a clock directly from oscillator because DPLL acts like a noise filter, is it right ?

    Rgards,
    Takeshi Matsuzaki

  • When DMTimer1 is being clocked by the DPLL, noise from the oscillator may be filtered by the DPLL such that DMTimer1 never gets a clock glitch.

    The DPLL may also malfunction as result of noise, but not as likely since the DPLLs are sourced from the faster master oscillator. As mentioned before, it is much harder to couple noise into the higher frequency master oscillator.

    Your customer needs design the product to minimize noise coupling into the crystal circuits.

    In most cases where customers experienced an issue with the RTC jumping backwards in time, they were able to resolve the issue by clocking the RTC from the internal 32.768 KHz clock reference that is divided down from the DPLL output.

    Regards,
    Paul

  • Hi Paul,
    Sorry for the delay in my reply.

    I understand waht you mean. I'll talk to my customer to implement the workarouds.

    Thanks,
    Takeshi Matsuzaki