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: XOSC Cap Array / Crystal Tuning

Part Number: CC2640R2F

I'm trying to develop a calibration procedure for manufacturing where each PCBA will have its XOSC load capacitor array tuned. After taking some measurements on a sample of our custom boards, it was determined that there is too much variance between boards using the same cap array value, and that we'll need to calibrate each board during manufacturing.

To tune each board we'll need to sweep through a few cap array delta's and choose the best one. I'm wondering if there is any way to modify the delta value at run time, does it get loaded into a register?  Right now I'm assuming we'll have to reprogram the CCFG for each value we want to test. This isn't ideal, so I'm wondering if there are any alternatives / workarounds.

Thanks,

Josh

  • Hello Josh,

    As we discussed last fall, it makes most sense to identify why you have such variation in your PCBA and identify & address any material quality control issues. It's not typical to have such variation. As such, we don't provide an API for dynamic adjustment in the BLE stack since the cap array delta value is loaded by the driverLib during pre-main initialization. The specific functions are SetupAfterColdResetWakeupFromShutDownCfg2 and SetupGetTrimForAmpcompCtrl in setup_rom.c. Note that this is a ROM function, so you will need to rebuild driverLib with the DRIVERLIB_NOROM define or add these files to your project. If this seems too daunting, it may be best to program the CCFG using the ROM SBL for the desired values. Another option is to use SmarRF Studio 7, the latest release has the long sought after feature to dynamically adjust the load cap values via the GUI.

    Best wishes

  • Hi Josh,

    Would you mind sharing which crystal P/N you are using?

    Cheers,
    Fredrik
  • Hello JXS & Fredrick,

    Thanks for the feedback, I do remember the recommendation from last fall. I sent it along to the appropriate parties and the decision was still made to move forward with developing the calibration procedure. I'll renew that discussion to make sure we are not going down the wrong path.

    In the meantime, I will look into what you mentioned with the driverLib functions JXS, glad to hear there is a path forward if it's needed. If I get tripped up on the implementation I will report back.

    Fredrick, I don't have access to our customer's PDM system to pull the full crystal part numbers, but I believe we are using the:
    AVX / Kyocera Cx3225GB24000 with the R2F and (8 pf load capacitance versions) and
    AVX / Kyocera Cx3225GB48000 with the CC2642

    We will be opting for use of the CC2642, assuming that production parts are available when we are ready to release our product to production.

    Thanks,
    Josh

  • Hi Josh,

    Looking at the crystal datasheet it seems like the tolerance should be good enough, depending a bit on the application use case. What is the observed frequency variation?

    Cheers,
    Fredrik
  • Fredrick, I haven't had access to enough boards to do testing on a significant sample, but on the 10 R2F boards I was able to test with a fixed 7.6pF load cap value all boards were within +/- 12 KHz of the target carrier frequency. Most were closer, but there were outliers at +12 and -12 KHz.

    After some more discussion with my customer we've concluded that this calibration is no longer a hard requirement, there was some confusion on the Radio Frequency tolerance for BLE. We may pursue it anyway as there will already be a station on the manufacturing line with the equipment needed for some other conformance testing. In theory from the calculations we've done, a product could still eventually drift out of spec after ~9 years, if it were a worst case outlier when initially manufactured.

    JXS, thanks for the advice on the driverLib calls. It was pretty easy to get dynamic load cap array changes integrated into our application. I went a slightly different route than you outlined, as the CC26X2 SDK 1.60 driverLib provides a specific API for modifying this value (I'm guessing this was added for the feature added to the SmartRF Studio 7 GUI).

    For anyone curious, here is how I implemented it. When I receive an updated Cap Array value on our products CLI I do the following:

                        Log(LOG_CONSOLE_LEVEL, "Updating cap array delta to %d\n", delta);
                        uint32_t key = Hwi_disable();
                        NOROM_OSC_AdjustXoscHfCapArray(delta);
                        NOROM_OSCHF_SwitchToRcOscTurnOffXosc();
                        NOROM_OSCHF_TurnOnXosc();
                        while (!NOROM_OSCHF_AttemptToSwitchToXosc()) {}
                        Hwi_restore(key);

    Thanks for the help, I think I'm all good on this topic!

  • Thanks for sharing your solution, Josh! I'm sure others will find it useful.

    Best wishes