TMS320F280049C: EPWM Xbar output Mux 0-31 Trips

Perhaps the problem relates to there being only 8 ePWM xBAR outputs into DC sub module Fig.18-48 but no cross reference was shown in table 9-2 for Trip 4-12 shown Fig.18-48.

So CMPSS1 = TripIN4 and what figure in the TRM would confirm that as being remotely a good guess?

TRIPIN4 is the FIRST output of the EPWM XBAR.

Hi Nima,

Nima Eskandari said:

TRIPIN4 is the FIRST output of the EPWM XBAR.

That much is clear but there are no TRM table 18-13 entry to indicate CMPSSx connects to any one of the ePWM TripIN inputs shown in Fig.18-47.

If we guess Trip4 = 0 (CMPSS1) it then gets sketchy after Trip12 (CMPSS7). According to table 18-13 how does MUX13 to MUX31 connect ePWM xBAR?

So MUX12 = TripIN11=12 but MUX12 to TripIN11 don't match, see the grey? Why do we have to guess when it may not work that way at all?

Seems a grey area without TRM facts being presented to support an intended CMPSSn MUX connection into ePWM Xbar outputs into Trip sub module via SW. Fig.18-57 indicates a disconnect from CMPSSx block outputs CTRIPH/L and a (hint) "ePWM XBAR only."

How does TRM clarify XBAR_setEPWMMuxConfig(), XBAR_enableEPWMMux(), and XBAR_disableEPWMMux() produce a 1:1 match to ePWM xBAR when in fact the values skew near the end.

typedef enum
{
    XBAR_TRIP4  = 0,        //!< TRIP4 of the ePWM X-BAR
    XBAR_TRIP5  = 2,        //!< TRIP5 of the ePWM X-BAR
    XBAR_TRIP7  = 4,        //!< TRIP7 of the ePWM X-BAR
    XBAR_TRIP8  = 6,        //!< TRIP8 of the ePWM X-BAR
    XBAR_TRIP9  = 8,        //!< TRIP9 of the ePWM X-BAR
    XBAR_TRIP10 = 10,       //!< TRIP10 of the ePWM X-BAR
    XBAR_TRIP11 = 12,       //!< TRIP11 of the ePWM X-BAR
    XBAR_TRIP12 = 14        //!< TRIP12 of the ePWM X-BAR
} XBAR_TripNum;

Table 18-13 does not show any TripINx value or that CMPSSx MUXn even connect to ePWM xBAR inputs. Firmware calls to configure MUX to TripINx do not indicate CMPSSx even connects to TripINx or have notes for how net decodes should relate to ePWM xBAR.  

Nima Eskandari said:

If you want to use TRIPIN1-3,6 you can just configure the corresponding INPUT XBAR.

No where is it stated the DC sub module or combinational TripINx auto routes ePWM xBAR outputs to previously configured CMPSSx output MUX's. Again Fig.18-57 does not support that kind of logic. Yet one is left to assume some kind of switching logic must route CMPSSx to ePWM xBAR output ports as static aligned TpriINx inputs. And shown Fig.18-49 to be static ePWM sub module TripINx inputs via xBAR and it's outputs.

There needs to be text/table disclosure how static MUX routing of CMPSS1.CTRIPH can trigger any one of the 8 sub module inputs Fig.18-49. The point of configuring ePWM xBAR output was to align each selected MUX output port to specific ePWM sub module trips configured as/for combinational TripINx or DC TripINx. Why the need to have TripINx numbers for the ePWM xBAR if they automatically connect to the configured MUX? Note too the MUX enable requires a specific TripINx value and would not be required if it was auto routed. 

MUX's configure CMPSSx  didn't work with DC submodule TripINx or combination TripINx when ePWM outputs were forced low. Seemingly CMPSSx are not being connected to the ePWM TripINx that were configured via enableEPWMMux. The TripINx port decodes are seemingly wrong to link any of the DC sub module or combinational TripINx inputs! The only one that worked was Tz2 when it was forced inverted via GPIO port added as TripIN2 to combinational. 

Configuration via drive lib does not explain how the TripINx that was selected some how aligns to the configured MUXn being transformed into a random port selection Fig.18-49.

    // Configure TRIP5 to be CTRIP1H and CTRIP1L via ePWM X-BAR
    // TRM:9.2.1 Table 9-2
    XBAR_setEPWMMuxConfig(XBAR_TRIP5, XBAR_EPWM_MUX02_CMPSS2_CTRIPH_OR_L);
    XBAR_enableEPWMMux(XBAR_TRIP5, XBAR_MUX02);

        //enable DC TRIP combinational input
        // 18.11.12 CMPSS: EPWM_DC_COMBINATIONAL_TRIPIN2 (GPIO)
        EPWM_enableDigitalCompareTripCombinationInput(obj->pwmHandle[cnt],
               ( EPWM_DC_COMBINATIONAL_TRIPIN5),
                EPWM_DC_TYPE_DCAH); 

They seem to align by the equal value as 5 now trips from CMPSS2 in the above configuration. It was configured for TripIN7 and was not faulting previously from TripIN7. Also the low side DC latch of CCMP2, CCMP4  remain latched after being SW cleared, CCS debug real time register view. Both H/L latch status bits CCMP2, CCMP4 register COMPSTS where toggling via idle INA240 inputs 40mV (+1.65v REF) even after DC filter threshold 4058 counts. 

.