• State
  • Locked Locked
  • Replies 10 replies
  • Subscribers 51 subscribers
  • Views 593 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.

CC2642R: 48MHz clock stops working (no code runs) when exposed to high humidity

Garth Richmond
Prodigy 10 points
Part Number: CC2642R

Hello,

We have a CC2642R based product in final testing, and have discovered a strange but serious problem. The device locks up when exposed to humidity (just breathing on the PCB will do it). We have reproduced the same problem using only TI hardware and software - specifically the TI CC2642 Launchpad Eval board with a generic “Simpleperipheral” application... and the freezing still happens.

We have done a lot of investigation, but the results are readily reproducible, and despite our best efforts / experimentation, we have not found a solution. Our device is using a CX2016DB48000C0FPLC1 crystal, and internal load capacitors are set to the default (CCFG delta value = 0), although we have tried many values to no avail.

We believe this is a HF clock failure, because A) the watchdog does not reset the device, which it would if the HF clock was running, and B) we have run the device on a power profiler, which gives a clear picture what is running and what is not... and we can see that the moment we breathe on the device, the BLE advertising stops, our 4Hz signal from the Sensor Controller stops, and no code appears to be running... the device is drawing less than 1 µA.

We need support in solving this so the LaunchPad (and our device) does not die when exposed to humidity.

This is fairly urgent as we are very close to product release date.

Thanks.

  • 0
    TI__Expert 6520 points

    Hi Garth,

    I have escalated this to our validation and product team to further investigate this issue. I myself will be try to replicate this issue on our launchpad boards. Please allow us to have until the end of the week to provide a feedback.


    Note that a typical stress test our device go through is UHAST (JESD22-A118B) which has 2 profiles:

    1. 96 hrs, 130C, 85%RH, 33.3 psia

    2. 264hrs, 110C, 85%RH, 17.7 psia

    To help our team accelerate this troubleshooting, I have a few questions

    1. Do you have an exact level of relative humidity that this failure can be observed?

    2. Has the device or area around crystal gone through any sort of rework? Or are they freshly assembled?

    3. Have you tried other crystals from our recommended list to see if the problem persist? 
    (https://www.ti.com/lit/an/swra495i/swra495i.pdf?ts=1681365107061&ref_url=https%253A%252F%252Fwww.google.com%252F)

    Best regards,

    Bun

  • 0 in reply to Bun Kuch
    TI__Expert 6520 points

    Another question:

    4. Can you replicate this issue with external loading capacitors installed? It may be that the frequency is shifting due to high humidity and causing the advertising to stop.

  • 0 in reply to Bun Kuch
    Prodigy 10 points

    Hi Bun,

    We have been investigating this further, and have an update for you. But first I will answer your questions:

    1. We do not have a precise value for RH to see the problem, but I expect RH of human breath up close is near 100% - our devices are rated for 95% RH non-condensing.

    2. All devices are freshly built on SMT, no rework

    3. We have not tried with other crystals so far.

    4. We have adjusted the internal load caps for 48MHz... to no avail.
        We have 12pFexternal loading caps for the 32kHz XTAL now, and are trying some other values to see if it helps.
        We have not tried external caps on 48MHz XTAL (yet).

  • 0 in reply to Garth Richmond
    Prodigy 10 points

    Here is the update I mentioned above...

    It looks like the LaunchPad does not have the lockup/reset problem, as orignially reported. I think that first test actually caused condensation. In all subsequent tests (done more carefully) the LaunchPad has worked fine, while our device locks up or resets. More to come on this...  

  • 0 in reply to Garth Richmond
    TI__Expert 6520 points

    Hi Garth,

    Per our SME, the 32 kHz crystal has been observed to fail when there is condensation on the board shorting out the two crystal pins, but the issue has not been observed on the 48 MHz crystal unless the impedance between the crystal pin is in the 10s of kOhms range due to high humidity.

    Your latest update was very insightful as it helps narrow the potential root cause to the board design or possible the assembly. Without seeing the layout and schematic it may be difficult to spot the issue


    Additionally, we need to identify which crystal is actually the causing this issue. One quick, possibly way is to de-solder the 32 kHz crystal and try to replicate the failure.

    Keep us posted.

    Best regards,

    Bun 

  • 0 in reply to Bun Kuch
    Prodigy 10 points

    We have more info now... and it appears that it is indeed the 32kHz XTAL that is causing us problems... we know this because we could readily trigger the problem on several of our boards, but by adding two lines of code (shown in bold below) in main() that eliminated the external 32kHz XTAL, the problem disappeared.

    int main()
    {
    /* Register Application callback to trap asserts raised in the Stack */
    RegisterAssertCback(AssertHandler);

    Board_initGeneral();

    OSCClockSourceSet(OSC_SRC_CLK_LF, OSC_RCOSC_LF);
    while (OSCClockSourceGet(OSC_SRC_CLK_LF) != OSC_RCOSC_LF);

    .
    .
    ...etc.

    If possible, please modify the "48MHz" in the title of this ticket to "32kHz" 

  • 0 in reply to Garth Richmond
    TI__Expert 6520 points

    Hi Garth,

    1. Were you able to perform the same, more careful troubleshooting you did the LP on the your board?

    2. Were you able to swap in an alternate part and replicate the issue with the 32kHz crystal?

    3. Can you provide an image of the layout around the 32kHz crystal?

    4. What is the 32kHz crystal vendor part number?

    Best regards,

    Bun

  • 0 in reply to Bun Kuch
    Prodigy 10 points

    Hi Bun,

    We did lot more testing, and we did prove to ourselves that the external 32k XTAL is the source of the problem, when exposed to humid air. Using internal 32k RC avoids the problem, but BLE communication fails, I suspect due to inaccuracy of the RC clock timing of sleep / wake intervals. We also used conformal coating to cover the PCB on and near the 32k XTAL, and the problem went away.

    I do not think the LaunchPad has the same issue... but we have been more focused on our own board.

    We have many board in test, and they all show the same issue with humid air, so swapping MCUs seems unlikely to help.

    The 32kHz crystal is SER4271TR-ND (https://www.digikey.ca/en/products?keywords=ser4271tr-nd)

    I will see about getting you the layout. We will probably need an NDA - please let me know what email address I can send it to..

    Thanks.

  • 0 in reply to Garth Richmond
    Prodigy 10 points

    What format would you like the files in? Gerber files?

  • 0 in reply to Garth Richmond
    TI__Expert 6520 points

    Hi Garth,

    It sounds like you have found the root cause. Conformal coating is the industry standard for handling humidity as it is the most straight forward solution.

    No NDA needed as you can submit the design review here if you like: https://www.ti.com/tool/SIMPLELINK-2-4GHZ-DESIGN-REVIEWS

    Let me know if you have any more questions.

    Best regards,

    Bun