• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 3 answers
  • Subscribers 82 subscribers
  • Views 819 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.

TMS320F280049: Testing HRPWM on F280049 Launchpad

Brian Wang0
Expert 5220 points
Part Number: TMS320F280049
Other Parts Discussed in Thread: C2000WARE

Hi team,

I am promoting F280049 for a customer demanding high frequency DC/DC solution (over 200k). In order to present the HRPWM performance of F280049, I am trying to perform some tests on F280049 launchpad based on the example code:hrpwm_ex1_duty_sfo_v8. And here is some strange findings.


The original code was a duty cycle sweeping demo. In order to show the duty cycle accuracy enabled HRPWM under high frequency, I changed it into a fixed frequency version. By changing the Line 201 into: 

for(DutyFine = 0x2000 ; DutyFine < 0x2001; DutyFine++)

First group test is under 10Mhz and here is the result:

Q15 Number Duty cycle Result
0x4000 50% 45.31%
0X4cc1 60% 54.36%
0x2666 30% Fault
0x2000 20% 19.80%

Question:

1. As shown in the result, I believe, the duty cycle accuracy did not meet the expectations. Since we support 150ps resolution, we should not have ~5% error under 10Mhz PWM. Could you help to explain if there is any misunderstanding?

2. As you can see, when I changed the dutyFine value into 0x2666 to achieve 30% duty cycle. I got a scope as below. Seems the PWM got high twice in a switching period. And this can be observed in the original example code where dutyFine = 0x3000.

The second group was tested at 1Mhz switching frequency.

Q15 Number Duty Cycle Result
0x4000 60% 59.38%
0X4cc1 50% 49.53%
0x2666 30% 29.74%
0x2000 20% 24.78%

Questions:

3. As you can see, the accuracy improved a lot.

However, if we look into detail, we can noticed when I set dutyfine=0x2000 for 20% duty cycle. I am always getting ~24% duty cycle which is very strange.

And your support is needed to help explain this.

Thanks,

Brian

  • 0
    TI__Expert 3720 points

    Hi,

    Can you please tell me which C2000Ware version you are using to do this evaluation. Because the default example had couple of bugs which are resolved in the latest C2000Ware release. I believe that you are getting huge error in duty due to this bug only :

    In the above configuration, '1' is not added to the TBPRD register value for computation. Thus it should be modified as :

    If my reply answers your question please click on "This resolved my issue" button located at the bottom of my post.

    Regards

    Himanshu

  • 0 in reply to Himanshu Chaudhary60
    TI__Expert 5220 points

    Hi Himanshu,

    I am using C2000Ware_1_00_06_00 and the +1 is indeed missed.

    However, after adding the +1 to the original code, I still cannot get the correct result. Still getting a 25% duty cycle PWM when dutyfine=0x2000.

    Did I misunderstood how the dutyfine should be calculated when given a duty cycle. For example, if I want to get a 20% duty cycle, how the get the correct dutyfine value?

    Thanks,

    Brian

  • 0 in reply to Brian Wang0
    TI__Expert 3720 points

    Hi Brian,

    For dutyfine = 0x2000, if you are getting 25% duty cycle then its correct right as 0x2000 represents 0.25 in Q15 format.

    For duty = 0.2, Q15 value is 0x199A, you need to use that as dutyfine.

     

    If my reply answers your question please click on "This resolved my issue" button located at the bottom of my post.

    Regards

    Himanshu

     

  • 0 in reply to Himanshu Chaudhary60
    TI__Expert 5220 points

    Hi Himanshu,

    After adding the +1 code to original example. The program can work normally now.

    However, this bring 2 addtion questions:

    1) Why we need this +1 to the right result?

    2) I went through the detailed code to calculate the value of CMPAHR:

        

    CMPAHR_reg_val = ((temp*MEP_ScaleFactor)+(0x0080<<7))>>15;
CMPAHR_reg_val = CMPAHR_reg_val << 8;
CMPBHR_reg_val = ((temp1*MEP_ScaleFactor)+(0x0080<<7))>>15;
CMPBHR_reg_val = CMPBHR_reg_val << 8;

      My question si why we need to add 0.5 (0x0080) to the result of CMPAHR？

    Regards,

    Brian

  • 0 in reply to Brian Wang0
    TI__Expert 3720 points

    Hi Brian,

    1) The actual value of period is the programmed (register value + 1). This is due to the factor that the counter starts from 0 and not 1, you can find further details around this in the device datasheet.

    2) 0.5 is added to take care of truncation error as in C by default the decimals are truncated and not rounded off while assigning to a integer variable. 

    If my reply answers your question please click on "This resolved my issue" button located at the bottom of my post.

    Regards

    Himanshu