• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 52 subscribers
  • Views 524 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.

CC2640R2F: Anything caused the higher RF power consumption

Samson Chen1
Intellectual 760 points
Part Number: CC2640R2F

We built a bunch of PCBA with CC2640R2F. About 0.x% of them, the RF power consumption is higher than the other 99%. Everything is the same. All PCBAs were built in the same batch. The exact same program causes a higher power consumption on advertising in that 0.x% problematic PCBA. The power consumptions in the idle mode or during the RTOS tasks are all the same, just the RF takes about 8% more with those PCBA. I have no idea what caused that. The assembly used ultrasonic welding. Could that be the problem? But the crystal component manufacturers said if the ultrasonic damaged it, it would not work at all.

Any idea? Is there a way for the factory QA to identify such PCBA(s)?

The following tests were using the standard Simple BLE Peripheral project. (Flash is still working).

Thank you for your time.

Samson

  • 0
    TI__Guru** 105180 points

    Hello Samson,

    I don't recall seeing this phenomenon before, but I have seen cases where the ultrasonic weld damages the 32k sleep crystal. In that case you will still ADV and be able to form connections at relatively short CI's. Can you try establishing a connection to the problematic board at a connection interval of say 300-500ms with a short supervision timeout (1-2 seconds)? That would likely cause a problem if the 32k crystal was not functioning.

    Maybe it's just me, but your standby current on the upper image seems just a tad bit higher than the lower (problem) plot. If the 32k crystal wasn't running, you'd save ~ 100nA of current.

    Taking a zoomed in plot of the actual ADV event might be helpful as well. Refer to app note SWRA478 for what this looks like.

    Best wishes

  • 0 in reply to JXS
    Intellectual 760 points

    Hello JXS,

    Thank you for the reply. Can you explain more about the problem when the CI is longer like 300-500ms? Connection lost?

    I just swapped the two crystals (24M and 32.768K), then the power consumption was back to normal. So the best guess is that 32K crystal was damaged. Now the question is... Is there a way to identify whether the 32K crystal is damaged or not by software? SCLK_LF_LOSS? Will that work? I need to find another problematic board to test it since the one I have had been fixed...

    Here is the diagram before the crystals were fixed... (different software, not Simple BLE Peripheral)

    Here is the diagram of the crystals were fixed. Very obvious...

    Samson

  • 0 in reply to Samson Chen1
    TI__Guru** 105180 points
    Glad to see that you are able to isolate the failure. Those ultrasonic welds can do a number on the 32k xtal.

    To check if the 32k xtal is selected/operating, see the code snipped in the "CC26xx BLE HW Troubleshooting & Bring Up" article on the TI BLE Wiki. See the "BLE Connection issues" subsection with instructions on confirming the LF clock source. If the xtal is damaged and can't be selected by the driverLib, it will switch to the internal RCOSC_LF. Since you are not configured to use the internal RCOSC_LF, the sleep clock error (ppm) will exceed the limits for a BLE connection. At a 300ms + CI, the error will be too great to sustain a connection.

    Best wishes