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.

AM3352: question about RTC_PWRONRSTn assert time

Part Number: AM3352

There was an issue with AM3352 (ZCZ package) custom board.

According to the data sheet, "RTC_PWRONRSTn should be asserted for at least 1 ms ...".

So, what will happen if this condition does not meet (shorter time than 1 ms)?

Rarely, with unknown reason, when connecting power cable to custom board, OSC1_OUT (RTC_XTALOUT) did not come out, there was no oscillation.

When issue happened, the Linux OS booting was fine, but no 32kHz clock working.

At normal case, OSC1_OUT, 32,768 Hz output has no issue.

Can you guess why RTC_XTALOUT (OSC1_OUT) does not oscillate?

 

Regards,

Hayden

  • Hi Hayden
    I will forward to additional experts
    Can you double check this thread to see if the customer design can leverage the debug/design steps here to isolate the problem on their board
    e2e.ti.com/.../316906
  • Additionally, based on the internal threads I had a few more follow up questions

    1) Can you clarify the fail rate, how many boards failing?
    2) Are the failures time 0 failures or does these boards stop showing RTC XTLOUT over time?
    3) Can you please clearly specify what swap experiments have been done with crystal and processor. I would like to make sure that putting a failing processor makes a known good board fail - that failure truly follows the device.
    4) I see that they have tried to change the crystal and it did not make a difference, did they try to change the crystal vendor
    5) Please also elaborate on the temperature sensitivity relationship.
    6) You are asking about the PWRONRST timing dependency - are you see the behavior to differ between good vs bad board - if so please share the waveforms.

    Regards
    Mukul
  • Hi Mukul,

    I will check an update via e-mail.

    Thanks and regards,
    Hayden
  • Copying some more internal discussion, on the questions posted previously 

    1) Can you clarify the fail rate, how many boards failing?
    [Response] Currently, total six AM3352 devices show the issue.
    [TI] 6 boards out of how many?

    2) Are the failures time 0 failures or does these boards stop showing RTC XTLOUT over time?
    [Response] With board of the specific AM3352 device, when issue happens, RTC_XTALOUT signal never oscillate (remains pulled-up) after connecting the power cable.
    When repeating the test (power cable connect/disconnect), the fail rate with the specific AM3352 device is about 60~70% during the repeat test.
    [TI] Ok, so failing boards never work reliably from time 0.

    3) Can you please clearly specify what swap experiments have been done with crystal and processor. I would like to make sure that putting a failing processor makes a known good board fail - that failure truly follows the device.
    [Response] Our quality team will send information.

    4) I see that they have tried to change the crystal and it did not make a difference, did they try to change the crystal vendor
    [Response] We also checked for swapping crystal, but phenomenon of failure was same. And crystal unit on bad board was checked (frequency, physical damage, de-cap test..) from vendor,
    they said OK for their crystal.
    [TI] Can you share further details on tests done. Additionally my request was to see if it is feasible to try crystal from another vendor too.

    5) Please also elaborate on the temperature sensitivity relationship.
    [Response] Current issue board shows the symptom at normal room temperature.
    [TI] Does the failure become better or worst at high or low temperature?

    6) You are asking about the PWRONRST timing dependency - are you see the behavior to differ between good vs bad board - if so please share the waveforms.
    [Response] We got board today. We will send the detail wave form. (In previous, we checked that PWRONRST timing is same between good vs bad.)

    [TI] 1ms is required for the RTC LDO to stabilize CAP_VDD_RTC. Do you know if they are using internal LDO in this case?