TMS320F28379D: Also Missing Trip events in peak current mode control

Hi,

Can you provide more details of the issue you are encountering?

The comparator is set up for peak current mode control. There are times that the current goes well over the comparator setting without terminating the duty cycle. The result is that we are getting way too much energy delivered.

I really would like to be able to setup a conference. This is an urgent issue that requires expert assistance.

In addition to my previous comment - Document SPRZ422I offers 3 workarounds for a race condition between COMPHSTS and PWMSYNC. It is unclear how to achieve any of these workarounds in code. We require some help understanding how to achieve these workarounds.

Please, we need an avenue to work interactively over conferencing. We do have a very urgent issue that needs to be resolved.

Hi Vito,

I took a look at the doc you mentioned. The issue in the errata is about latch not cleared at the expected time point. However, your case is like the compare event does not happen when hitting the CMPSS threshold. So I am not very sure if that is the root cause. 

Also you mentioned that this issue happens very rare but only happens during the tranisient, corrrect?

Will you be able to provide the waveforms of key PWM and the feedback current signals during the transient(when issue happens)?

Will you be able to draw a pic how you configure the PWM and CMPSS? also the CMPSS reset?

any blanking used? 

Regards,

Chen

The Green trace is the signal fed into CMPIN1P. This is our primary current. The scale is 1V = 40A. You can see that the voltage is going well over the DACREF which is VDDA. We apply 3.3V to VDDA. We do not set SELREF. The default value is 0, so DACREF should be VDDA.

We are using a TI macro to execute the math – The macro is called “CNTL_2P2Z_CLA_C” The macro requires the user to put in a value for the maximum output for the math.

In our code, it is entered as “coeff1.Max = .8;”

We multiply this by (2¹⁶ – 1) and load it into RAMPMAXREFS.

According to figure 12-5 on page 1649 of SPRUHX5G, this value is divided by 2⁴ and then transferred to DACHVALA.

Then, according to figure 12-3 on page 1647 of SPRUHX5G, this value is transferred as a voltage to DACOUTH. The value of that voltage should follow equation 12-4 which works out to be 2.64V. I imagine it is less than a coincidence that this happens to be 0.8 of 3.3.

In any case, no matter what type of math you are doing, it is physically impossible for DACOUTH to be greater than 3.3V. As you can see, the CMPIN1P is going well above that level.

For your reference, the Blue trace is the secondary output voltage.

Correction...

Where I wrote "We multiply this by (2¹⁶ – 1) and load it into RAMPMAXREFS."

Should be ... "We multiply the output of the macro, which has a maximum value of 0.8, by (2¹⁶ – 1) and load it into RAMPMAXREFS"

Please review the 2 earlier replies from today.

I have the CMPSS and PWM configuration settings below. You also asked for CMPSS reset. I am not sure what you mean by that.

CPMSS Configuration…

(From file Peripheral_CNF)

Cmpss1Regs.COMPCTL.bit.COMPDACE = 1;        // Power up Comparator locally

Cmpss1Regs.COMPCTL.bit.CTRIPHSEL = 3;       //3 Latched output of digital filter drives CTRIPH//2 Output of digital

Cmpss1Regs.COMPCTL.bit.COMPHINV = 0;        // Comparator Output passed

Cmpss1Regs.COMPCTL.bit.ASYNCHEN = 0;                 // PWMSYNC path to reset latch is enabled

Cmpss1Regs.COMPDACCTL.bit.DACSOURCE = 1;    // DACsrc; // 0 - DACHVALA is updated from DACHVALS; // 1 - Internal ramp

Cmpss1Regs.COMPDACCTL.bit.RAMPSOURCE = 11;  //RAMPsrc; // 0 - PMW1; 1 - PWM2,...so on

Cmpss1Regs.RAMPDECVALS = 40;

EPwm12Regs.HRPCTL.bit.PWMSYNCSEL = 1;       // PWM SYNC generated at CTR = ZRO for synchronizing internal ramp

Cmpss1Regs.CTRIPHFILCTL.bit.FILINIT = 1;

Cmpss1Regs.CTRIPHFILCTL.bit.THRESH = 3;

Cmpss1Regs.CTRIPHFILCTL.bit.SAMPWIN = 5;

Cmpss1Regs.COMPSTSCLR.bit.HSYNCCLREN = 1;            // PWMSYNC will reset latch

NOTE : Cmpss1Regs.COMPCTL.bit.COMPHSOURCE is not set in code Default is 0, so ramp generator and DAC is being used.

             Cmpss1Regs.COMPCTL.bit.CTRIPOUTSEL is not set in code. Default is 0.

             Cmpss1Regs.COMPDACCTL.bit.SELREF is not set in code. Default is 0

            Cmpss1Regs.COMPDACCTL.bit. RAMPLOADSEL is not set in code. Default is 0

            Cmpss1Regs.COMPDACCTL.bit.SWLOADSEL is not set in code. Default is 0

            Cmpss1Regs.COMPDACCTL.bit.FREESOFT is not set in code. Default is 0

            Cmpss1Regs.COMPHYSCTL.bit.COMPHYS is not set in code. Default is 0

PWM Configuration

EPwm1Regs.TBPRD = 300;

CpuSysRegs.PCLKCR0.bit.HRPWM = 1;

EPwm1Regs.TBCTL.bit.PRDLD = 0;                 // Set shadow load

EPwm1Regs.TBPHS.all = 0;

EPwm1Regs.TBCTR = 0;

EPwm1Regs.TBCTL.bit.CTRMODE = TB_COUNT_UPDOWN;

EPwm1Regs.TBCTL.bit.PHSEN = 1;// TB_DISABLE;

EPwm1Regs.TBCTL.bit.SYNCOSEL = 1;             // Used to sync EPWM(2-7) "down-stream"

EPwm1Regs.TBCTL.bit.HSPCLKDIV = TB_DIV1;

EPwm1Regs.TBCTL.bit.CLKDIV = TB_DIV1;

       // Counter compare submodule registers

EPwm1Regs.CMPCTL.bit.SHDWAMODE = 0;//CC_IMMEDIATE;

EPwm1Regs.CMPCTL.bit.SHDWBMODE = 0;//CC_IMMEDIATE;

       // Action Qualifier SubModule Registers

EPwm1Regs.AQCTLA.bit.ZRO = AQ_SET;

EPwm1Regs.AQCTLA.bit.PRD = AQ_CLEAR;

       // DeadBand Control Register

EPwm1Regs.DBCTL.bit.OUT_MODE = DB_FULL_ENABLE;

EPwm1Regs.DBCTL.bit.POLSEL = DB_ACTV_HIC;                   // Active Hi Complimentary

EPwm1Regs.DBRED.all = PS_DT;//PS_DT_R1;//40,20;                                // Initial value

EPwm1Regs.DBFED.all = PS_DT;//PS_DT_F1;//40,20;                                // Initial value

EPwm12Regs.TBPRD = 299;   //

EPwm12Regs.TBPHS.bit.TBPHS = 5 ;

EPwm12Regs.TBCTR = 0;

EPwm12Regs.TBCTL.bit.CTRMODE = TB_COUNT_UP;

EPwm12Regs.TBCTL.bit.PHSEN = TB_ENABLE;

EPwm12Regs.TBCTL.bit.PHSDIR = TB_UP;

EPwm12Regs.TBCTL.bit.HSPCLKDIV = TB_DIV1;

EPwm12Regs.TBCTL.bit.CLKDIV = TB_DIV1;

EPwm12Regs.TBCTL.bit.SYNCOSEL = 1;//TB_SYNC_IN;      // Sync "flow through" mode

       // Counter compare submodule registers

EPwm12Regs.CMPCTL.bit.LOADAMODE = CC_CTR_ZERO;

EPwm12Regs.CMPCTL.bit.SHDWAMODE = 0;//CC_IMMEDIATE;

       //===========================================================================

    // Define an event (DCAEVT1) based on Comparator 1 Output

EPwm12Regs.DCTRIPSEL.bit.DCAHCOMPSEL = 3;// DCAH = Trip4 Comparator1 output

EPwm12Regs.TZDCSEL.bit.DCAEVT2 = TZ_DCAH_HI;             // DCAEVT1 = DCAH high(will become active as

EPwm12Regs.DCACTL.bit.EVT2SRCSEL = DC_EVT_FLT;           // DCAEVT1 = DC_EVT_FLT (filtered)

EPwm12Regs.DCACTL.bit.EVT2FRCSYNCSEL = DC_EVT_ASYNC;     // Take async path

       // Enable DCAEVT1 as a one-shot source

EPwm12Regs.TZSEL.bit.DCAEVT2 = 1;                        // CBC / Enable One-Shot Trip

       // Following code for the sync mechanism based on the same trigger event - COMPxOUT

EPwm12Regs.DCACTL.bit.EVT1SYNCE = 1;                 // Sync enabled

       // ADC SOC generation

       //===========================================================================

       //PWM EXTERNAL SYNC CONFIG

InputXbarRegs.INPUT5SELECT = 17;         // Set PWM SYNC IN source to GPIO17

InputXbarRegs.INPUT12SELECT = 17;        // Set eCAP6 source to GPIO17

GpioCtrlRegs.GPAMUX2.bit.GPIO17 = 0;        // GPIO17 = GPIO

GpioCtrlRegs.GPADIR.bit.GPIO17  = 0;        // GPIO17 = INPUT

GpioCtrlRegs.GPAPUD.bit.GPIO17  = 0;        // enable internal Pull-Up

EPwm12Regs.HRPCTL.bit.PWMSYNCSEL = 1;       // PWM SYNC generated at CTR = ZRO for synchronizing internal ramp

Hi Vito,

Sorry for the late reply. 

I didn't see the PWM waveform together with the feedback signal. So I assume the PWM is not responding, correct? (just to confirm)

It will be helpful if you can tell me how PWM looks like. Is it turned off and quickly turn back on? or it is always on during that time.

Your calculation in the first reply makes sense for me. But that does not explain why PWM is not responding when 2.64 is set as the max ref.

I will take a look at the code you posted.

Regards,

Chen

I don't have the PWM signals captured. The the high current at full duty cycle is evidence that the PWM signals are going full tilt. Please spend some time reviewing the information that I already provided on Friday. Let me know if it you believe the settings are correct.

Hi Vito,

You may take a look at the thread below

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/967421/tms320f280049-pcmc-for-psfb-topology-abnormal-ctripouth-signal

Also you may try to use digital filter and hysteresis in the CMPSS to see if the issue can be removed.

Regards,

Chen

Thanks for your reply.

Our intent is to use the synchronous mode and the digital filter as the thread you asked me to review suggests. I was hoping you could review the comparator and PWM settings I had previously sent to see if you agree they are appropriate. TI did ask me for this information. I made the assumption that someone at TI would look at that they requested.

If TI does not have the resources to spend reviewing this, I would understand, but please let me what your plan is.

Alternatively, if TI can not spend time reviewing the information they requested, I would appreciate if TI can provide a third party contact who can work more interactively.

The peripheral configuration for peak CMC is pretty complicated, best strategy is to verify in chunks.

Have you tried observing the comparators' raw outputs during such an event? You can rout the comparators' outputs (CTRIPOUTH/L) to GPIO pins via the output XBAR. But keep in mind the CTRIPOUTH/L signals are not necessarily the same as the CTRIPH/L signals (the ones which can be routed to the ePWMs via the PWM XBAR). Make sure to set up CTRIPH/L and CTRIPOUTH/L with the same mux settings.