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.

CC2340R5: Workaround for Improving LFCLK RTC Accuracy when using LFOSC?

Part Number: CC2340R5


Tool/software:

Hello,

We are using the LFOSC on the CC2340R53 as a source for the LFCLK RTC. After reading some documentation and reading this other forum post (https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1309385/cc2340r5-improve-accuracy-of-lfclk-derived-rtc-when-using-lfosc-as-source), we were wondering if there was a reason that the referenced solution seems not to have been implemented yet for improving accuracy.

In regards to the above footnote, in the other forum post, it was noted that "For technical reasons it was found that improving the accuracy of the LFCLK-derived RTC, and thus the footnote will be removed from the datasheet.". This footnote still exists in the datasheet. The forum post also mentioned a "workaround" that is planned. Was this ever implemented, or will it be? If not, is there a particular reason for this?

I see that calibration does exist on other devices using the AUX_TDC driver, but according to the following forum post, the hardware exists on the CC2340R53, but since it isn't fully validated, there is no documentation or software support. https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1310169/cc2340r5-tdc-support?tisearch=e2e-sitesearch&keymatch=CC2340%20TDC#
Since this post is from over a year ago, are there any updates for when software support may be available?

  • Hello Alexander,

    There have been several improvements to the CC23X0 Power TI Driver since the prior investigation, so I am asking the TI Drivers Development Team for more details and will get back with you shortly.

    I unfortunately do not have any updates to provide concerning the TDC.

    Regards,
    Ryan

  • Hey Alexander,

    As before, TI does not directly support RTC compensation when sourced from LFOSC.  I am once again asking internally to have this footnote removed from the CC2340R5 datasheet.  Please note that the BLE stack will be able to maintain a connection when using LFOSC as the Low Frequency Source Clock.

    Regards,
    Ryan

  • Ryan,

    Could you please explain why TI has chosen not to support LFOSC RTC compensation on the CC2340R5?
    Is it just a low priority issue for TI, or is there some hardware limitation that prevents the CC23XX series from using the same calibration method as the CC26XX processors?

    Perhaps we will look into implementing the calibration logic ourselves, but if there is some hardware limitation that would prevent this, we would like to know beforehand.

    Thank you,
    Peter

  • Hi Peter,

    I have asked for an explanation from the stakeholders and will let you know their response as soon as possible.

    Regards,
    Ryan

  • The TI Driver Team did not pursue LFOSC compensation for a variety of factors that made it unviable for target use cases

    • It is the potential drift while in standby that gets us and makes it challenging to give promises especially across devices and operating conditions.  
    • The combined worst-case PPM between baseline LFOSC inaccuracy, predictable temperature sensitivity, and random thermal noise (RTN) was higher than initially expected, particularly on the RTN.
    • The CC27XX family of devices offer an improved LFOSC with better baseline PPM and lower RTN as well as a dedicated LFOSC calibration mechanism that saved significant amounts of power vs what would have to be used on the CC23XX. The implementations would not have meaningfully overlapped on the SW side and especially the required characterization work would have needed to be done twice.

    There should be nothing to prevent developers from implementing this feature themselves, although they should keep the above limitations in mind during software characterization.

    Regards,
    Ryan