• State Answer Suggested
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 52 subscribers
  • Views 326 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.

Problem measuring short time differences with beta GPTimer/PWM drivers

Benjamin Foote
Intellectual 700 points

Hello fellow BLE devs,

I'm writing because I'm having an issue with the beta GPTimer/PWM drivers that I find kind of odd. I'm using the PWM driver to drive an ultrasonic transducer to measure distances, and need to be fairly precise with the time differences coming back. What I'm finding is that measuring the input times using the GPTimer driver seems to lump them into 30uS buckets (which would indicate that the GPTimer driver is running at the 32kHz RTC rate instead of the full 48Mhz.) Has anyone else encountered this? And if so, what are some potential solutions or remedies?

I've capture 2 oscillograms that show pulse differences of 500uS and 503uS, but both of them consistently report the same GPTimer reading. I've run this test many times, and see the same thing. Really weird if you ask me, considering the GPTimer should be working at the full clock rate.

Here are the oscillograms:

Thanks for all the help as usual guys!

-Ben

PS - I'm  not sure it helps, but I'm willing to share all my code to get this looked at - I'm really at my wits end. Let me know!

  • 0
    TI__Guru 56075 points
    Hi,
    can you post your code snippet? GPTimer only runs on sclk_hf so what you are seeing if pretty weird. Which TI-RTOS version are you using?
    Are you using BLE stack as well? If you are not using(don't need) BLE stack, then you can directly move to TI-RTOS 2.20 which has official release of PWM/GPTimer driver.
  • 0 in reply to Christin Lee
    Intellectual 700 points
    I'm an idiot.

    I had POWER_SAVING defined, which was allowing the processor to go to sleep an add additional overhead in the sleep/wakeup process. This gave the illusion that there were problems with the GPTimers, but it wasn't real.

    I re-ran my tests with POWER_SAVING disabled, and everything is spot on.
    Thanks for the help though Christin.
    -Ben