• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 82 subscribers
  • Views 504 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.

TMS320F280039C: TBPRDHR calculation in up-down count

Wayne Huang
Genius 15745 points
Part Number: TMS320F280039C

Dear Champs,

I am asking this for our customer.

In 20.15.1.5.4 High Resolution Period, it says, for up-down count, 

Step 1,

100MHz/175KHz = 571.428

So, for up-down count,

TBPRD = int(571.428/2) = 285

For TBPRDHR, 

=frac (571.428) << 8
=0.428 × 256

However, we are confused why TBPRDHR calculation is same between up-count and up-down count?

Why isn't it like this?

TBPRDHR = frac (571.428/2) * 256 = 0.714 * 256

That is, since up-down count is symmetric and TBPRD is defined as the middle point of the real PWM cycle, why doesn't TBPRDHR calculation have /2 in this case?

Would you please clarify and confirm it?

 

  • 0
    TI__Genius 9261 points

    Hello Wayne,

    As far as I am familiar with the TBPRDHR functionality, the calculations to determine this value are independent of up-down-count vs up-count mode. To determine TBPRDHR, determine the fractional remainder based on the original calculated period, not the TBPRD integer value.

    Regards,

    Jason Osborn

  • 0 in reply to Jason Osborn
    TI__Genius 15745 points

    Dear Jason,

    Would you please confirm this again?

    From my testing on TI F280039C control card, it seems /2 for TBPRDHR provides better accuracy.

    In my test case,

    Case 1: Follows TRM, that is, using /1 for TBPRDHR

    EPwm1Regs.TBPRD = 342; // 120M/175K = 685.7143

    EPwm1Regs.TBPRDHR = 182 << 8; // 0.7143 * 256

    Case 2: using /2 for TBPRDHR

    EPwm1Regs.TBPRD = 342; // 120M/175K/2 = 685.7143/2 = 342.8571

    EPwm1Regs.TBPRDHR = 219 << 8; // 0.8571 * 256

    (That is, I put HRPWM_setTimeBasePeriod(ePWM[1], (uint32_t)compPeriod); where compPeriod = 120000.0/175/2 * 256).

    I found Case 2 is more accurate (closer to 175.0KHz) based on the oscilloscope mean measurement.

    OR do you have different result on your side?

  • 0 in reply to Wayne Huang
    TI__Genius 9261 points

    Hello Wayne,

    That's very good to know. I'll look into this further! In the meantime, just to confirm, do you have autoconversion enabled?

    Regards,

    Jason Osborn

  • 0 in reply to Jason Osborn
    TI__Genius 15745 points

    Dear Jason,

    Yes, autoconversion is enabled. SFO V8 library is also used in the background like our example.

  • 0 in reply to Wayne Huang
    TI__Genius 9261 points

    Wayne,

    Thank you for confirming. I'm currently looking into this further and will get back to you as soon as I am able.

    Regards,

    Jason Osborn

  • +1 in reply to Wayne Huang
    TI__Genius 9261 points

    Wayne,

    Thank you for your patience. I was able to confirm that you are correct, it is frac(final period), so period/2 for up-down count. Apologies for my previous mistake. If you have the time, please submit a document feedback request for this be clarified.

    Regards,

    Jason Osborn