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: 32.768kHz Clock Issue with CC2640R2F

Part Number: CC2640R2F

Hello,

We are coming across issues with the 32.768 kHz clock on the CC2640r2. After building up a few boards, we did a bluetooth connection test where the units failed (we've successfully ran this same exact type of test with a cc2640r1). We have a build that buffers the 32.768kHz clock through a GPIO from the 2640r2. We use this pin to measure the clock on our factory test build in production builds. When we measure the clock output with the r2 we are getting very sporadic values. Those values are not close to 32.768 and are off by several thousand ppm. All other clocks are measuring correctly. Also, we see that if we remove the chip from the board and then place it back, that we get different results but still way off. As a control test, we measured the clocks with a CC2640r1 and a known good pcb that we've used in production, then we removed that same chip and placed it on our new pcb and had good results. We then put a CC2640r2 on the known good pcb and got bad results. Is there something that we need to be doing differently in firmware? We were under the impression that this was a drop in replacement. Thanks in advance.

-Allen

  • Hi Allen,
    Are all boards with R2 devices have the same problem? How many are failing? Which xtal (part number) are you using?
  • Hey FI,

    Thanks for your response. We are seeing this issue with every board that has an R2 device. We have the exact same boards with R1 devices and are working normally. We have built up 8 units and all are exhibiting this behavior. We are using part number: ABS07-32.768KHZ-T.

    https://abracon.com/Resonators/ABS07.pdf

    -Allen

  • Hi Allen,
    Please consider the information in section titled "BLE Connection issues" of this link: processors.wiki.ti.com/.../CC26xx_HW_Troubleshooting
    Also, your xtal loading capacitance is 12.5pF where as we recommend 7pF. Our Max is 12pF for 32.768kHz xtal.
    It could be that R2 is not behaving well due to borderline xtal spec. Is it possible to change the xtal and loading caps and see if this fixes the issue?
  • Thanks FI, we'll give this a try and report back. If that's the case, I'm not sure why it's been working with the R1. We've built and sold thousands of units with this same crystal on the R1...
  • Hello,
    I wanted to add to FI's post above.

    If there are marginal issues on crystal layout - it is possible that you did not see issues on R1 but see it on R2 due to process/ osc trim variations. So ensuring you are staying with the crystal cap loading spec is important.

    Secondly , this issue can be debugged in application. The device drivers (driverlib) is setup to default to the internal RC oscillator if the LF XTAL fails to start. This might explain the high PPM variance you are seeing. One way to determine if this is the case is to read the LF clock source using the driverlib function OSCClockSourceGet(); Calling this function returns the value of the clock source.

    In your case, the expected return value should be "OSC_XOSC_LF"
    If instead you are getting a return value of "OSC_RCOSC_LF" this would imply that the LF osc failed to start - and we can determine that this is the reason for the frequency deviation.

    Let me know if you are able to use / call this function in your application (after board init) or I can provide an example.

    -Priya
  • Priya,

    Thanks for your help. This was our issue. Our team must have missed that when porting over the R1 project to the R2. Thank you!