This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

F28377D Trip-Zone Always Tripped

Other Parts Discussed in Thread: CONTROLSUITE

I'm trying to set up a trip-zone input on an F28377D part, based on the epwm_trip_zone example in controlSUITE.  I'm configuring EPWM1 to set both signals low on TZ1.  I'm using GPIO11 as an output and tying this physically to GPIO12 on my control card, which I'm configuring as an input and tying to TZ1 using the input x-bar.  The idea is that I can change GPIO11 and see the effect of that on the PWM signals.  The problem I'm having is that it appears to always be tripped, regardless of the value of GPIO11 or GPIO12.  If I set the appropriate bits in the TZCLR or TZCBCCLR registers, the corresponding bit in TZFLG or TZCBCFLG always stays set.

I can see the values of GPIO11 and GPIO12 change as expected in the GPADAT register.

I also read through this post, and I think I'm understanding everything there and doing everything according to the suggestions: http://e2e.ti.com/support/microcontrollers/c2000/f/171/p/328007/1142569.aspx#1142569

Can anyone suggest what I might be doing wrong?  Here are the relevant bits of code:

EALLOW;

// Configure GPIO11 to output a signal for TESTING the cap fault trip zone.
GPIO_SetupPinOptions(11, GPIO_OUTPUT, GPIO_ASYNC);
GPIO_SetupPinMux(11, GPIO_MUX_CPU1, 0);
GpioDataRegs.GPASET.bit.GPIO11 = 1;

// Configure GPIO12 as CAPFAULT_IN for TESTING capacitor fault trip-zone. We set it here
// as a GPIO input, then it is configured as a trip-zone through the input crossbar.
GpioCtrlRegs.GPAPUD.bit.GPIO12 = 0;  // enable pull-up on GPIO12 (TZ1)
GpioCtrlRegs.GPAQSEL1.bit.GPIO12 = 3; // asynch input for GPIO12 (TZ1)
InputXbarRegs.INPUT1SELECT = 12;

// Enable TZ1 to force PWMs LOW cycle-by-cycle.
EPwm1Regs.TZSEL.bit.CBC1 = 1;
EPwm1Regs.TZCTL.bit.TZA = TZ_FORCE_LO;

EDIS;

 

  • Jon,

    What is the order of operations you are configuring these in?  Note that you will want to configure the Input X-bar before doing any PWM configuration.  By default, the Input X-bar is set to GPIO0 so if you enable your PWM generation before changing the Input X-bar EPWM1 will actually trip itself.

    Also, just a side note, you can skip the external wire and just set the Input X-bar to GPIO11.  The Input X-bar reads the value from the input on the GPIO which is always active.  So you can set GPIO11 as an output and set the Input X-bar to GPIO11 and everything will work without the external connection.  There's nothing wrong with the way you're doing it.  Just a tip.

    Kris

  • Kris,

    Thanks for your reply.  I am setting up the configuration registers in the order I indicated, setting up the input x-bar before I set up the trip-zones for the PWMs.  I originally was using the X-bar with GPIO11 without the external connection, but I switched to the "manual" method because I was having this problem with the PWM always being tripped.

    Thanks,
    Jon

     

  • Thanks Jon,

    Can you provide the rest of your code which configures the TZ or DC event to cause the trip?  Thanks,

    Kris

  • Kris,

    I've attached a minimal project for the 28377 control card that exhibits the problem.  It configures EPWM1 to produce a 20 kHz PWM at 50% duty cycle, and sets up GPIO12 as a cycle-by-cycle trip.  It appears that this is always tripped unless I comment out the code that sets the CBC bit in TZSEL.

    Thanks for your help,
    Jon

    4848.TripZoneTest.zip

  • Hi Jon,

    I took a brief look at your code and while much seems correct, I think I see a potential gotcha. 

    Be careful of EALLOW/EDIS.  The GPIO setup functions call EDIS inside them. 

    I think your input xbar configuration may be outside of an EALLOW/EDIS block and therefore won't happen.  As a result the default InputXBAR input is chosen (GPIO00) which explains some of what you're seeing.  You can check whether these writes are/aren't occurring by viewing the relevant registers in the watch window.

    Please let us know if this helps.


    Thank you,
    Brett

  • Brett,

    Nice catch, that was the problem.  I made sure that EALLOW and EDIS were surrounding the InputXBar configuration, and it's now working as I'd expect.

    Thanks,
    Jon