• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 54 subscribers
  • Views 264 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.

CC1312R: Exact clock frequency of Clock_getTicks()

Alexander Fickle
Prodigy 10 points
Part Number: CC1312R
Other Parts Discussed in Thread: SYSCONFIG

We are using Simplelink cc13x2_26x2 SDK version 3.20.0.68 on a project with the cc1312 using an external 48MHz oscillator part number ABM8W-48.0000MHZ-7-D1X-T3.

We are attempting to use Clock_getTicks() to timestamp events and are noticing that this clock appears to be running about 4% slower than expected.  Clock_tickPeriod is 10, but from our measurements on one device the period is closer to 10.4 microseconds.

Is there a way to get a more accurate frequency for the clock backing Clock_getTicks()?  Even if we have to calculate it ourselves and hard code it that is fine.  Additionally can we tell if Clock_getTicks() is using our external oscillator or an internal one?

  • 0
    TI__Intellectual 2115 points

    Hi Alexander,

    From the API calls you are using I'm assuming you are using TI-RTOS as operating system, correct?

    You should definitely be expecting better clock accuracy if your external 48MHz crystal behaves following to its datasheet (I read this part has a freq tolerance of 10ppm and freq stability of 20ppm). 

    Are you using Radio in the application? I'm asking this because highest accuracy calibration is performed by the Power driver if RFlib is in use. 

    Also is RCOSC calibration enabled in your application inside the Power section of the Power driver?

    You can check which clock source is being used to feed the system clock SCLK_HF in the "System configuration" tab of sysconfig:

    Regards,

    Fausto

  • 0 in reply to Fausto C
    Prodigy 10 points

    We are using TI-RTOS and the radio.

    I was told that the version of Simplelink SDK version that we are using predates the SysConfig tool that you are showing.  Looking at the ccfg.c that we are using it appears that the our system clock is using "LF XOSC".  I am basing this off the SET_CCFG_MODE_CONF_SCLK_LF_OPTION define.  If this is the clock backing Clock_getTicks() then maybe we should change this to be the "LF clock derived from HF clock" option.  I do not see any references to clock calibration in our settings file.

  • 0 in reply to Alexander Fickle
    TI__Intellectual 2115 points

    Hi Alexander,

    could you provide an example in which we can replicate this issue. That would be very useful to debug the problem. 

    Are you seeing this inaccuracy consistently over time ?

    Also as it seems that you are sourcing the LF XOSC as your system clock, what is the LF crystal you are using in your design?

    Regards,

    Fausto

  • 0 in reply to Fausto C
    Prodigy 10 points

    Oh, it looks like the system clock is attempting to use a crystal that does not exist due to our misconfiguration of the SET_CCFG_MODE_CONF_SCLK_LF_OPTION define.  It is likely falling back to a different clock source.  From table 7-4 of the cc13x2 user manual (literature number SWCU185E) it looks like it is falling back to a clock source with a frequency of 31.25kHz.  The external oscillator has an expected frequency of 32.768kHz.  This difference is near the 4% that I initially measured.

    I'll rebuild my application configured to use the HF clock as the system clock source and rerun my tester overnight.  I'll update with my findings tomorrow.

  • 0 in reply to Alexander Fickle
    TI__Intellectual 2115 points

    Hi Alexander,

    Also be aware that for the first few hundreds milliseconds after boot the device is using an LF clock derived from HF clock running at 31.250kHz, and it will switch to the user selected LF clock only once it the crystal has stabilized. Therefore it will be interesting to see if you record this inaccuracy only at boot or over an extended period of time.

    Regards,

    Fausto

  • 0 in reply to Fausto C
    Prodigy 10 points

    Switching SET_CCFG_MODE_CONF_SCLK_LF_OPTION  to use the HF clock source worked.  There was no measurable clock drift over several hours of my tester running.

    For full context the cc1312 in my project was given a timestamp several seconds after it booted.  It then was expected to generate timestamps for events using a time offset generated by this timestamp and Clock_getTicks() (with care to mitigate tick timer overflow that occurs after ~12 hours).  Due to the misconfiguration of SET_CCFG_MODE_CONF_SCLK_LF_OPTION these timestamps were drifting consistently by 4% over the course of several hours of uptime.  This drift is most likely caused by the Clock module not being aware that the LF clock was running at 31.25kHz instead of at the 32.768kHz that it would be running at under the value of the SET_CCFG_MODE_CONF_SCLK_LF_OPTION if the external LF oscillator was actually placed as it should have been.  Not lying to the Clock module by using a valid value of SET_CCFG_MODE_CONF_SCLK_LF_OPTION  for our board layout solved the issue.

    Thanks for the help in solving this issue!