• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 79 subscribers
  • Views 1481 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.

MSP430F5310: Errata UCS11 detail

Hisao Uchikoshi
Genius 14980 points
Part Number: MSP430F5310
Other Parts Discussed in Thread: CC2500

Hi Experts,

We are using F5310 for more than five years. We recently noticed that on some devices XT2 fault error occurs and clock source was automatically switched to internal DCO. We are using XT2 so the CPU frequency is changed unintentionally causing the system fault. After applying the workaround for UCS11 which clears UCSCTL7 following to writing UCSCTL4, the device seems to work fine. This is actually good for us but this errata occurs on about 10 pcs units recently so we'd like to confirm the UCS11 detail and if possible, we'd like to know the reason why this errata occurs on recent devices.

Looking at the description of UCS11, the XT1/XT2 fault may occur when setting UCSCTL4. My question is why changing SELx bit has a chance to occur the detection of XT1/XT2 oscillator failure since the fault detection circuit is not related to SELx in UCS block diagram.

Could you please advice any?

Regards,

Uchikoshi

  • 0
    TI__Guru**** 218387 points
    Hi Uchikoshi-san,

    For clarity, is the workaround still viable for these recent units? Am I to understand that the devices still work properly but the customer would like to know more about the nature of the errata? What revision are the recent devices in question?

    XT2 will not operate and drive the XT2IN/OUT pins until it is selected as a source for ACLK/SMCLK/MCLK. Once this is done but XT2 is not present, has not been configured properly yet, or has trouble on start-up then the XT2 fault flag could be set. So in this sense the SELx bits do have control over XT2 operation.

    Regards,
    Ryan
  • 0 in reply to Ryan Brown1
    TI__Genius 14980 points

    Hi Ryan,

    Thank you for your explanation. I understood.

    Actually, we are using F5310 over several hundreds units. The only recent devices are encountering UCS11. Die rev is F. We are not sure the revision of previous devices.

    According to our test, UCS11 looks like to occur under 20 degree. At this test, voltage is not changed.

    Do we think the chance of UCS11 depends on lot, fab, temperature or voltage?

    Regards,

    Uchikoshi

  • 0 in reply to Hisao Uchikoshi
    TI__Guru**** 218387 points
    Hi Uchikoshi,

    Is there a new PC board design involved, or is a new crystal type being used with these recent devices? I would suspect that this issue is more related to a hardware fault than an errata, especially due to the temperature dependence. USCS11 only refers to situations where UCSCTL4 is modified and is independent of the variables suggested. I'm suspecting a valid XT2 fault flag as compared to one produced in error. Please advise the customer to review their XT2 design and ensure that it is oscillating properly with the temperature tests.

    Regards,
    Ryan
  • 0 in reply to Ryan Brown1
    TI__Genius 14980 points

    Hi Ryan,

    Thank you for your advice. We are using clock input from CC2500 instead of xtal for XT2. So we believe there is no PCB design modification. MSP430 executes at 1MHz DCO clock after startup and communicate CC2500 at DCO, then after completing CC2500 MSP430 switches CC2500 output clock from DCO. However, we do not observe clock from CC2500 so I will investigate it more detail.

    Thanks,

    Uchikoshi

  • 0 in reply to Hisao Uchikoshi
    TI__Guru**** 218387 points
    Please do investigate the CC2500 clock output and let me know what you discover. The customer needs to follow all recommendations regarding XT2 bypass operation from both the datasheet and user's guide.

    Regards,
    Ryan
  • 0 in reply to Ryan Brown1
    TI__Genius 14980 points
    Hi Ryan,
    We confirmed output clock from CC2500 is fine. We also confirmed the XT2 fault flag is set only when writing UCSCTL4. We can share the clock wave form if you needed. As a result, we are concluding this fault flag is set by UCS11.
    I appreciate any of your comment.
    Regards,
    Uchikoshi
  • 0 in reply to Hisao Uchikoshi
    TI__Guru**** 218387 points
    Hi Uchikoshi,

    Based on these findings the device behavior is the result of errata UCS11 and as such the workaround should be implemented to avoid the issue.

    Regards,
    Ryan

**Attention** This is a public forum