• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 53 subscribers
  • Views 437 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.

LAUNCHXL-CC26X2R1: calibration of cc26x2r crystal for better RTC accuracy

kazola
Guru 18595 points
Part Number: LAUNCHXL-CC26X2R1
Other Parts Discussed in Thread: SYSCONFIG, CC2642R

Hi all,

We are talking about project "project_zero" here.

We use the high-level API "seconds_set()" and "seconds_get()" functions. Everything works but we want to increase the precision. As we have it now, time drifts a bit after some days.

We already read user guide, page 1398.

www.ti.com/.../swcu185f.pdf

We would like to be able to access the AON_RTC to calibrate it. We are guessing we have to:

Change the increment by updating the AUX_SYSIF:RTCSUBSECINC0 and the AUX_SYSIF:RTCSUBSECINC1 registers, and then load the new setting to the AON_RTC by a write to the AUX_SYSIF:RTCSUBSECINCCTL.UPD_REQ register

Honestly, I have no idea how to do this.

Is there an example piece of code that you can provide that does exactly what is stated above?

Do I need to disable interrupts and enable them before and after?

Please let me know your points of view, thanks.

  • 0
    Guru 86755 points

    Hi kazola,

    As I mentioned I have used utc_clock for my project. If you set this utc_clock it is very accurate at the device itself. Now, if you retrieve the utc_clock value and then if it has to go to other processes then that adds to drift.

    The RTC clock is saved in RAM for faster read and write. If you update the RTC clock from FLASH then that will add to drift. Because, FLASH read and write are slower compared to RAM.

    At my previous product development we decided not to use RTC clock from device. Because, we needed to updated the RTC clock device value whenever there is a reset or shutdown. That just adds to the process. So, after receiving the data from the device at smartphone, we append the data with smartphone clock value. 

    Another option is to use a coin cell powered RTC board connected to CC26x2R1. Regardless of the state of CC26x2R1 the coin cell powered RTC board will maintain the RTC clock. But, adding more components to CC26x2R1 will add to current consumption.

    -kel

  • 0
    TI__Guru** 101460 points

    Hi kazola,

    To add on Markel excellent answer, the accuracy of the RTC clock is given by the accuracy and stability of the 32 kHz clock used by the system. 

    The CC2642R has 4 configurations possible when it comes to the 32 kHz clock (all can be configured using SysConfig > Device Configuration > LF Clock Source) - RCOSC, LF XOSC, Derivated from HF XOSC, External LF Clock.

    - The characteristics of the RCOSC can be found in the device data sheet (§8.12.3.5 https://www.ti.com/lit/gpn/cc2642r). This option leads to the lowest BOM costs but gives less accuracy.

    - The characteristics of the 32kHz LF XOSC are given by the crystal vendor. Usual solution as a compromise between costs, accuracy and power consumption.

    - The accuracy of the clock derivated from HF XOSC, depend on the HF XOSC (provided by crystal vendor) - This solution usually gives the best accuracy but prevents the device to go to standby/shutdown.

    - The external LF clock accuracy depends on the clock generator - Reserved to use cases where there is a possibility to generate such clock.

    I hope this will help,

    Bets regards,

  • 0 in reply to Markel Robregado
    Guru 18595 points

    Hi 

    These are good advice, we have followed similar paths and reached similar conclusions.

    Our code works fine with RTC + crystal, we only want to specifically set it up with registrer or driverlib instructions. It also worked with external RTC, we also did this.

    We are just after some real low-level code. We are NOT using the flash or anything, but thanks for this tip, too.

  • 0 in reply to Clément
    Guru 18595 points

    Hi Clement,

    yes we know this, that is why we are trying to specifically tune that 32 kHz clock. We read about the 4 types of RTC sources.

    Specifically I guess we would need:

    - a way to write to registers such as the SUBSEC in AON_RTC, as the user guide says

    AON_RTC implements a 70-bit, free-running counter incremented by a programmable value for each 32
    kHz clock. The programmable value allows compensation of ppm-offsets in the 32 kHz clock, making it possible
    for the counter to operate with a very high precision.

    - a way to reroute the incoming 32 kHz signal to an output pin. This would allow us to see the signal after tweaking the previous register.

    Please let us know who at TI could help with this register or driverlib code.

    Thanks and have a nice day.

  • +1 in reply to kazola
    TI__Guru** 101460 points

    Hi,

    We do not have code reference showing how to write the AON_RTC.SUBSEC - this probably means this has not been tested. With that being said, the AON_RTC.SUBSEC register is a read/write register so it should be possible to write it. My concern is more how this is going to work in case the register is altered by the system concurrently.
    To help getting you started, please refer to the function AONRTCCurrent64BitValueGet() in <SDK>\source\ti\devices\cc13x2_cc26x2\driverlib\aon_rtc.c. This function shows how to read the register the proper way.

    The 32 kHz signal can be routed to a pin with the following code:

    #include <driverlib/aon_ioc.h>
IOCPortConfigureSet(IOIDn, IOC_PORT_AON_CLK32K, IOC_STD_OUTPUT);
AONIOC32kHzOutputEnable();

    I hope this will help,

    Best regards,