RTOS/CC2640R2F: RTC implementation in CC2640R2F

Hello Abhi,
When you say considerable offsets in measured time of 72 hours, how off were they? The error will depend on the accuracy of the clocks. Typically can range up to 20 ppm. So in prolonged measurements of up to 72 hours, the error can be significant.
Regards,
Prashanth

Hello Prashanth,

Yes, the errors are significant. We observed a drift of 8 to 20 seconds on different modules under test.

I am of the opinion, if we have a constant drift  across multiple PCB's, we can correct it by using a offset. But the worrisome part is that, it is not constant all though the samples are from the same batch.

As mentioned above, what would be interesting for me is to know,

1. If the above implemented mechanism actually works with CC2640R2F without any clashes with the TI-RTOs?

2. Any suggestions, ideas on how to correct this erroneous behaviour?

Thanks a lot for your support,

Regards,

Abhi

Hello Abhi,
The drift won't be constant and varies from device to device. The error comes from the variance in the clock accuracy (it wont be constant error).

1. This error has nothing to do with TI-RTOS.
2. May be you can consider measuring this offset on every device with respect to a reference and correct for it on air using the RF signals.
Regards,
Prashanth

Hello Prashanth,

Thanks, it is clear.

Could you please confirm if our implementation is correct?, i.e. using AONRTCCurrent64BitValueGet() , this function has no side effects?

Thank you,

Regards,
Abhi

Hello Abhi,
Can you give us more information on what is that you are trying to achieve? Why would you need to use AONRTCCurrent64BitValueGet() for 72 hours?
Regards,
Prashanth

Hello Prashanth,

As mentioned in my original post,

our use case is
"Get the time elapsed from the time controller (CC2640R2) was powered up in seconds."

The 72 hours is just an example value (the duration for which we have placed the device under test).

In reality, We would like to retrieve the elapsed time at run time from the controller, by using a command.

Please let me know, if something is unclear.
Thanks,

Regards,
Abhi

Abhi,

You can use AONRTCCurrent64BitValueGet() if the error in the elapsed time across different boards does not affect performance. I can't think of any other way to achieve better performance other than some how measuring and correcting for this error or use an external accurate clock.

Regards,
Prashanth

What we have observed from extensive testing that we have performed for the last few days is,

AONRTCCurrent64BitValueGet(), This function is providing inconsitent results over a long run period. Example, Sometimes the value is totaly erroneous, which is no where close to the expected value.

Now we are performing the tests using the Sys_Tick implemtation for RTC. In this case so far the results are pretty decent and we have observed a constant drift of 4 sec on all the PCB's under test after 32 hours.

e2e.ti.com/.../2431615
e2e.ti.com/.../2435884

The above threads don;t encourage the use of AON RTC in application, which contradicts with the previous responses, which says it is Ok to use the AON registers.

So could you please provide me a clear picture on what can and what shoud not be done to implement the RTC?

Thank you,

Regards,
Abhi

Hello Abhi,

Thanks for the information that AON RTC is inaccurate. I was unaware of this. It is interesting to note that all PCBs have a constant 4 sec drift. I would let some one else with more information answer your question.

Regards,
Prashanth

Hi Abhi,

There is really no reason AONRTCCurrent64BitValueGet() should not work for you. Can you elaborate on what you mean by " the value is totaly erroneous"? Keep in mind the timer does wrap.

You state that you observe 8 - 20 s positive drift over 72 hours. This translates to a clock offset of ~30 - 80 ppm. Have you measured the actual frequency of your 32 kHz crystal oscillator? If this is the same HW as I have been working on, it looks like the load caps are a bit on the low side, which would make the oscillator run fast (12pF load caps for a crystal with CL=9pF). If this is the case, increasing the cap values slightly, to 15 pF for example, will decrease the frequency a bit.

When using systick you are using the 24 MHz crystal oscillator. 4 s over 32 hours means about 30 ppm offset. If this is consistent for all your units you should consider adjusting the load cap-array slightly.

Regards,
Fredrik

Hi,

AONRTCCurrent64BitValueGet() would be the best way to implement a "seconds counter" if the device is to enter standby. The SysTick module will stop counting if the device is put into low-power modes.

There should be no side effects to using AONRTCCurrent64BitValueGet(), all it does is basically perform a read of the RTC counter value, it does not actually impact the RTC functionality.

If you are experiencing drifts between 8 -20 seconds it is likely to be because of the actual clock running of beat. Have you tried to measure up the frequency of the devices and see how much they diverge from what you expect?

It is possible to do some kind of factory trim of devices where the SUBSECINC value of the RTC is adjusted to match the device, but I would assume this to be a bothersome approach.

The threads you linked does not encourage use of the RTC that includes changes in the RTC configuration (which often means we don't encourage using it in any way). This is simply due to the RTC being used by TI-RTOS as the Systick and we want to avoid possible problems due to miss configuration of the RTC.

Just for reference, if someone do actually want to use the RTC for cases where they need to configure their own interval (and are aware of the risks), there is documentation inside the SYS/BIOS API documentation on how to use CH1 and CH2 on how to do this:

dev.ti.com/.../index.html

Dear TI Team,

I have the following queries related to RTC please clarify .

In example code provided by TI ,RTC is implemented using Clock_getTicks(), wherein ticks returned by Clock_getTicks() are conveted to seconds.

1. What is advantage/disadvantage of using AONRTCCurrent64BitValueGet() over the above method?

2. Do they both(Clock_getTicks() and AONRTCCurrent64BitValueGet()) clocked using 32-kHz clock ?

3. Can I use AONRTCSecGet() If I am interested only in seconds (not interested in fractional part)?

Reference of Clock_getTicks() based RTC is in [C:\ti\simplelink_cc2640r2_sdk_1_40_00_45\source\ti\blestack\common\cc26xx\time\utc_clock.c]