• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 51 subscribers
  • Views 123 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.

LAUNCHXL-CC26X2R1: gptimer checkbox in sysconfig

kazola
Guru 18625 points

Part Number: LAUNCHXL-CC26X2R1
Other Parts Discussed in Thread: SYSCONFIG

Hi all,

I am trying to create a square wave with 20 ms period.

I am using a timer from Sysconfig. I did NOT check the "use GPTimer" checkbox.

My current timing is a bit off, we can see some cycles being 19.9 ms or 20.1 ms.

So, my question is twofold:

  1. Should I check the GPTimer box? Will it increase precision?
  2. Since I guess it is derived from 48 MHz, when I stop() such timer, will my design be allowed to go to low-power mode? or do I need to specifically close() it.

Thanks a lot and have a nice day.

  • 0
    TI__Guru**** 223167 points

    Hi kazola,

    Your relevant E2E thread for my reference:  LAUNCHXL-CC26X2R1: about timer precision in cc26x2r  

    Here is the Timer.h TI Driver API documentation.  The Timer module will use GPTimer regardless, you can see this from the <sdk_install_directory>\source\ti\drivers\timer\TimerCC26XX.c file.  The "use GPTimer" checkbox refers to whether higher-level Timer.h or direct GPTimer.h APIs are used.  Either option will require 48 MHz and active power consumption when operable, and the device should be able to enter standby only if these instances are fully closed (see the GPTimerCC26XX.c file) and no other power dependencies exist.

    I'm rather partial to using ClockP as this allows for device standby power consumption while the Clock is operating, and the timing has been accurate according to my needs.

    I don't have an explanation for the timing being off, especially given that the resolution is low, without the code implementation.  Perhaps your interrupt to toggle the GPIO is being delayed by another HWI but this wouldn't account for the undershoot (19.9 ms).  Are you using default LaunchPad hardware and have you tried testing across different devices?

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Guru 18625 points

    Hi Ryan,

    OK so to go into low-power I need to stop + close.

    I also liked ClockP when I tried it. Should it give me more precision than Timer? I saw quite the jitter when activating the persistence option in the oscilloscope. Isn't ClockP precision bound by the quality (50 ppm) of the crystal oscillator? As you say is not too demanding.

    I will try again with a frequency counter.

  • 0 in reply to kazola
    TI__Guru**** 223167 points

    I do not think ClockP should be more precise than the Timer/GPTimer, which is why further investigation into the code solution would be necessary to understand more about the inaccuracy.  A logic analyzer could be useful here as well.

    Regards,
    Ryan