• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 31 subscribers
  • Views 191 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.

Original question:

Capture Timer with MSPM0G3507 messures periodic signal not correct

MSPM0G3507: PWM duty cycle capture issue

deven athavale
Prodigy 30 points

Part Number: MSPM0G3507

Tool/software:

Need to capture duty cycle of input PWM signal having frequency of 400Khz. For this I have used existing example  timx_timer_mode_capture_duty_and_period_LP_MSPM0G3507_nortos_ticlang with following change 

1. CPU Clock Frequency change to 80Mhz with sysclk

2. Capture module and PWM module uses 80Mhz clock 

Issue 

duty cycle calculation is coming as 117value for input PWM signal frequency 400Khz and Duty cycle set to 60  

CPU clock 

Capture module 

PWM module 

output

  • 0
    TI__Expert 6255 points

    Hey Deven, thanks for reaching out. Let me replicate this on my side and I will look at how to resolve the issue. I will keep you updated!

    -Brian

  • 0
    Guru 101915 points

    With a 80MHz CPU clock and 400kHz signal, the PWM period is 200 CPU clocks, which sounds like a lot but it goes fast (particularly with 2 wait states). With a 50% duty cycle, you need to fetch CC[0] (really, re-load the CTR value) within 100 CPU clocks, which is somewhat tighter. 

    Getting a value of 117(%) with PwmPeriod = 35 means the measured delta was 41, which suggests 100 clocks was not enough to reach the setTimerCount() call, and there was another capture in the meantime.

    Suggestions:

    1) Experiment: Slow down the input PWM -- say double or triple the period -- and see if you get more reasonable readings.

    2) If you haven't already, try increasing the optimization (-O) level. My observation was that with -O0 many/most of the "inline" functions turn into library calls, adding considerably to the low-level run time.

    3) Fetch CC[0] as well as CC[1] in the ISR. Separating the two fetches by that much invites a (different sort of) race.

  • 0 in reply to Bruce McKenney
    Prodigy 30 points

    1. At slower PWM frequency Like 400 hz PWM duty cycle logic works fine 

    2. Increasing optimization level did not help any random values are coming in dutycycle variable 

    3.  fatching CC0 and CC1 inside the ISR did not help 

  • 0 in reply to Bruce McKenney
    Prodigy 30 points

    1. At slower PWM frequency Like 400 hz PWM duty cycle logic works fine 

    2. Increasing optimization level did not help any random values are coming in dutycycle variable 

    3.  fetching CC0 and CC1 inside the ISR did not help 

  • 0 in reply to deven athavale
    Guru 101915 points

    You may be reaching the limits of this MCU+firmware. If you have some time, you can try fine-tuning the PWM frequency to see what your actual limit is.

    Longer term, you might be able to do something with DMA, but that's beyond the scope of this particular Example.

    In either case, you'll need to deal with the result stream at its arrival rate, which (still) gives you only 200 CPU clocks per measurement for everything you want to do with it.