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.

TMS320F2809: HRPWM issue

Part Number: TMS320F2809


Hi,

I'm working with the TMS320F2809 microcontroller and I have some question about the HRPWM module.

First of all, I tried the Example_280xHRPWM_SFO_V5.c. It seem's to bo working.

In my case, I'm using the TBPHS instead of CMPA register.

I read the datasheet spru924f, more exactly in page 15/42. We can see how to calculate both registers.

So, if we follow this example :

1)

MEP_ScaleFactor = 55

PWMDuty = 99,1896/180 = 0,551053

PWMperiod = 715

CMPA = PWMDuty*PWMperiod = 394

CMPAHR = (frac(PWMDuty*PWMperiod)*MEP_ScaleFactor +1.5) << 8) = (frac(0,551053 * 715)*55 +1.5) *256) = (0,0031333*55 +1.5) *256) = 428 = 0x1AC (lower 8 bits will be ignored by hardware) 

CMPAHR = 0x100 = 256

(*ePWM[i]).CMPA.all = ((long)CMPA_reg_val)<<16 | CMPAHR_reg_val; = 394*65536 + 256 = 25821440

2)

MEP_ScaleFactor = 55

PWMDuty = 99,1882/180 = 0,551045 (this angle is the nearest from the 1) example)

PWMperiod = 715

CMPA = PWMDuty*PWMperiod = 393

CMPAHR = (frac(PWMDuty*PWMperiod)*MEP_ScaleFactor +1.5) << 8) = (frac(0,551045 * 715)*55 +1.5) *256) = (0,9975722*55 +1.5) *256) = 14429 = 0x385D (lower 8 bits will be ignored by hardware) 

CMPAHR = 0x3800 = 14336

(*ePWM[i]).CMPA.all = ((long)CMPA_reg_val)<<16 | CMPAHR_reg_val; = 393*65536 + 14436 =25770084

The difference between these two points makes me some trouble. (25821440 - 25770084= 51356).

I implemented these equation on Excel. My duty is linear but CMPA.all is not. May be it's normal.

But in my case, I can see a gap with the duty when there is a change in CMPA register.

Below an evolution of CMPA.all register in function of the angle (duty).

In red this is exactly what it's written in the datasheet.

We can see the gap I'm talking about and I can see it in my system.

Is there any explaination?

Thank you so much

PWMDuty
  • Alexandre,
    sorry for the delay during the holiday season. I am looking into this one and will post back here in the new year.

    Regards,
    Cody
  • Hi Cody,

    Happy new year.

    Have you got some explanation for me?

    thank you

  • Alexandre,

    I am a little confused by your question, lets focus on the TI solution first. In your graph I see a large jump between 25850000 and 25900000, is this a problem for you system? Could you label the graph, this will make it easier to read?

    Are you running the SFO periodically?

    It looks like you are trying to use the HRPWM for Duty control, is this correct?

    Regards,
    Cody 

  • Cody,

    "In your graph I see a large jump between 25850000 and 25900000, is this a problem for you system?"

    Yes it is. Because this jump makes me some trouble.

    "Could you label the graph, this will make it easier to read?"

    Of course I can. The red graph is the TI's example. The Y axis is the (*ePWM[i]).CMPA.all register and the X axis is the angle (0 to 180°). If you want it, this angle can be converted to a duty (divide angle by 180).

    "Are you running the SFO periodically?"

    The "SFO_MepDis_V5" is called at the initialisation function as it's said on the example.

    The "SFO_MepEn_V5" is called sometimes in the main loop (between 30µs & 60µs).

    But in fact, my project is not working properly but the examples too. Due to this jump.

    Best regards.

  • Alexandre,

    1. What example isn't working?
      1. What CCS version are you using?
      2. What compiler version are you using?
    2. Do you see this issue on one device or many?
      1. Have you replicated this issue on another device? If not, can you include the compiled .out file? I will see if I have an f2809 device I can test it on.

    Regards,
    Cody 

  • Cody,

    1. What example isn't working? I used "Example_280xHRPWM_SFO_V5". In fact this is working but the jump in the register can be clearly seen in the real duty.
      1. What CCS version are you using? I'm using CCS Version: 5.5.0.00077 
      2. What compiler version are you using? I'm using the TI v6.2.0
    Do you see this issue on one device or many? Just one because my application must run on f2809
    1. Have you replicated this issue on another device? If not, can you include the compiled .out file? I will see if I have an f2809 device I can test it on.

    Nope I can"t replicated it on another device.

  • Alexandre,

          when I said "have you replicated this issue on another device?" I meant do you see this issue on more than one F2809 device?

    My thought was, maybe your device has been damaged some how causing the issue we are seeing.

    Can you send me the .out file for the example code? I will try to run your code on a F2809 device so we can tell if this is a hardware or a software issue.

    Regards,
    Cody 

  • Cody,

    oh sorry!

    Yes, I tried it on different board which contains the F2809 device.

    I attached the example I've modified but I'm not sure it can be helpful.

    RegardsExample_280xHRPWM_SFO_V5.zip

  • Alexandre,

    Are you still working on this issue?

    I was able to execute your code. I placed a breakpoint on line 311"(*ePWM[i]).CMPA.all = ((long)CMPA_reg_val)<<16 | CMPAHR_reg_val;" and then measured the PWM's pulse width, ran the code, then again checked the pulse width. I was able to see roughly even steps with no discontinuity as you have shown in the graph until the code looped back from its maximum width to its minimum width. I stepped through this several times and was able to note once or twice that the pulse width did increase by a value that was less than expected, but i did not see an extended period where there was not change in the pulse width. At this time I do not have an explanation for this, but it may have been due to instrumentation limitations.

    Regards,
    Cody 

  • Cody, 

    I still have this issue but I have no more time to solve it.

    So, I found a "solution". I added a x4 for the HR register when we used the x MEP_ScaleFactor.

    I'm not able to explain why it is better, but it seems to do the job.

    Thank you for your explaination.

    Best regards,

    Alexandre

  • Alexandre,
    adding the 4x will certainly smooth out the discontinuity you are seeing. If another solution comes to me I will be sure to let you know.

    Regards,
    Cody