TMS320F28379D: High-Resolution PWM Control mismatch with SFO() result

Hi,

First of all thank you for posting a query with a very detailed analysis.

I presume, the value returned by SFO() in the EPwm1Regs.HRMSTEP.bit.HRMSTEP register would be accurate.

One way to check this would be to focus on just one of the PWMs.
Say, set the EDGEMODE to rising edge delay and set EPwm1Regs.CMPA.bit.CMPA = 2,501 measure the PWM output duty cycle.
Now change CMPA:CMPAHR = 2,501.5 and measure the PWM duty cycle.
Does the change in the duty cycle correspond to the value updated in CMPAHR?
If so, then the calculated HRMSTEP is accurate.

For your second question,
Since you are trying to use dual edge control (both rising and falling edge) - can you enable HRPE? You can use it with TBPRDHR=0 since you are not trying to change the frequency. This should have the desired effect on both edges.

Hello Subrahmanya,

Thank you for your reply.

Some of the questions that you asked are already answered in my original post...

To ensure full coverage of all possible configurations, I conducted several experiments, each with a different configuration.  The results are listed below.

In general:

1.  Since I have no access to a high-speed Oscilloscope, I monitored the Output using a Resistor-Capacitor Circuit that provided aggressive filtering of the PWM Voltage, measuring the voltage across the Capacitor only.  Using a 3.75 Digit DVM, I was able to monitor the Voltage at 0.1mV resolution; out of a 40VDC Buss, this is 1 / 400,000 resolution.

2.  PWM Clock is 100MHz, the Period Counter counts Up-Down (no Saw-Tooth waveform for PWM Control); Period is 5,000.

3.  Phase A is kept at 50% Duty-Cycle, Phase B is manipulated using both CMPA and CMPAHR; RC Circuit is connected between Phase A and Phase B.

4.  Voltage Command is given writing to motor1.VqTesting; CMPA and CMPAHR of all three PWM Outputs are monitored.

Experiments:

A.  Direct calculation of CMPAHR value, no High-Res. Period Enable:

EPwmnRegs.HRPCTL.bit.HRPE = 0

u16_HrStep = 126; // internal Variable to be used in HRPWM Calculations, value is twice the nominal estimate

PWM Calclations:
motor->PwmARegs->CMPA.bit.CMPA = u16_Pwm1 = (Uint16)((INV_PWM_HALF_TBPRD * motor->svgen.Ta) + INV_PWM_HALF_TBPRD);
motor->PwmARegs->CMPA.bit.CMPAHR = (Uint16)(((INV_PWM_HALF_TBPRD * motor->svgen.Ta) + INV_PWM_HALF_TBPRD - u16_Pwm1) * u16_HrStep * 256 + 0x0080);
motor->PwmBRegs->CMPA.bit.CMPA = u16_Pwm2 = (Uint16)((INV_PWM_HALF_TBPRD * motor->svgen.Tb) + INV_PWM_HALF_TBPRD);
motor->PwmBRegs->CMPA.bit.CMPAHR = (Uint16)(((INV_PWM_HALF_TBPRD * motor->svgen.Tb) + INV_PWM_HALF_TBPRD - u16_Pwm2) * u16_HrStep * 256 + 0x0080);
motor->PwmCRegs->CMPA.bit.CMPA = u16_Pwm3 = (Uint16)((INV_PWM_HALF_TBPRD * motor->svgen.Tc) + INV_PWM_HALF_TBPRD);
motor->PwmCRegs->CMPA.bit.CMPAHR = (Uint16)(((INV_PWM_HALF_TBPRD * motor->svgen.Tc) + INV_PWM_HALF_TBPRD - u16_Pwm3) * u16_HrStep * 256 + 0x0080);

Result - ~8.7mV for each PWM Count; smooth continuity between Integer values, down to available resolution.

B.  Direct calculation of CMPAHR value, with High-Res. Period Enable:

EPwmnRegs.HRPCTL.bit.HRPE = 1

u16_HrStep = 126; // internal Variable to be used in HRPWM Calculations, value is twice the nominal estimate

PWM Calculations as in Experiment A above.

Result - ~8.7mV for each PWM Count (as before); NO EFFECT of CMPAHR Content AT ALL.

C.  Auto-Conversion with SFO, no HRPE:

EPwmnRegs.HRPCTL.bit.HRPE = 0;

EPwmnRegs.HRCNFG.bit.AUTOCONV = HR_AUTOCONV_ON;

EPwm1Regs.HRMSTEP.bit.HRMSTEP = 63; (calculated by SFO())

PWM Calculations:
motor->PwmARegs->CMPA.all = (65536 * INV_PWM_HALF_TBPRD * (motor->svgen.Ta + 1));
motor->PwmBRegs->CMPA.all = (65536 * INV_PWM_HALF_TBPRD * (motor->svgen.Tb + 1));
motor->PwmCRegs->CMPA.all = (65536 * INV_PWM_HALF_TBPRD * (motor->svgen.Tc + 1));

Result:  ~8.7mV for each PWM Count (as before); Fractional values are off by a factor of two.  For example - setting 1/4 step causes 16,384 to be written in CMPAHR (as expected), BUT the resulting voltage difference from Integer value is 1.1mV (instead of ~2.2mV); setting 15/16 step causes 61,440 to be written in CMPAHR (as expected, BUT the resulting voltage difference from Integer value is 4.1mV (instead of ~8.2mV); etc.

D.  Auto-Conversion based on Estimate, no HRPE:

EPwmnRegs.HRPCTL.bit.HRPE = 0;

EPwmnRegs.HRCNFG.bit.AUTOCONV = HR_AUTOCONV_ON;

EPwm1Regs.HRMSTEP.bit.HRMSTEP = 126; (estimated from 2 * result from SFO())

PWM Calculations as in Experiment C above.

Result - ~8.7mV for each PWM Count; smooth continuity between Integer values, down to available resolution.

E.  Auto-Conversion with SFO, High-Res. Period Enable:

EPwmnRegs.HRPCTL.bit.HRPE = 1;

EPwmnRegs.HRCNFG.bit.AUTOCONV = HR_AUTOCONV_ON;

EPwm1Regs.HRMSTEP.bit.HRMSTEP = 63; (calculated by SFO())

PWM Calculations as in Experiment C above.

Result - ~8.7mV for each PWM Count (as before); NO EFFECT of CMPAHR Content AT ALL.

[Please note that Auto-Conversion based on Estimate (as in Experiment D above) with HRPE was not run, as it seems that setting HRPE completely disables High-Res. MEP anyway.]

Conclusions:

i.  HRPE somehow disables High-Res. MEP, regardless of other configuration settings.

ii.  The MEP value that gives the correct results seems to be twice the calculation results of the SFO() Function.

iii.  It is possible to utilize Auto-Conversion Setting "EPwmnRegs.HRCNFG.bit.AUTOCONV = 1", BUT an estimate for MEP which is twice the result from the SFO() Function has to be used.

Please review and comment.

Hi,


Would you be able to start with the example provided in C2000Ware

C:\ti\c2000\C2000Ware_2_00_00_02\device_support\f2837xd\examples\cpu1\hrpwm_prdupdown_sfo_v8

This project is for period control but you can use this for testing and not have High resolution period configured.

For controlling both the edges in Up-Down count mode, you've to have the HPRE enabled. Otherwise, both the edges will see same amount of fine delay and not effecting duty cycle. 
So, I wonder you may be missing some configuration related to HRPE, hence please refer to the example and cross check the configuration.
Ideally, it'll be good if you can test with the same example code, so that i can reproduce, if you are seeing any issue, at my end. 

Hi,

I'm adding more details upon receiving the note from FAE regarding clarification of the suggested example and need to enable HRPE.

1. Why HRPE is needed for your configuration-
You've stated that you are using up-down count mode and achieve duty cycle control. 
The only way this can be achieved is by enabling HRPE.
If HRPE is not enabled, as you have observed "applying HR MEP to both Rising-Edge and Falling-Edge would result in a Phase-Shift, which is NOT beneficial to PWM Duty-Cycle Control". Where as with HRPE enabled, symmetric duty cycle control can be achieved as the edges will now move in opposite direction - as needed in up-down count mode. Hence HRPE is needed for symmetric mode (Up-down) even when you are using this only for duty cycle control.

2. Why I suggested example hrpwm_prdupdown_sfo_v8 -
The other example hrpwm_duty_sfo_v8 intended to showcase duty cycle control (which you intend to use) is only using up-count mode. Not the up-down count mode. Where as the example I suggested hrpwm_prdupdown_sfo_v8 uses up-down count mode, though it is not actually configured for duty-cycle control. This example has all the configuration needed for dual edge control in up-down count mode (including HRPE enabled).
I totally understand that this is not the exact configuration you want but something you can start with, so that we are on the same page in case I need to reproduce the issue at my end. Since I do not have access to your complete PWM configuration - I was trying to suggest the best possible option among the available examples.
This would at least validate the theory of whether sfo() computations are accurate or not. One of your conclusions was "HRPE somehow disables High-Res. MEP, regardless of other configuration settings." - this can be validated by the above example.

Other 2 conclusions you've are interrelated. 
ii.  The MEP value that gives the correct results seems to be twice the calculation results of the SFO() Function.
iii.  It is possible to utilize Auto-Conversion Setting "EPwmnRegs.HRCNFG.bit.AUTOCONV = 1", BUT an estimate for MEP which is twice the result from the SFO() Function has to be used.

As of now, my understand still is that there is something missing in the configuration with HRPE enabled. If we can sort that our via example or some other means conclusions 2 and 3 would not be necessary.

Please let us know if you need any additional details.

Hello!

Thank you very much for your reply.  I will rephrase your comments here, please review and confirm or correct my understanding:

Setting "HRPCTL.bit.HRPE  = 1"would cause BOTH Edges of the COMPA-CMPAHR comparison to move, only when this Bit is set they move in OPPOSITE directions; therefore this Bit is required for Duty-Cycle Control with Up-Down Counting.

If this understanding is correct - does that mean that Edge-Mode has to be set to Both, such as "HRCNFG.bit.EDGMODE = HR_BEP"?

Please answer at your convenience; I will continue with experiments on Sunday next week.

Thanks, Alon Harpaz

Hi,

Alon Harpaz said:

If this understanding is correct - does that mean that Edge-Mode has to be set to Both, such as "HRCNFG.bit.EDGMODE = HR_BEP"?

Hello SubrahManya,

I attempted to follow your advice, using a configuration that is similar to the Code in hrpwm_updown_sfo_v8.c

I attached my Code here (nothing two original that would warrant secrecy) after I compared this Code to the Code in the file mentioned above There are no significant differences that I could tell.

The Configuration Function is called for all three ePWM Modules (1, 2, and 3) that are used as Motor1 PwmARegs PwmBRegs, and PwmCRegs, respectively; with parameters period = 10,000 and db = 5.

void PWM_1ch_UpDwnCnt_CNF(volatile struct EPWM_REGS * ePWM, Uint16 period, int16 db)
{
EALLOW;
// Time Base SubModule Registers
ePWM->TBCTL.bit.PRDLD = TB_SHADOW; //Shadow Load
ePWM->TBCTL2.all = 0; // Legacy settings - Period-Load at Zero, no Sync. Out, no One-Shot
ePWM->TBPRD = period / 2; // For Triangular Wave; PWM frequency = 1 / period
ePWM->TBCTR = 0; // Start at Counter Zero
ePWM->TBCTL.bit.CTRMODE = TB_COUNT_UPDOWN; // Triangular Wave (Up-Down Counting)
ePWM->TBCTL.bit.HSPCLKDIV = TB_DIV1; // High-Speed Clock Divider of 1
ePWM->TBCTL.bit.CLKDIV = TB_DIV1; // Clock Divider of 1.

// High-Resolution Period Control
ePWM->HRPCTL.all = 0x0; // Reset all Bits first
ePWM->HRPCTL.bit.TBPHSHRLOADE = 1; // Enable TBPHSHR sync (required for up-down count HR control)
ePWM->HRPCTL.bit.HRPE = HR_PRD_EN; // Enabled

ePWM->TBCTL.bit.PHSEN = TB_DISABLE; // Disable all Syncing, enable specific Modules in Configuration
ePWM->TBCTL.bit.SYNCOSEL = TB_CTR_ZERO; // sync "down-stream" on Counter at Zero
ePWM->TBPHS.bit.TBPHS = 0;
ePWM->TBPHS.bit.TBPHSHR = 0x0; // No HR for Time-Base Phase settings

// Counter Compare A Submodule Registers
ePWM->CMPA.bit.CMPA = ePWM->TBPRD / 2; // set duty 50% initially
ePWM->CMPA.bit.CMPAHR = 0; // initialize HRPWM extension
ePWM->CMPCTL.bit.SHDWAMODE = CC_SHADOW; // Shadow loading of CMPA
ePWM->CMPCTL.bit.LOADAMODE = CC_CTR_ZERO_PRD; // Load Shadow at ZERO and at PRD

// High-Resolution Configuration
ePWM->HRCNFG.all = 0x0; // Zero all Bits first
ePWM->HRCNFG.bit.EDGMODE = HR_BEP; // Control both Rising and Falling Edge Position
ePWM->HRCNFG.bit.CTLMODE = HR_CMP; // CMPAHR controls the MEP
ePWM->HRCNFG.bit.HRLOAD = HR_CTR_ZERO_PRD; // Shadow load on both CTR==ZERO & CTR==PRD

// Auto-Conversion for High-Res
ePWM->HRCNFG.bit.AUTOCONV = HR_AUTOCONV_ON;
// Initial value for Micro-Edge Positioning Step
ePWM->HRMSTEP.bit.HRMSTEP = 66; // Initial value only, overwritten by SFO().

// Compare-A Action Qualifier SubModule Registers
ePWM->AQCTLA.bit.CAU = AQ_CLEAR;
ePWM->AQCTLA.bit.CAD = AQ_SET;

// Active high complementary PWMs - Set up the deadband
ePWM->DBCTL.bit.IN_MODE = DBA_ALL; // Source A, both edges
ePWM->DBCTL.bit.OUT_MODE = DB_FULL_ENABLE; // Both Edges
ePWM->DBCTL.bit.POLSEL = DB_ACTV_HIC;
ePWM->DBRED.all = db; // porting change
ePWM->DBFED.all = db; // porting change
EDIS;
}

The Macro below is called for EPwm2Regs and EPwm3Regs, chaining their Sync. Sources to EPwm1Regs.

//-----------------------------------------------------------------------------
// PWM SYNCing MACRO
#define SYNC_EPWM(EPwmXRegs_Ptr) \
EPwmXRegs_Ptr->TBCTL.bit.SYNCOSEL = TB_SYNC_IN; \
EPwmXRegs_Ptr->TBCTL.bit.PHSEN = TB_ENABLE; \
EPwmXRegs_Ptr->TBPHS.bit.TBPHS = 0; \
EPwmXRegs_Ptr->TBCTL.bit.PHSDIR = TB_UP;
//-----------------------------------------------------------------------------

// configure Epwms B and C as slaves of A (EPWM highest up is chosen as A)
SYNC_EPWM(motor1.PwmBRegs);
SYNC_EPWM(motor1.PwmCRegs);

The PWM Generating Code is listed here (writing the full 32-Bit Wide result into CMPA ad CMPAHR simultaneously):
motor->PwmARegs->CMPA.all = (65536 * INV_PWM_HALF_TBPRD * (motor->svgen.Ta + 1));
motor->PwmBRegs->CMPA.all = (65536 * INV_PWM_HALF_TBPRD * (motor->svgen.Tb + 1));
motor->PwmCRegs->CMPA.all = (65536 * INV_PWM_HALF_TBPRD * (motor->svgen.Tc + 1));

When I operate the PWM Sources this way (using Build_Level1 of the LaunchPad Example Code), I get NO effect from any value written into CMPAHR at all; this is similar to my previous experiments, except that here (per your advice) the HRPE Bit is set and Auto-Convert is enabled.

Just to ensure that there was no matter of reversed polarity somewhere, I also checked the configuration as listed here with the Action-Qualifiers swapped; again, there seemed to be no effect of anything written into the HR Registers.

The theory of operation suggests strongly that some other setting is missing.  Can you fill me in please?

Thanks, Alon Harpaz

Hi,

Further to our discussion, I've gone ahead and tested the example project I suggested above.
I've loaded the hrpwm_updown_sfo_v8 and disabled UpdateFine - by writing UpdateFine=0. When I run this code it produces a fixed duty output.
Now, through the debugger window, I've modified the CMPAHR value and I do observe the duty cycle change as expected.
So, the duty cycle change, when HRPE is enabled, is happening as expected.
I tried multiple values of CMPAHR (0x8000, 0xC000, 0xAA00.... etc) and I do see the expected result.
I've also checked your configuration code you provided - and it seems to be correct as well.
At this stage i'm not sure why you are not observing the duty cycle changes.
Can you do this simple step as above and confirm your observation - before we start digging into your application code?

Hi,

Did you get a chance to check the duty cycle variation with the example as suggested above? 

Hello!

My apologies, I just got back to some experiments yesterday.  I am still in the process of setting up the SW/HW configuration so I can test the results within our limited resources (no high-bandwidth oscilloscope).

One thing which I already noticed - the SFO() result (as read from EPwm1Regs.HRMSTEP.bit.HRMSTEP is 130, which is roughly TWICE the value that was obtained with my setup, as based on the FCL_379XL Example Code.  Please note that this ALONE would be sufficient to allow me to operate the HRPWM with the Auto-Conversion feature and SFO() Calibration.

I am not sure what the cause for this difference is.  One thing which I noticed - the EPwm1Regs.HRPWR.bit.CALPWRON occasionally toggles '1' and back to '0'.  Is that part of the expected behavior?  Is there any significance to other Bits in that Register?

Thanks, Alon Harpaz

Hi,

Alon Harpaz said:

One thing which I already noticed - the SFO() result (as read from EPwm1Regs.HRMSTEP.bit.HRMSTEP is 130, which is roughly TWICE the value that was obtained with my setup, as based on the FCL_379XL Example Code.  Please note that this ALONE would be sufficient to allow me to operate the HRPWM with the Auto-Conversion feature and SFO() Calibration.

Alon Harpaz said:

I am not sure what the cause for this difference is.  One thing which I noticed - the EPwm1Regs.HRPWR.bit.CALPWRON occasionally toggles '1' and back to '0'.  Is that part of the expected behavior?  Is there any significance to other Bits in that Register?