TMS320F280025: why are EPWMs tripped no matter what CMPSS1 output?

I even set CMPSS1's internal DAC to 1 (lowest number) to make sure external voltage is definitely HIGHER than internal threshold voltage(1), but EPWMs are still tripped

Can someone advise on how to diagnose this issue?  Thanks

Hello,

Your configuration of CMPSS and XBAR seem correct. Could you share your configuration of Digital Compare Event submodule, please? Please refer to Figure 17-50 in TRM for block diagram of Digital Compare Event submodule to see how EPWM X-BAR is connected to TripZone submodule. 

A digital compare DCAEVT1/2 or DCBEVT1/2 event is generated based on a combination of the DCAH/ DCAL and DCBH/DCBL signals as selected by the TZDCSEL register. The signals which source the DCAH/ DCAL and DCBH/DCBL signals are selected using the DCTRIPSEL register and can be either trip zone input pins or analog comparator CMPSSx signals like in your case.

Hi Stevan,

Thanks for looking into it!  Please see the configuration of Digital Compare module below (take EPWM3 as example):

• TRIPIN10 -> DCAH: 

    EPWM_enableDigitalCompareTripCombinationInput(EPWM3_BASE,                                                 

                                                  EPWM_DC_COMBINATIONAL_TRIPIN10,

                                                  EPWM_DC_TYPE_DCAH);

• Use “DCAH -> DCAEVT1” to trip EPWM:

    EPWM_setTripZoneDigitalCompareEventCondition(EPWM3_BASE,

                                                 EPWM_TZ_DC_OUTPUT_A1,

                                                 EPWM_TZ_EVENT_DCXH_HIGH);

    EPWM_setTripZoneAction(EPWM3_BASE, EPWM_TZ_ACTION_EVENT_TZA,EPWM_TZ_ACTION_LOW);

EPWM_setTripZoneAction(EPWM3_BASE, EPWM_TZ_ACTION_EVENT_TZB,EPWM_TZ_ACTION_LOW);

    EPWM_enableTripZoneSignals(EPWM3_BASE,

                               EPWM_TZ_SIGNAL_DCAEVT1);

    EPWM_setDigitalCompareEventSource(EPWM3_BASE,

                                      EPWM_DC_MODULE_A,

                                      EPWM_DC_EVENT_1,

                                      EPWM_DC_EVENT_SOURCE_ORIG_SIGNAL);

 =========================================

Some important info which might help to diagnose:

In the SAME project, I also implemented a very similar feature using CMPSS3.LOW_COMPARATOR to compare an external voltage with internal threshold voltage -- internal threshold voltage is generated through CMPSS3's internal DAC(for example, set as 1500).  When external voltage is higher than internal threshold voltage(for example, 1500), CMPSS3.CTRIPL trips all EPWMs.

The CMPSS3 implementation above is almost the same as CMPSS1 implementation: both CMPSS1 & CMPSS3 output are connected to TRIPIN10 – very similar to CMPSS1, CMPSS3.LOW_COMPARATOR.CTRIPL is used to trip EPWMs with the following lines to connect through ePWM X-BAR to TRIP10 :

    XBAR_setEPWMMuxConfig(XBAR_TRIP10,  XBAR_EPWM_MUX05_CMPSS3_CTRIPL);

XBAR_enableEPWMMux(XBAR_TRIP10, XBAR_MUX05);

If I comment out the whole CMPSS1 implementation, CMPSS3 implementation works correctly as expected:  EPWMs are ONLY tripped when  external voltage is  HIGHER than internal threshold voltage of CMPSS3

However, If I comment out the whole CMPSS3 implementation, CMPSS1 implementation works incorrectly as previously stated:  no matter if external voltage is LOWER or HIGHER than internal threshold voltage(for example, 1500), i.e: no matter if  CMPSS1regs.COMPSTS.COMPLSTS = 1  or   =0,  EPWMs are immediately tripped

Hi Stevan,

Could you advise how I should furtherly diagnose based on the info provided?

Thanks,

Quentin

Hello,

So, your CMPSS3 configuration works correct? Is CMPSS1 configuration exactly the same for CMPSS3? What happens if you use different Trip signal for CMPSS1

Hi Stevan,

Sorry that I replied to you late, because I did not get email notification about your previous update.

CMPSS1 configuration is exactly the same as CMPSS3. 

• CMPSS1 output is connected to TRIPIN10 with code below:

                        XBAR_setEPWMMuxConfig(XBAR_TRIP10, XBAR_EPWM_MUX01_CMPSS1_CTRIPL);
                        XBAR_enableEPWMMux(XBAR_TRIP10, XBAR_MUX01);

• CMPSS3 output is connected to TRIPIN10 with code below: 

XBAR_setEPWMMuxConfig(XBAR_TRIP10,  XBAR_EPWM_MUX05_CMPSS3_CTRIPL);

XBAR_enableEPWMMux(XBAR_TRIP10, XBAR_MUX05);

CMPSS3 works correctly.  CMPSS1 works incorrectly!   That is the strange part!

• If I add back the line " XBAR_enableEPWMMux(XBAR_TRIP10, XBAR_MUX01) " above to connect XBAR, no matter if external voltage is LOWER or HIGHER than internal threshold voltage(for example, 1500), i.e: no matter if  CMPSS1regs.COMPSTS.COMPLSTS = 1  or   =0,  EPWMs are immediately tripped;  why are EPWMs tripped no matter what CMPSS1 output?   Why are EPWMs tripped no matter if external voltage is LOWER or HIGHER than internal threshold voltage(for example, 1500), i.e: no matter if  CMPSS1regs.COMPSTS.COMPLSTS = 1  or   =0 ?

It feels like XBAR_MUX01 connects something else other than XBAR_EPWM_MUX05_CMPSS3_CTRIPL with TRIP10 -- at least it feels that way

Unfortunately we can not use different Trip signal for CMPSS1. We have to stick to TRIP10 and get this issue resolved for some reason.

Hi Stevan,

I don't think that is the reason, because multiple CMPSS can connect to the same TRIP signals -- I have done this many times.

I already tried this:  in the same design, I configured 4 CMPSSs, CMPSS4, CMPSS2, CMPSS3, CMPSS1  the same way, and they are all connected to TRIP10 with code below:

CMPSS4:

  XBAR_setEPWMMuxConfig(XBAR_TRIP10, XBAR_EPWM_MUX07_CMPSS4_CTRIPL);
XBAR_enableEPWMMux(XBAR_TRIP10, XBAR_MUX07);

CMPSS2:

XBAR_setEPWMMuxConfig(XBAR_TRIP10, XBAR_EPWM_MUX03_CMPSS2_CTRIPL);
XBAR_enableEPWMMux(XBAR_TRIP10, XBAR_MUX03);

CMPSS3:

XBAR_setEPWMMuxConfig(XBAR_TRIP10, XBAR_EPWM_MUX05_CMPSS3_CTRIPL);
XBAR_enableEPWMMux(XBAR_TRIP10, XBAR_MUX05);

CMPSS1:

XBAR_setEPWMMuxConfig(XBAR_TRIP10, XBAR_EPWM_MUX01_CMPSS1_CTRIPL);
XBAR_enableEPWMMux(XBAR_TRIP10, XBAR_MUX01);

As long as I comment out CMPSS1,  CMPSS4 & CMPSS2 & CMPSS3 all work correctly as expected: EPWMs are only tripped when external voltage is greater than internal DAC setting.

CMPSS1 is the only problematic one.

There are other reasons. Please advise how to diagnose.

Thanks,

Quentin

Quentin Fu said:

XBAR_setEPWMMuxConfig(XBAR_TRIP10, XBAR_EPWM_MUX01_CMPSS1_CTRIPL);

Stevan mentions best to configure CMPSSx multiple or combinational OR'd trip signals from xBAR MUX to trip PWM action qualifiers via MDAC inputs. The OR gate seems to add protection against false tripping PWM action qualifiers. That way you know which phase is causing issues (if any) by checking CMPSSx status and latch events CCS debug register tab. 

Perhaps test inverting the output CMPSS DACVAL-L if monitoring AC sinewave via low side shunts. Set the DACVLA-H/L counts 2048 and keep in mind 2048 count = +1.65vdc at the DAC negative inputs and bidirectional current sensors. Negative half of sinewave produce counts, e.g; 2048(Min) to 0(Max) negative sinewave peak current trip points. And 2048 to 4096 positive trips for setting both OVC limits subtracting both OVC trip fault counts from 4096 will produce lower counts to set DACVAL-H/L trip points.

Thanks a lot for your reply! But I am a little confused and don't understand. Could you please elaborate with more detailed and specific steps on how I should furtherly diagnose this issue?

Quentin

Hi Quentin,

You might check universal motor control SDK, download project via CCS Resource Explorer from toolbar. The SDK documents folder PDF migration section examples how to configure x25c two CMPSS modules for 3 phase trip zones. Some other TI MCU's classes have 3 CMPSS modules. The UMCSDK v5.03 project drives BLDC Halls (Trapezoidal wave) and FOC controls sinewave phase current with encoder position sensing as well.

Thanks, but I believe I am already very familiar with multiple CMPSS configurations -- I have done this many times for many years.

I only ran into this strange issue with this particular case. Please advise how to specifically diagnose this issue.

You could try to calibrate the CMPSSx suspected of and assume false setting Tz when it should not? Anyway, if you have not reviewed the x25 TRM in some time, MUX decodes or ePWM xBAR tables. Don't be surprised of what seemed to work properly at one time stops working, After POR any single CMPSSx status shows latch set, there is most likely misconfiguration to blame.

I don't understand.

I don't think my CMPSS1 is misconfigured. The reasons are:

1.  4 CMPSSs, CMPSS4 & CMPSS2 & CMPSS3 & CMPSS1  are configured the same way (including TRIP configuration) by calling exactly the same function call, and they are all connected to TRIP10.  CMPSS1 is the only problematic one.
2. I am sure CMPSS1.LOW_COMPARATOR is configured correctly; we verified with experimentations:

• when external voltage is LOWER than internal threshold voltage(for example, 1500), CMPSS1regs.COMPSTS.COMPLSTS = 1   -- this is correct
• when external voltage is HIGHER than internal threshold voltage(for example, 1500), CMPSS1regs.COMPSTS.COMPLSTS = 0   -- this is correct

Please advise how to specifically diagnose this issue.

Quentin Fu said:

I don't think my CMPSS1 is misconfigured. The reasons are:

Perhaps choose another CMPSSx for experiment.

You can add below clear latch code snip bottom PWM fault and setup hal.c. It does clear CMPSSx set latches. Perhaps enter CCS debug clear the latch status Register view, enter 0 for any set LatchCLR bits, continuous refresh. The comparator inputs are not debounced can easily be false triggered unless configure DAC output to set a 1500 count. 

EALLOW;
// SW Reset comparator digital filter output H/L latch status
while(HWREGH(obj->cmpssHandle[cnt] + CMPSS_O_COMPSTS) &= CMPSS_COMPSTS_COMPHLATCH)
{
    CMPSS_clearFilterLatchHigh(obj->cmpssHandle[cnt]);
    //DEVICE_DELAY_US(1);
}

// SW Reset comparator digital filter output H/L latch status
while(HWREGH(obj->cmpssHandle[cnt] + CMPSS_O_COMPSTS) &= CMPSS_COMPSTS_COMPLLATCH)
{
    CMPSS_clearFilterLatchLow(obj->cmpssHandle[cnt]);
    //DEVICE_DELAY_US(1);
}
EDIS;

// Clear any spurious interrupt faults
EPWM_clearTripZoneFlag(obj->pwmHandle[cnt], HAL_TZFLAG_INTERRUPT_ALL);