• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 53 subscribers
  • Views 566 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.

RTOS/LAUNCHXL-CC1310: Both RF_getTime() and Clock_getTicks() goes backwards in time when CC1310 sleeps?

Michael Moon
Expert 2050 points
Part Number: LAUNCHXL-CC1310
Other Parts Discussed in Thread: CC1310

Tool/software: TI-RTOS

Hi,

I'm trying to track clock drift on a cc1310.

My application has a fairly complex interaction between long-running radio commands and periods of sleep, and I'm trying to measure the drift that occurs when regularly switching between clock domains. Measuring clock drift of each crystal independently without characterising errors from regularly changing between clock domains would be worthless for my application.

The problem I'm experiencing is that both RF_getTime() and Clock_getTicks() occasionally jump to a lower value in situations that are NOT integer rollover (at just shy of 18 minutes and 12 hours respectively) - I can easily handle integer rollover.

RF_getTime() will sometimes go backwards by the entire length of the sleep period which, during clock drift testing is ~30 seconds.

Clock_getTicks() seems to only jump back by the wake period, ~1-2 seconds.

This happens every few minutes to half an hour, seemingly at random.

If I prevent the cc1310 from sleeping (eg by never ending my radio command), there are no jumps from either clock source, but then I can only measure the drift of the XOSC and not the combined drift when regularly waking and sleeping.

Are there any known race conditions in the clock save/restore code that might cause this behaviour?

  • 0
    Expert 2050 points

    Forgot to include a log.

    Short log demonstrating the issue

    I generated this using a combination of CC1310 code (which generates everything from @ time ms .... fl 0x0000nnn) and a host-side post processor which prepends a full timestamp and adds systime/nodetime/delta/drift/ppm on the end

    This is using RF_getCurrentTime() which rolls over at ~1060 seconds. As you can see, I have absolutely no problems with the rollover and successfully track drift and ppm over the rollover with no problems.

    However there are a number of spots where my post-processor detects disjoints and has to reset the ppm measurement because the numbers don't make sense - going back in time is usually an indication of rollover but these steps back in time are clearly not rollover.

    My script will happily tolerate disjoints of a line or two, in the case where UART doesn't flush it's buffer properly before sleep, but these are different. The clock *remains* behind and completely throws off the ppm tracking unless I start tracking again.

    All lines in the log are printed from a single System_printf in the RF callback in my code, there's no possibility of multiple threads generating lines of text and printing them out of order.