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.

Linked Concerto ePWM TBPRD Registers Problem



In our system, we are using the Concerto C28x's ePWM7, ePWM8, ePWM9, and ePWM10 together to drive a buck/boost DC converter.  I have linked the TBPRD of #8, #9, and #10 to #7 using the following:

 

    EPwm8Regs.EPWMXLINK.bit.TBPRDLINK = 8;      // link TBPRD to ePWM7

    EPwm9Regs.EPWMXLINK.bit.TBPRDLINK = 8;      // link TBPRD to ePWM7

    EPwm10Regs.EPWMXLINK.bit.TBPRDLINK = 8;     // link TBPRD to ePWM7

 

I change ePWM7’s value using the following:

 

    EPwm7Regs.TBPRDM2.half.TBPRD = <new value>;    // Set timer period for ePWM7-10 (use TBPRD Mirror)

 

I am observing (via the Code Composer’s Registers View) that the TBPRD register of ePWM8 & ePWM 9 (I am not concerned with ePWM10 at this time) does indeed follow the value written to the ePWM7 TBPRDM2 register.  Also, that new value is always reflected in the ePWM8’s TBPRDM register contents displayed in CCS.  However, intermittently, ePWM9’s TBPRDM does not get updated with the new value, but instead, retains the previous value.  When this occurs, ePWM9’s outputs operate incorrectly;  they output a steady state value instead of a modulated signal.  After that, writing a new value to ePWM7’s TBPRDM2 appears to make things right again, and ePWM9’s TBPRDM displays the correct value, and ePWM9’s outputs are modulated again.

 

Simply stated, the linking of ePWM9's TBPRD to ePWM7's TBPRD results in intermittent problems in ePWM9 when ePWM7's TBPRD value is modified.  The operation is usually successful, but often not.

 

Again, even though ePWM8 and ePWM9 are configured almost identically (except for the TBPHS reg and TBCTL:PHSDIR bit), the ePWM8 TBPRD link always appears to work correctly, but ePWM9 behaves intermittently in the scenario described above.

 

Is there some issue with writing to the TBPRDM2 register vs writing to the TBPRDM register?  I’m not really understanding the difference between them.

 

Thanks,

Chuck

  • Hi Chuck,You seem to have configured everything right.
    Just a few checks/clarifications will help:
    1. Does the failing behavior last only for one PWM cycle or continuously till a new PRD value is written?
    2. Are you using shadow load mode for the PRD register updates or immediate mode?
    Hrishi
  • Hi Hrishi,

    1)  The failing behavior is continuous.

    2)  I am using the shadow load mode.  (PRDLD = 0)

    Here is some other pertinent info to add:

    Our design requires that the output of the 3 linked PWMs (7,8,9) be 120 degrees out of phase with eachother.  To accomplish this, I am setting the TBPHS value of ePWM8 and ePWM9 to the appropriate values each time I change ePWM7's TBPRD value,  When the undesired behavior occurs on ePWM9, I observe (using the CCS Registers view) that its TBCTR value appears to count up starting from the stored TBPHS value to a value that is well beyond TBPRD, and then back to the TBPHS value, never getting low enough to reach the CMPA value.  Shouldn't the TBCTR always count from 0 to the TBPRD value?

    Thanks,

    Chuck

  •  

    Changing PWM Period.pdf

    Chuck,

    You are probably using the sync mechanism to synchronize PWM modules and maintain constant phase shift with changing frequency. When changing frequency, the PRD register for each of the PWMs should be written at an appropriate point in time before that PWMs shadow to active load event (typically, CTR = 0). Please refer to attached drawing for a 4 phase system using 4 ePWM modules.


    In your case, it looks like you have captured the failure behavior when the PRD value is reduced. It is possible that in your code the write to the linked PRD register is occurring after PWM9 CTR = 0 (shadow to active load event) and before the sync event. Therefore PWM9 could still have the old PRD register as its active value but a new TBPHS value is used at every sync event. This sync event is being generated by PWM7/8, whose new PRD is less than the PRD value in PWM9’s active PRD register. This means that before a CTR = 0 event (shadow to active load) can be reached for PWM9, its counter is getting reloaded by the TBPHS register. Thus PWM9 behavior never gets corrected.


    You have two possible options to solve this problem. You can write to the PRD register for PWM9 before its CTR=0 event or you could use ‘load on sync’ feature, which allows the shadow to active load of registers to occur on a sync event.


    I hope this helps.

    Hrishi

  • Hi Hrishi,

    I did not know how to implement your first option because I'm not sure how to guarantee a write to the PRD register before it's CTR=0 event (could you explain how to do that?), so I tried your second option as follows:

    PWM7:TBCTL:PRDLD = 0 (shadow-to-active load of PRD at CTR=0)
    PWM8:TBCTL:PRDLD = 1 (shadow-to-active load of PRD based on TBCTL2:PRDLDSYNC)
    PWM8:TBCTL2:PRDLDSYNC = 2 (shadow-to-active load of PRD at sync event)
    PWM9:TBCTL:PRDLD = 1 (shadow-to-active load of PRD based on TBCTL2:PRDLDSYNC)
    PWM9:TBCTL2:PRDLDSYNC = 2 (shadow-to-active load of PRD at sync event)

    This seems to correct the problem. However, I am concerned about the possibility of the sync event happening in the middle of setting up the new TBPRD and TBPHS values. Should I write the PWM8 and PWM9 TBPHS values before or after writing to PWM7's TBPRD, or doesn't it matter?

    Thanks,

    Chuck
  • Chuck,

     

    You can guarantee a write to PRD register before CTR = 0 by executing the write from inside a PWM ISR, triggered as shown in the attachment. When changing PWM frequencies, it is best to update PWM registers from a PWM ISR synchronous to the switching cycle instead of changing it from an asynchronous (slower) loop. If you do not want to continuously run the PWM ISR every switching cycle (for CPU bandwidth reasons), you can decide to enable it just when a change in frequency is commanded and then disable it once the registers are updated from inside the ISR.

     

    This is also a way to guarantee that PWM sync will not happen in the middle of writing to PRD register.

     

    I hope this helps.

     

    Hrishi

     

  • Hi Hrishi,

    I configured PWM7 to generate an interrupt when CTR=0, and inside the ISR, I now write PWM7's TBPRD, PWM8's TBPHS, and PWM9's TBPHS. However, I still write the CMPA registers asynchronously, as I always have. Now, the PWMs all switch frequencies properly, but the output duty cycle is wrong. When I break inside the ISR, I see that the CMPA register holds the correct value for the current frequency, but CMPAM still holds the value that is valid for the other frequency. As configured, the CMPA registers should be loading from the shadow at CTR=0 for each PWM, but I don't see why the part is behaving this way.

    Any ideas?

    Please ignore this latest reply;  I discovered that my test code was not set up as I described.
     
    Thanks,
    Chuck

  • Chuck,

    Thank you for the update. I am glad this is working now.

    Hrishi