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.

TMS320F28035: HRPWM in up-down count mode produces spurious pulse around TBCTR=0

Part Number: TMS320F28035

Tool/software:

Hello experts,

I have an application with type 1 EPWM running in up-down count mode, where pulse width has to be precisely controlled. Pulses have to be centered around PRD for synchronization purposes, so using up-count mode is problematic.

EPWMxA goes high on CMPA match counting up, and low on CMPA counting down. HRPWM operates on CMPA, falling edge only, since MEP can only delay pulse transitions. 

In up-down count mode, T_pwm = 2 * PRD * T_tbclk.

Because of the 2x multiplier, HRPWM autoconversion cannot work properly in this application: fractional part of CMPA represents a fraction of 2 * T_tbclk. When fractional part is 0.999999, I need 2*MEP_SCALE_FACTOR microsteps in CMPAHR, but autoconversion will produce 1*MEP_SCALE_FACTOR.

With autoconversion disabled, I do all the calculations in the code and write the 32-bit CMPA:CMPAHR register in one instruction.

The pulse width is set correctly and everything works as expected, except for one thing:

when CMPA:CMPAHR register is written, a spurious glitch appears around TBCTR=0. It is exactly one T_tbclk or one T_sysclk wide. The PWM then operates normally until next CMPA update. It seems like the glitch only shows up when coarse part of CMPA changes.

Both LOADAMODE and HRLOAD are set to load from shadow on PRD and ZERO, as per instructions on forums. Changing these settings has no effect - the glitch is always there when CMPA/coarse changes.

With AUTOCONV enabled, the waveform is clean, but fractional duty cycle is half of what it should be, because only the falling edge of the pulse is delayed and autoconversion is not accounting for up-down count mode.

With HRPWM disabled, the glitch does not appear.

Any suggestions?