• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 83 subscribers
  • Views 810 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.

TMS320F280049: TZCTL priority

HS FAE Germany
Mastermind 32400 points
Part Number: TMS320F280049


Hello,
customer has following configuration:

RAIL_A_PWM_AB.TZCTL.bit.TZA = TZ_FORCE_LO;         /* Trip Action On EPWM1A */
RAIL_A_PWM_AB.TZCTL.bit.TZB = TZ_FORCE_LO;         /* Trip Action On EPWM1B */
RAIL_A_PWM_AB.TZCTL.bit.DCAEVT2   = TZ_FORCE_LO;   /* CBC TZ enabled for Comparator */        
RAIL_A_PWM_AB.TZCTL.bit.DCBEVT2   = TZ_FORCE_HI;   /* CBC TZ enabled for Comparator */
RAIL_A_PWM_AB.TZCTL.bit.DCAEVT1   = TZ_FORCE_HI;   /* OST TZ enabled for Comparator */
RAIL_A_PWM_AB.TZCTL.bit.DCBEVT1   = TZ_FORCE_LO;   /* OST TZ enabled for Comparator */

He only sees that TZA and TZB work. My understanding is that there is a priority but only if there is a conflict (same events at the same time):
TZA (highest) -> DCAEVT1 -> DCAEVT2 (lowest)
TZB (highest) -> DCBEVT1 -> DCBEVT2 (lowest)

If there is no conflict it should work, right?

Regards, Holger

  • 0
    TI__Intellectual 860 points

    Hello,

    Concerned experts have been notified of this query.

    Note that it is Thanksgiving week in US and most of the TI engineers are away.

    Please expect a delayed response, surely by early next week.

     

    Regards,

    Sudhakar

    ---------------------------------------------------------------------------------------------------

    If a post answers your question, please mark it with the "verify answer" button.

    Other useful links:

    C2000 Getting Started      C2000 Flash Common Issues/FAQs      Emulation FAQ

  • 0 in reply to Sudhakar Singh47
    TI__Guru 57255 points

    Hi Holger,

    I would first make sure that the meaning of each of these terms is understood. The figure labelled "Trip-Zone Submodule Mode Control Logic" in the TRM should help.

    • TZA: What to happen on PWMxA when a OST or CBC event occurs.  These events can occur from a combination of TZn or DCxEVTn events, depending on how TZSEL is set.
    • TZB: What to happen on PWMxB when a OST or CBC event occurs.  These events can occur from a combination of TZn or DCxEVTn events, depending on how TZSEL is set.
    • DCAEVT1: What to happen on PWMxA when a DCAEVT1 event occurs.  PWMxA will only be affected during the time of the event.
    • DCBEVT1: What to happen on PWMxA when a DCBEVT1 event occurs.  PWMxB will only be affected during the time of the event.
    • DCAEVT2: What to happen on PWMxA when a DCAEVT2 event occurs.  PWMxA will only be affected during the time of the event.
    • DCBEVT2: What to happen on PWMxA when a DCBEVT2 event occurs.  PWMxB will only be affected during the time of the event.

    As a result, only TZA & TZB can affect PWM outputs for longer than exactly during the event.

    I'm hoping that with this additional explanation, you'll be able to make more sense of what you are seeing.


    Thank you,
    Brett

  • 0 in reply to Brett Larimore
    TI__Mastermind 32400 points

    Hello Brett,

    > DCAEVTx: What to happen on PWMxA when a DCAEVTx event occurs.  PWMxA will only be affected during the time of the event.
    does this mean that the PWMxA will not be affected for a complete PWM period?

    Regards, Holger

  • 0 in reply to HS FAE Germany
    TI__Guru 57255 points

    Hi Holger,

    Where TZCTL is concerned, yes.  TZCTL.DCxEVTn will only affect PWM outputs on a PWMCLK-by-PWMCLK basis, and only while the event is actually occurring. 

    You can read more about this in the "Digital Compare Events (DCAEVT1/2 and DCBEVT1/2)" bullet-point within the section labelled "Operational Highlights for the Trip-Zone Submodule".

    ===

    Note however that DCxEVTn events from the Digital Compare submodule do have an ability to generate CBC style trips.  However, assuming things are configured correctly, the trip action will be defined by the TZCTL.TZA/TZCLT.TZB settings.

    Hopefully this explanation, along with the figure I mentioned in my previous response, will help.


    Thank you,
    Brett

  • 0 in reply to Brett Larimore
    TI__Mastermind 32400 points
    Hello Brett,

    > However, assuming things are configured correctly, the trip action will be defined by the TZCTL.TZA/TZCLT.TZB settings
    and this is the point. Customer has 3 different events (see above) and need 3 different actions on PWMA/B. So this is not possible? Only the action for TZCTL.TZA/TZCLT.TZB will be set.

    Regards, Holger
  • 0 in reply to HS FAE Germany
    TI__Guru 57255 points

    Hi Holger,

    That is correct & is one of the weaknesses of the current ePWM peripheral.  One that we are looking to enhance in future devices.

    Depending on the exact need, it is sometimes possible to create workarounds to meet the need. 

    For example, since DCxEVTn gets its own set of actions, could try to input a PWMCLK-by-PWMCLK proper waveform for which it can trip to.  You may be able to duplicate your PWM waveform on a spare PWM channel.  You could then utilize it's CBC trip functionality to build one type of waveform & feed it as an input into the DCxEVTn of your primary ePWM.  You could then use that ePWM's CBC and DCxEVTn events to force the ePWM the way you want based on the situation. 

    Another thing that may be useful is the logical OR & AND gates at various points within the signal chain. 

    I'll advise some others of this thread in case they have additional advice.


    Thank you,
    Brett

  • 0 in reply to Brett Larimore
    TI__Mastermind 32400 points

    Brett,
    I'm not sure if I can follow you with workaround. May be you can do it more concrete on the customer use case?

    Regards, Holger

  • 0 in reply to HS FAE Germany
    TI__Guru 57255 points

    Hi Holger,

    My comments on a workaround were deliberately vague because there are various possibilities.  I was just giving some options that can build up a workaround.  As you say, it would need more analysis around a specific usage.


    Thank you,
    Brett