• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 82 subscribers
  • Views 336 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.

TMS320F28P659DK-Q1: HRPWM - Trouble Understanding Operation of Example

Andrew McA
Prodigy 55 points

Part Number: TMS320F28P659DK-Q1
Other Parts Discussed in Thread: C2000WARE

Hi,

I've been having issues understanding the operation of the hrpwm_ex4_duty_updown_sfo example for F28P65x, SDK version 5.01.

The example seems like it should increment between 4% and 96%, with increments of 0.01%.

I see this generally working, although I see that when HR 8bit register rolls over from 0xFF to 0x01, that the duty cycle jumps 0.5%.

The example runs PWM at a Frequency of 505kHz, with TBPRD = 99, therefore i expect course PWM to have a duty cycle resolution of ~1%. I might be wrong here, but the HRPWM should then be able to achieve 1%/255 (8bit register), which equals 0.0000396%?

 

The table below shows some measurements i have collected using an oscilloscope, with timebase period equal to 100. I am manipulating the CMPA register using the debugger.

CMPA

HR (8bit)

Duty Cycle

  

CMPA

HR 

(8bit)

Duty Cycle
71 1 28.53%   70 1 29.54%
71 128 28.28%   70 128 29.29%
71 255 28%   70 255 29%

As shown above when CMPA = 71 and HR reg = 1, duty cycle equals 28.54%. When CMPA=70 and HR reg = 255, duty cycle = 29%, therefore there is a gap of 0.5% that the HRPWM is unable to achieve?

I have also tested this with hrpwm_ex1_duty_sfo, and i see the same thing, although timebase period and duty cycles are different.

 

Another thing that confuses me is that the frequency of PWM is 505kHz, which uses TBPRD=99, but the counter compare is calculated using a TBPRD=100. Why is this? Why do I not seem to need to do this for non-HRPWM up-down count PWM?

 

Many Thanks,

 

Andrew

 

  • 0
    Prodigy 55 points

    Hi,

    I was able to correct the behaviour by increasing PWM Clock from 100MHz (default of example) to 200MHz. Does this seem correct?

    On the last question - I've been able to replicate the desired behaviour in a demo application I created, but I just wanted to check that the following is correct:-

    Configuration

    • 10Mhz PWM Frequency
    • Up-Down Count Mode
    • 200MHz ePWM Clock

    Therefore I have configured TBPRD as 10-1 - Gives me 11MHz Frequency ( not what I want) - so I increase TBPRDHR to 0xFF - which creates 10Mhz frequency I want.

    CMPAHR register is calculated using TBPRD value of 10.

    I am not able to see expected duty cycle control if TBPRD is 10 (instead of 10-1) - does this seem correct or does this sound like a misconfiguration on my part?

    All in all - If you want HRPWM control of duty cycle, will this affect Frequency - which you then need to account for with TBPRDHR register?

    Many Thanks,

    Andrew

  • 0 in reply to Andrew McA
    TI__Prodigy 260 points

    Hi Andrew,

    Apologies for the delayed response.

    Yes your configuration looks good with the 200M clock. When using HRPWM duty cycle control, the frequency is slightly affected, and you MUST use TBPRDHR to compensate and maintain your target frequency. The HR period extension (TBPRDHR) and HR compare extension (CMPAHR) work together — TBPRDHR corrects frequency while CMPAHR provides fine duty control .


    Few things to correct.

    The MEP subdivides a single 10ns clock cycle (at 100MHz) into ~150ps steps, yielding approximately 66 usable MEP steps per clock cycle. The SFO library calibrates this count and stores it in HRMSTEP. The 0.5% jump occurs because the duty cycle resolution is bounded by the MEP scale factor (~66 steps), not the full 255-count register range


    I highly recommend you use the latest C2000ware(V6.01) which has SFO corrections which might mitigate these issues.

    Best Regards,

    Prajwal