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.
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?
Hello,
Please allow another day for me to look into your inquiry. Appreciate your patience!
Best Regards,
Allison
Hello,
Thank you for the helpful diagram! I'm still looking into this. Am I correct in saying that you only see this after you are changing your CMPA value? And you are updating your CMPA using CLA right before the CTR = 0 (when the new CMPA value should be loaded)?
Best Regards,
Allison
Yes, the glitch only occurs when CMPA:CMPAHR is written, but if the CMPA part is the same as before, the glitch does not occur.
Also, only happens with AUTOCONV disabled.
Anyhow, I found an old forum thread describing this issue, and it looks like someone has found an undocumented way of doing it:
I've made these changes, and verified that HRPWM operates as expected - both edges placed using micro-positioner.
Hi Pavel,
Glad to hear you were able to resolve it! I'll look into if we should add anything to our documentation for this.
Best Regards,
Allison