• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 2 answers
  • Subscribers 84 subscribers
  • Views 972 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.

TMS320F28377D: HRPWM Not Working Properly Near CMPA Changes

Lance Hummel
Intellectual 960 points
Part Number: TMS320F28377D

Hi all,

I am working on a PWM converter design using the 28377D to implement the modulator.  A coworker and I noticed that in some cases, in some regions the response from the HRPWM module isn't correct.  We observed the CMPA and CMPAHR registers and saw that the CMPAHR value was increasing as expected.  On a high speed digital oscilloscope we measured the width of the pulse and observed how the pulse width changed with increases in the CMPAHR register.  We observed that for several sets of valid CMPAHR counts, the duty cycle was unchanged until the microcontroller hit a change in the coarse CMPA register value.  Is this a known issue with the HRPWM modules, or is there something wrong with the hardware we are using?  Any possible help or guidance would be appreciated.  Losing substantial PWM resolution isn't great and could cause our converter to potentially limit cycle, leading to noise, which we are trying to avoid. 

Thanks,

Lance Hummel

  • 0
    Intellectual 960 points
    Hi all,

    To add some additional information, I have observed the HRPWM module output, and I created a loop to test the module, and I noticed that the peripheral works fine with values of up to 64*256 in the CMPAHR register, however once that value is exceeded, the PWM output no longer shows any fine adjustment to pulse width. I am using the SFO and the MEP_Scalefactor is typically in the range of 65-67 which ultimately leads to the dead spots in the pulse width response. I am operating the converter at 250kHz, and the converter is interleaved with 4 separate phases with synchronous rectification. If there is any more information needed that may be useful please let me know.

    Lance
  • 0 in reply to Lance Hummel
    Intellectual 960 points

    Here is some data that was captured showing the issue.  We incremented the HRPWM upper 8 bits of CMPAHR register and measured the duty cycle on a high speed oscilloscope and averaged the waveform.  The orange line is the change in the duty cycle for each increment of the CMPAHR register value.  When the MEP no longer works the differential plot in orange goes to near zero.  As can be observed, the measured duty cycle does NOT increase for a value above 63, even though the condition is valid for the number of MEP steps.  There is some measurement noise, which can be reduced by averaging more samples, but this data using 64 averaged points shows the general trend well enough, that the pulse width isn't increasing even though it is being programmed to do so.

    Lance

  • 0 in reply to Lance Hummel
    Intellectual 960 points
    As an additional point of information, I ported my 28377D code to run on a 28377S micro, and that device produced an MEP_Scalefactor of 69, and it stopped working above a CMPAHR count of 66. It appears that based on testing multiple devices, the nonlinearity occurs 3 counts below the MEP_Scalefactor that the SFO returns. I couldn't find anything in the documentation that would indicate this is the expected operation, but I thought I would share.

    Lance
  • 0 in reply to Lance Hummel
    TI__Genius 10820 points

    Hi Lance,

    Sorry for the delay.

    Let me make sure I understand the problem. What you are seeing is that when the MEP scale factor returned by the calibration routine is 65, the CMPAHR values don't have any effect once they are increased above 65*256?

    This behavior seems to suggest that the HRCNFG[AUTOCONV] bit has not been set in the PWM configuration. Once you set this bit, you should be able to write to the CMPAHR register from 0 to 0xFFFF and see a linear response throughout the range.

    Please let me know if this is not the case or if I have missed something here.

    Thanks.

    Hrishi

  • 0 in reply to Hrishi Nene
    Prodigy 10 points

    Hi Hrishi,

    The problem was a bit more complicated than that.  During the tests above autoconv bit was indeed set to 0 but that was on purpose.  If the autoconv=0 and MEP_SCALE_FACTOR = 67, we should see a linear delay response all the way up to 67x256 in the CMPHR register but we were typically seeing that the last few counts (a range of 57-63, depending on the PWM module) did produce additional delay.

    We found the problem to be fixed when we changed the MEP modulation to the rising edge of the CMPA signal (away from the end of the period where it was previously) and the problem fixed itself.  We were attempting to use the HRPWM system right at COMP0 event (we are using the down ramp scheme).  Switching the HRPWM edge to the rising edge meant that we had to invert the polarity of the MEP counts. Unlike the coarse counts, where higher counts mean wider duty cycle, in the HRPWM, higher MEP counts mean narrower duty cycle, so we have add some simple math to take care of that.  We also enabled the autoconv bit to save some computation time.  

    Thank you,

    Peyman.