CC2340R5: The accuracy of the 32kHz RC Oscillator (LFOSC)

Hi Ryan, 

My customer is developing medical application and need to sample vital signs once per minute by CC2340.

So the number of the record of vital sign will be 60x24= 1440 records every day.

The phone APP need to collect 1440 records every day from CC2340.

If the CC2340 RTC time is not accurate enough, the  the number of the record of vital sign will be incorrect.

Through Test1 and Test2 , we know the exact deviation between RTC and LGPTimer.

For Test 2 , my customer are already multiplying TIME524 by 0.524 second to get 5 seconds different from the system time.

And we need to know why the time difference of Test1(1 second ) is different than Test2 (5 second).

We also need to know which way(better) is better for calculating the exact deviation between RTC and LGPTimer.

Then my customer can try to compensate RTC  to get close to the correct value.

Please help to provide comments.

Thanks.

Mike Wu1 said:

If the CC2340 RTC time is not accurate enough, the  the number of the record of vital sign will be incorrect

The RTC will be more accurate if using an external 32 kHz crystal (XOSC) as the LF clock source.

Mike Wu1 said:

And we need to know why the time difference of Test1(1 second ) is different than Test2 (5 second).

Please provide code snippets of each implementation for review.

See this similar E2E thread for which 524.288 ms is the true units of TIME524.  That can make for a significant difference across a long time span.

Mike Wu1 said:

We also need to know which way(better) is better for calculating the exact deviation between RTC and LGPTimer.

Mike Wu1 said:

The phone APP need to collect 1440 records every day from CC2340.

If there is a phone APP connection then the phone can send its own timestamp occasionally and the CC2340R5 can resync and adjust the sample rate accordingly.

Regards,
Ryan

Ryan Brown1 said:

The RTC will be more accurate if using an external 32 kHz crystal (XOSC) as the LF clock source.

Since using an external 32.768K oscillator will cause the MCU to reset during ESD testing, we have to switch to the internal oscillator and use a calibration method to perform RTC timing.

Ryan Brown1 said:

Please provide code snippets of each implementation for review.

See this similar E2E thread for which 524.288 ms is the true units of TIME524.  That can make for a significant difference across a long time span.

void Calibration_RTCTimerCallback(LGPTimerLPF3_Handle lgptHandle, LGPTimerLPF3_IntMask interruptMask)
{
    g_tRTC.uiRTC_Calibration_Count++;
    if(g_tRTC.uiRTC_Calibration_Count >= 125)
    {
        g_tRTC.uiRTC_Calibration_8us = HWREG(RTC_BASE + RTC_O_TIME8U);
        LGPTimerLPF3_disableInterrupt (hTimer_RTC, LGPTimerLPF3_INT_TGT);
        LGPTimerLPF3_stop(hTimer_RTC);
        if(g_tRTC.uiRTC_Calibration_8us < g_tRTC.uiRTC_Calibration_8us_old)
            g_tRTC.iRTC_Calibration_8us_diff = (g_tRTC.uiRTC_Calibration_8us + 0xFFFFFFFF) + g_tRTC.uiRTC_Calibration_8us_old;
        else
            g_tRTC.iRTC_Calibration_8us_diff = g_tRTC.uiRTC_Calibration_8us - g_tRTC.uiRTC_Calibration_8us_old;

        g_tRTC.dRTC_Calibration_perSecond = (double)(g_tRTC.iRTC_Calibration_8us_diff - 125000) * 0.000008;
    }
}

    /* ----Calibration RTC Timer Initial ---- */
    hTimer_RTC = NULL;
    LGPTimerLPF3_Params LGPparams_RTC;
    LGPTimerLPF3_Params_init(&LGPparams_RTC);
    LGPparams_RTC.hwiCallbackFxn = Calibration_RTCTimerCallback;
    LGPparams_RTC.prescalerDiv = 48 - 1;
    uint32_t counterTarget_RTC;
    hTimer_RTC = LGPTimerLPF3_open(CONFIG_LGPTIMER_1, &LGPparams_RTC);
    if(hTimer == NULL)
    {
//        while(1){}
    }
    counterTarget_RTC = 8000 - 1; // 8ms with a system clock of 48MHz
    LGPTimerLPF3_setInitialCounterTarget(hTimer_RTC, counterTarget_RTC, true);
    g_tRTC.uiRTC_Calibration_Count = 0;
    g_tRTC.uiRTC_Calibration_8us_old = HWREG(RTC_BASE + RTC_O_TIME8U);
    LGPTimerLPF3_enableInterrupt(hTimer_RTC, LGPTimerLPF3_INT_TGT);
    LGPTimerLPF3_start(hTimer_RTC, LGPTimerLPF3_CTL_MODE_UP_PER);

Due to power consumption issues, CC2340 cannot be connected to the mobile phone continuously.

Hi Ryan,

Thanks for providing this code.  I believe this is for Test 1, correct?  And this results in a 1 second delta from the real time after 18 hours?  Your code implementation is reasonable and I am syncing internally to confirm the preferred LFOSC calibration method.  If you want a review of Test 2 then please provide it as well, although it appears to be less precise.  Have you measured the LGPTimer accuracy against the system time?

Regards,
Ryan

Hi Ryan,

Test 1 is that I used an external 48M +-10ppm oscillator and turned on LGPTimer to calculate the error of the oscillator used by the internal 32.768K RTC. The calculated result is that the error is about 16us per second.

Test 2 is used to verify Test 1. Theoretically, if the error is only 16us per second, then after 18 hours, there should be only about 1 second difference, but in fact it is about 5 seconds. I want to know where the difference is? Or is there something wrong with my settings?

The following is the error calculation I performed using test 1, using a 524M RTC, and performing the calculation after sleep(1)

                g_tRTC.uiRTC_0_524288s_count = HWREG(RTC_BASE + RTC_O_TIME524M);
                g_tRTC.uiRTC_0_524288s_different = g_tRTC.uiRTC_0_524288s_count - g_tRTC.uiRTC_0_524288s_count_old;
                g_tRTC.uiRTC_0_524288s_count_old = g_tRTC.uiRTC_0_524288s_count;
                g_tRTC.dRTC_second += ((double)g_tRTC.uiRTC_0_524288s_different * 0.524288) + ((double)g_tRTC.uiRTC_0_524288s_different * 0.524288 * g_tRTC.dRTC_Calibration_perSecond);
                sleep(1)

You will need to ensure with the CCS debugger that your g_tRTC values are not rounding or removing the least significant digits.  I would also advise against relying on the sleep function to reliably consume exactly 1 second.  Here is a logic analyzer test where a GPIO is toggled every second:

This delay will increase with the g_tRTC logic.  Below is a test using ClockP timeouts instead (or you can choose LGPTimer as with Test1):

Although I would expect that comparing your calibration techniques against the real world time would reveal the best code implementation.

Regards,
Ryan

First of all, g_tRTC uses double type for calculation, so theoretically there will be no rounding problem.

Second point: Is this not related to how to consume 1 second accurately? Because no matter how to consume 1 second, I read the value of RTC register for calculation. Sleep(1) is only used to ensure that CC2340 enters sleep mode and is not used to count RTC. LGPTimer is too power-consuming if it is turned on for a long time.

Ryan Li said:

First of all, g_tRTC uses double type for calculation, so theoretically there will be no rounding problem.

I agree, and I trust that measures have been taken to confirm the calculations performed, so am simply cautioning additional inspection as the CCS compiler and optimization settings can have an effect on calculations.

Ryan Li said:

Second point: Is this not related to how to consume 1 second accurately?

I don't have the full Test 2 implementation, so if the delay between each calibration doesn't have to be precise then that's fine, I am just cautioning that a ClockP periodic software interrupt would be more precise than the relative sleep function.  ClockP allows for sleep mode unlike the LGPTimer.

Regards,
Ryan