Other Parts Discussed in Thread: C2000WARE
Using LaunchPad for experiments and existing Code as development starting point.
SFO() works, value written into EPwm1Regs.HRMSTEP.bit.HRMSTEP is 63; this is reasonably close to typical value of 67 based on PWM Clock 100MHz and typical MEP Step of 150pSec.
When utilizing Auto-Conversion (EPwm1Regs.HRCNFG.bit.AUTOCONV = 1), the resulting Voltage Command is clearly affected by fractional value in EPwm1Regs.CMPA.bit.CMPAHR, however the voltage is not continuous and has discontinuities close to points where the fraction is zero.
When avoiding Auto-Conversion (EPwm1Regs.HRCNFG.bit.AUTOCONV = 0) and calculating the value to enter into the High-Resolution Register CMPAHR, it is POSSIBLE to get Voltage Command that is continuous and consistent with expectation; however, the values that are entered into the CMPAHR Register are TWICE what is expected using the result from the SFO() Function. To illustrate:
1. DC Buss Voltage ~50VDC;
2. PWM Clock is 100MHz;
3. PWM Up-Down Counting, Period is 5,000, for a Triangular-Wave at 10kHz;
4. For Zero voltage between Motor Phases, the command at each PWM Output is 2,500;
5. To get 20mV between two Phases, one Phase would have EPwm1Regs.CMPA.bit.CMPA = 2,501 and the other Phase EPwm2Regs.CMPA.bit.CMPA = 2,499; for 40mV between two Phases set the values to 2,502 and 2,498; etc.
6. To get 30mV between two Phases, one Phase should have "1.5 PWM Counts" and the other Phase should have "-1.5 PWM Count"; represent that in "fractional notation", "EPwm1Regs.CMPA.bit.CMPA = 2,501.5" and "EPwm2Regs.CMPA.bit.CMPA = 2,498.5";
7. The values in EPwm1Regs.CMPA.bit.CMPAHR and EPwm2Regs.CMPA.bit.CMPAHR are expected to be about 8,192 in both (63 / 2 * 256);
8. However, these values cause INCORRECT Voltage between the two Phases, and the situation gets worse as different voltage commands are attempted, such as 20.5mV or 39mV (close to zero fraction points);
9. When calculating the fractional value as if the MSTEP calculation is 2 * 63 = 126, the result is continuous and accurate; thus the value of both CMPAHR Registers are 0.5 * 126 * 256 = 16,128.
10. It seems that the Auto-Conversion process gives the incorrect result BECAUSE it relies on the incorrect Micro-Step resolution as calculated by the SFO() Function.
What am I missing?
Another question: In the setup, only setting Rising-Edge-Positioning seems to have any effect. When setting "EPwmxRegs.HRCNFG.bit.EDGMODE = 2" there seems to be no effect of any value written into CMPAHR AT ALL.
Thanks, Alon Harpaz