• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 32 subscribers
  • Views 142 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

AM263P4: Cannot find way to disableTripZoneAction for CAPEVT

Akshay Murthy
Prodigy 10 points

Part Number: AM263P4

Tool/software:

Hi,

I'm trying to use the XMINMAX registers on AM263P4 to trigger a CAPEVT, but I'm seeing that CAPEVT trips the EPWM on which it is generated. I'm would like to set the Tripzone action to be EPWM_TZ_ACTION_DISABLE. I found in the register addendum that the corresponding register EPWM_TZCTL also doesn't have bits for trip events (like it does for DCxEVT).



Depiction of what I'm trying to do:

  • 0
    TI__Expert 8580 points

    Hello Akshay,

    On AM263P, CAPEVT can be routed into the ePWM Trip-Zone CBC path, so it will trigger whatever TZA/TZB action you’ve configured for CBC. There isn’t a dedicated “disableTripZoneAction(CAPEVT)” API; instead you turn it off by (a) not routing CAPEVT into the CBC mux, and/or (b) disabling its TZ interrupt and clearing any pending flags.

    If you still see the outputs tripping after removing CAPEVT from the CBC mux and disabling its TZ interrupt, please share a short snippet of your EPWM TZ/DCCAP setup. I can point out the exact line to change.

    Best Regards,

    Masoud

  • 0 in reply to Masoud Farhadi
    Prodigy 10 points

    Hi Masoud,

    Thanks for confirming that TripZoneAction cannot be explicitly disabled for CAPEVT. I'm using the OST mux, and not the CBC mux, but I'm assuming the same applies. Currently, the feature I'm implementing using CAPEVT event runs in shadow mode (meaning we're not aiming to trip the converter but are only evaluating the robustness of the limits we're using in the XMINMAX detection circuit). For now, I'm reading TZFLG to check if the CAPEVT has been triggered, and it is working. Here's a depiction of what the eventual trip architecture will look like:


    Basically, we have 2 ePWMs that are using the XMINMAX detection to trigger CAPEVT, and 6 ePWMs that are not using them. We route TRIPOUT from the CAPEVT ePWMs to the PWM XBAR, where we have a dedicated combined trip line that is used by all ePWMs. I would like to have all 8x PWM instances in the converter to trip at the same time. If I enable the OST mux for the ePWMs that perform XMINMAX checking, wouldn't they trip before the rest of the ePWMs?

  • 0 in reply to Akshay Murthy
    TI__Expert 8580 points

    Hello,

    If you select CAPEVT into the OST/CBC mux, that ePWM will trip itself immediately. OST vs. CBC doesn’t change that fact.

    And yes, if you enable the OST mux for CAPEVT on the 2 “detector” ePWMs, those 2 will trip first, and the other 6 will follow a few cycles later via the PWM XBAR combined line. To avoid that skew, don’t let CAPEVT trip locally (do not select CAPEVT into the local OST/CBC mux); only use it to generate the combined trip that all 8 listen to. OR the two TRIPOUTs to make COMBINED_TRIP and In TZSEL, enable the PWM XBAR input that carries COMBINED_TRIP. Finally, in TZCTL, set the one-shot action (e.g., A/B >> force low/high as needed).

    Best Regards,

    Masoud