• State TI Thinks Resolved
  • Locked Locked
  • Replies 15 replies
  • Answers 2 answers
  • Subscribers 55 subscribers
  • Views 381 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Original question:

CC1352R: Calibrate RTC

CC1352R: Calibrate RTC

sandra Garcia
Prodigy 50 points
Part Number: CC1352R
Other Parts Discussed in Thread: SYSCONFIG

Hi,

I have been working in other parts of the code, and totally leave the issue of the real time clock a side. Now I will try to restart with it.

In my hardware, I have a 48MHZ xtal reference: XRCGB48M000F4M00R0, I have changed in the sysConfig the Xosc Cap Array Delta to see if there was any change in the accuracy of the real time clock, but it was not changing, or the change was so small that I was not able to see it.

Also I was checking the value of SUBSECINC, and it is always the same value it never changes, and I do not know how can I see if my code is using this value or not, because I can not find where my code calls this function.

I have a device which needs to have a calendar, for this I use the function "Seconds_set" from Seconds.h. So when I need to check the calendar, i call "Seconds_get()". Is this option the right one to have a calendar?? Or should I use any other function or driver?

Thanks,

Sandra

  • 0
    TI__Expert 4425 points

    Hi Sandra,

    You can use Seconds_set to set the epoch time, and then you can use the time.h library to get the current date and time. Please refer to this E2E thread: https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1010813/launchxl-cc1312r1-how-to-use-rtc-to-keep-track-of-updated-current-time. Note you do not need to call Seconds_get(), because this is done internally when calling time(NULL)

    Are you using an external crystal for the LF clock (i.e. is SCLK_LF set to XOSC_LF). This is selected in the "Device Configuration" module in SysConfig. If XOSC_LF is selected, no calibration will be done. Calibration will only be done if you have selected RCOSC_LF (internal RC oscillator) as the LF clock and if you have enabled "Calibrate RCOSC_LF" in the "Power" module in SysConfig. We are planning on adding support for performing the calibration when XOSC_LF is selected in a future SDK release.

    Regards,
    Nikolaj

  • 0 in reply to Nikolaj_G
    Prodigy 50 points

    Hi Nikolaj,

    Thanks for your fast reply.

    Thanks for the link for the real time clock.

    About the oscillator, we are using also an external LF, reference "TF202P32K7680". So in the sysconfig I have it selected as LF_XOSC. So that means that there is not done the calibration?

    Is it possible to make it by myself?

    When it is planned more or less to have the new SDK release??

    Many thanks!

    Sandra

  • 0 in reply to sandra Garcia
    TI__Expert 4425 points

    Hi Sandra,

    Correct, the RTC compensation will not be done in your case.

    I believe the support for compensating the RTC when SCLK_LF is XOSC_LF will be ready in the Q4 2022 SDK (but the decision is not final yet).

    You can possible add the compensation yourself, but may I ask why you want to perform the compensation? It seems like the your LF crystal has at least the same frequency tolerance as your 48MHz crystal (at least at 25°C), so why do you want to perform the compensation of the LF crystal against the HF crystal? What are you hoping to achieve? 

    Regards,
    Nikolaj

  • 0 in reply to Nikolaj_G
    Prodigy 50 points

    Hi,

    My problem is that my real time clock is not well accurated, it goes around 1 second faster per hour.

    Some time ago I asked about this topic, and one colleage told me that there was the RTC compensation, and I was making some tests without result, but I needed to stop this until now, that I have found some time to try to fix this problem.

    Thanks,

    Sandra

  • 0 in reply to sandra Garcia
    TI__Expert 4425 points

    Hi,

    An error of 1s per hour sound quite high. That's an offset of around 278 ppm, which seems much higher than the frequency tolerance of the crystal you are using. You can try to output the SCLK_LF clock signal by configuring the mux of a DIO using GPIO_setMux(x, IOC_PORT_AON_CLK32K). With this you can measure if the clock has the expected frequency.

    A hacky way to enable the compensation is described below:

    1. Add the files source\ti\drivers\power\PowerCC26X2.c and source\ti\drivers\power\PowerCC26X2_calibrateRCOSC_helpers.c to your project
      1. We will make changes to these files, and this way they will only apply to the specific project.
    2. In Power_init in PowerCC26X2.c comment out the lines corresponding to line 3 and 5 below: 
          if (PowerCC26X2_config.calibrateRCOSC_LF) {
        /* verify RCOSC_LF is the LF clock source */
//        if (ccfgLfClkSrc == CCFGREAD_SCLK_LF_OPTION_RCOSC_LF) {
            PowerCC26X2_module.calLF = true;
//        }
    }
       
      1. This will enable the calibration even though RCOSC_LF is not used as the LF clock.
    3. Add lines 5-8 from below to PowerCC26X2_setAclkRefSrc in PowerCC26X2_calibrateRCOSC_helpers.c
      __tfm_secure_gateway_attributes__
void PowerCC26X2_setAclkRefSrc(uint32_t source)
{
    if (source == ACLK_REF_SRC_RCOSC_HF || source == ACLK_REF_SRC_RCOSC_LF) {
        if ((source == ACLK_REF_SRC_RCOSC_LF) && (CCFGRead_SCLK_LF_OPTION() == CCFGREAD_SCLK_LF_OPTION_XOSC_LF))
        {
            source = 3; // XOSC_LF
        }
        /* set the ACLK reference clock */
            DDI16BitfieldWrite(
                AUX_DDI0_OSC_BASE,
                DDI_0_OSC_O_CTL0,
                DDI_0_OSC_CTL0_ACLK_REF_SRC_SEL_M,
                DDI_0_OSC_CTL0_ACLK_REF_SRC_SEL_S,
                source
            );

            /* read back to ensure no race condition between OSC_DIG and AUX_SYSIF */
            DDI16BitfieldRead(
                AUX_DDI0_OSC_BASE,
                DDI_0_OSC_O_CTL0,
                DDI_0_OSC_CTL0_ACLK_REF_SRC_SEL_M,
                DDI_0_OSC_CTL0_ACLK_REF_SRC_SEL_M
            );
    }
}
      1. You also need to add "#include DeviceFamily_constructPath(driverlib/ccfgread.h)" to the file.
      2. These steps are done such that the correct clock is used when preforming the measurement of the LF clock for performing the calibration.
    4. Enable "Calibrate RCOSC_LF" in the "Power" module of SysConfig.

    These steps are not well tested and is not suggested to be used in production code, but you can use them to test out if the calibration will help with your issue.

    Regards,
    Nikolaj

  • 0 in reply to Nikolaj_G
    Prodigy 50 points

    Hi,

    Many thanks! I will try it and lets see if it works.

    Sandra

  • 0 in reply to Nikolaj_G
    Prodigy 50 points

    Hi,

    I have left the device during the weekend, and the clock accuracy is worst now. 17 minutes.

    I was trying to measure the SCLK_LF, but I am not able to do this beacuse I am using the SDK 5.20, and the function GPIO_setMux(x, IOC_PORT_AON_CLK32K) is not there.

    So i am not able to measure it. I was trying to change the SDK but it is giving me more errors. So I will try to find the way to measure the output.

    Sandra

  • 0 in reply to sandra Garcia
    TI__Expert 4425 points

    Instead of using GPIO_setMux, you can use IOCIOPortIdSet: https://dev.ti.com/tirex/explore/content/simplelink_cc13xx_cc26xx_sdk_6_20_00_29/docs/driverlib_cc13xx_cc26xx/cc13x2_cc26x2/driverlib/group__ioc__api.html#gae87a1f6be14963bee3439b13a7f4cfac 

    Are you saying that the RTC is 17 minutes incorrect over a period of one hour? How are you measuring the accuracy?

    Regards,
    Nikolaj

  • 0 in reply to Nikolaj_G
    Prodigy 50 points

    Hi,

    I am using the function you have suggestes, but I can not see anything in the output, only that the pin goes high level. I do not know if I need to make any other configuration.

    17 minutes was during the weekend, more or less it is around 24 seconds per hour. To measure the accuracy I put the date/time to my device, and then I read back from it and I compare the dates to see which is the accuracy.

    Thanks,

    Sandra

  • 0 in reply to sandra Garcia
    TI__Expert 4425 points

    Hi Sandra,

    Sorry, IOCIOPortIdSet only changes the muxing, you also need to configure the IO to enable output.

    You can configure the muxing and enable the output with this function (IOCIOPortIdSet is not necessary when using below function):

    IOCPortConfigureSet(IOID_x, IOC_PORT_AON_CLK32K, IOC_IOMODE_NORMAL);

    Regards,
    Nikolaj

  • 0 in reply to Nikolaj_G
    Prodigy 50 points

    Hi,

    With this instruction I have the same result, the pin is in high level.

    thanks,

    Sandra

  • 0 in reply to sandra Garcia
    TI__Expert 4425 points

    Hi Sandra,

    I am very sorry for the inconvenience. Below is what you need to do:

    Include the necessary header files:

    #include <ti/devices/DeviceFamily.h>
#include DeviceFamily_constructPath(driverlib/ioc.h)
#include DeviceFamily_constructPath(driverlib/aon_ioc.h)

    Add the following after any board/pin initialization code (to prevent the initialization overwriting the configuration). 

    IOCPortConfigureSet(IOID_7, IOC_PORT_AON_CLK32K, IOC_IOMODE_NORMAL);
AONIOC32kHzOutputEnable();

  • 0 in reply to Nikolaj_G
    Prodigy 50 points

    Hi,

    Finally I can see the wave. I can measure 32,77 khz with the oscilloscope.

    Regards,

    Sandra

  • 0 in reply to sandra Garcia
    TI__Expert 4425 points

    Hi Sandra,

    Can you try to measure the frequency with a higher accuracy?

    Are you sure you have selected the correct load capacitors for your external LF oscillator?

    You mentioned that you have previously that you have tried to modify the cap array delta value (see quote below). Are you sure you have changed set it back to the correct value (Note: The "correct" value depends your board and crystal). If the incorrect value is chosen, this can affect the accuracy of the HF clock, and that might be why your accuracy is worse when enabling calibration of the RTC against the HF clock. 

    sandra Garcia said:
    I have changed in the sysConfig the Xosc Cap Array Delta to see if there was any change in the accuracy of the real time clock, but it was not changing, or the change was so small that I was not able to see it.

    These documents might help you out:
    https://www.ti.com/lit/an/swra640f/swra640f.pdf 

    https://www.ti.com/lit/an/swra495i/swra495i.pdf 

    Regards,
    Nikolaj

  • 0 in reply to Nikolaj_G
    Prodigy 50 points

    Hi Nikolaj,

    Thank you very much for your support. Unfortunately now I do not have access to the laboratory to make the measurements of the oscillator and the HF calibration. But I can imagine that my problem is in the HF oscillator, when I have access to the laboratory if I found something or I need something I will come back to you.

    Thank you very much,

    Sandra.