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

CCS/CC1312R: Clock source for general purpose timer

David Snodgrass
Prodigy 40 points
Part Number: CC1312R
Other Parts Discussed in Thread: SYSCONFIG, , CC1120, CC1190

Tool/software: Code Composer Studio

How do I select the clock source for a GPTM, i.e., LF XOSC (external 32.768kHz crystal)? My timers are clocking at 48MHz by default.  I don't see an option for this in Sysconfig.

  • 0
    TI__Guru 58425 points

    Hi David,

    The GPTimer modules is clocked from the HF source only, it does not allow you to change to for example the LF clock. If you could elaborate on what you want to do then I could maybe propose a fitting solution for you.

  • 0 in reply to IUsedToBeARealPerson (M-W)
    Prodigy 40 points

    Thank you for your reply!

    A little background...

    Several years ago I developed a long range cluster-tree network based on the MSP430 and CC1120 (and CC1190 for hub/repeater devices).  I designed the CC1312R into a device I want to connect to this network.  This is a FHSS 915MHz network (Part 15.247).  In order for the CC1312R device to connect to my network, it needs to synchronize to the current channel (1 of 50) and the channel's remaining dwell time. Every 20 seconds, all hubs will send a sync message in one of eight randomly selected 50ms time slots on a dedicated channel.  To join the network, the device will listen on the dedicated channel until the first sync message is received.  The sync message contains the remaining dwell time (plus latency) of the current dedicated channel.  The dwell time (sent in the sync message) is the raw value of a 200ms MSP430 timer's TxR register, which is clocked by an external 32.768kHz crystal, i.e., a 2-byte unsigned value from 0 to 6553.  The 200ms timer will generate an interrupt, when expired, where the current channel index will be incremented.  Using the LF crystal to clock the timer and using the raw TxR register value in the sync message seemed like a nice universal way synchronize the network devices without having to perform any math on the register value.  I guess it was naive to assume that all TI MCU timers could, at least optionally, be clocked from an LF crystal :( 

    So, all of that being said, what are my options?  Can I use the RTC to generate a 200ms interrupt?  If not, I will just have to do some math on the received TxR register value to scale it to a 48MHz clock.

  • 0 in reply to David Snodgrass
    TI__Guru 58425 points

    Hi David,

    Thanks for sharing some background on your use case, it makes it a bit clearer what you are trying to achieve. Starting with the timer, there is multiple timers in the device but the timer you are looking at, the GPTimer, is only driven by the system clock (which happens to be 48 MHz).

    The RTC timer is always driven by the 32 kHz source and could be used for general timing in SW. This is actually what most of the examples provided for the CC13XX/CC26XX platform does. When using TI-RTOS, it boils down to using the "Clock" module which is a timer object based around the RTC clock:

    https://dev.ti.com/tirex/explore/content/simplelink_cc13x2_26x2_sdk_4_20_01_04/docs/tirtos/sysbios/docs/cdoc/ti/sysbios/knl/Clock.html

    Using this Clock module is one way to setup simple one-shot or periodic timers in the RTOS environment. Just remember that even tho it is driven by the RTC, the "tick value resolution" is given in 10us units. This means you would still need to scale the MSP value to 10us.

    Another feature on these Radio SoCs is that you can schedule your radio commands to the radio with timing information. Basically, you can issue a command and give it a start condition like "This should run in 200-x ms "FROM NOW" / "RELATIVE TO LAST"". There is of course more options here, also seen to end time, this was just an example.

    Another example:

    So say that you have set the CC1312 up in RX on a channel and you receive the "sync message" you are looking for and that your RX ends. You could then immediately schedule a new RX for the next channel index and configure the startTime to be "start X us from now". Where X is the received MSP counter value scaled to the Radio Access Timer (RAT) tick rate (there exists macros for this in the RF Driver).

    You could also use the radio timestamp feature to capture a RAT timestamp from when the package was received (sync found) and base your calculation on this which means you do not need to account for the internal processing delay when adjusting the dwell time. 

    Both the Radio and Clock approach is what I suggest you look closer at. Using the GPTimer would mean you basically force the device to stay out of standby which means the power consumption would be horrible. The Radio / Clock approach allows the device to optimize for power and go into standby when possible (handled automagically by the power driver in the system).