• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 32 subscribers
  • Views 1103 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.

TM4C Latching PWM Fault

KM01
Intellectual 295 points

Hello,

I am working with 8 PWM channels and each has an independent fault flag (they each have to independently handle faults, low indicates a fault). I am trying to set up a fault handler that will latch the respective channel when a fault is present (the fault flag triggers). I need the channel to latch and then be handled in an ISR per the scope of their use. However, with my setup, I am not getting the fault to trigger a jump to the Fault ISR. I am wondering if I initialized the channels incorrectly (see below) for my task. Another question I have, once I get the fault flags to trigger a jump to ISR, how do I know which base/generator saw the fault? Each channel is on a unique base/generator so that they will not be affected by faults on other channels.

ROM_GPIOPinConfigure(GPIO_PH0_M0PWM0);

ROM_GPIOPinTypePWM (GPIO_PORTH_BASE, GPIO_PIN_0);

ROM_PWMGenEnable(PWM0_BASE, PWM_GEN_0);

ROM_GPIOPinConfigure(GPIO_PK4_M0FAULT0);

ROM_PWMGenConfigure(PWM0_BASE, PWM_GEN_0, (PWM_GEN_MODE_UP_DOWN | PWM_GEN_MODE_NO_SYNC | PWM_GEN_MODE_FAULT_EXT |

PWM_GEN_MODE_FAULT_LATCHED | PWM_GEN_MODE_FAULT_NO_MINPER | PWM_GEN_MODE_DBG_STOP));

ROM_PWMGenFaultTriggerSet(PWM0_BASE, PWM_GEN_0, PWM_FAULT_GROUP_0, PWM_FAULT_FAULT0);

ROM_PWMOutputFault(PWM0_BASE, PWM_OUT_0_BIT, TRUE);

ROM_PWMOutputFaultLevel(PWM0_BASE, PWM_OUT_0_BIT, FALSE);

ROM_PWMOutputState(PWM0_BASE, PWM_OUT_0_BIT, TRUE);

TPWM_StatusEnabledSet(HAL_PWM09, TRUE);

ROM_PWMGenIntTrigEnable(PWM0_BASE, PWM_GEN_0, PWM_INT_CNT_ZERO);

ROM_PWMIntEnable(PWM0_BASE, PWM_INT_GEN_0);

Thank you.

  • 0
    TI__Guru**** 244400 points
    Hello KM01,

    There are 2 important things missing in the code

    1. Enabling the Interrupt for Fault Generation in the PWMINTEN
    2. Enabling the PWM Fault Interrupt vector in the NVIC as the PWM Fault interrupt is a separate interrupt vector

    Regards
    Amit
  • 0
    Guru 47900 points

    KM01 said:
    I need the channel to latch

    Sometimes - an improper "specification" may over complicate one's objective.

    Why do you believe that the faulting channel must latch?    What if the fault is very brief (transitory) and cures itself - does that demand the complexity and effort imposed by 4 distinct, PWM Fault ISRs?    There's not enough data w/in your post to (really) determine if both that "latch" and interrupt effort is mandated.

    As a far simpler - and faster to implement alternative - my group employs the, "non-latched and "ISR free" method - as achieved via parameter, " PWM_GEN_MODE_FAULT_MINPER" w/in function, PWMGenConfigure().    Again no specific Fault ISRs are needed - yet transient faults are managed "automatically" (i.e. with no PWM Fault code's intervention - which makes this method more robust) and the PWM Generation across all (3 paired PWM Channels in our case) is extinguished for a, "Variable, Programmable - and Interlocked time period" which effectively causes a, "Cycle by cycle" current limiting - in our design.   Clients & even "Venture" firms really like the "SW free" attack & release mechanism which this method - rather uniquely - provides.

    While this technique may not prove suitable in all cases - for all designs - this unique, proven effective and far simpler method deserves - at minimum - some mention & consideration...

  • 0 in reply to cb1
    Guru 27665 points
    There is a degenerate case (near dead short) where the power devices stay in the linear region.

    Robert
  • 0 in reply to Robert Adsett
    Guru 47900 points

    And - if when they do so - and current flow exceeds the pre-set "trip point" - all PWM outputs remain extinguished.

    I do not believe the "Latched PWM method" is more capable of handling such, "degenerate case."

    While focused upon degeneracy - note that 10 forum contributors have (each) clicked 500 times - yielding > 5K, "Tell TI" hits.    (even the lovely Ms. Stone - your Spidey's consort - could not spur more to, "Do more than read."

  • 0 in reply to cb1
    TI__Guru**** 244400 points
    Hello All,

    I think there are 2 aspects. Clarity on why the Latched Mode is required from the poster and second being the configuration itself. The IO Pin for external fault neither has been configured nor has the resultant interrupt been enabled. The call of the GPIOPinConfigure function is not sufficient for GPIO_PK4_M0FAULT0. The Pin must be configured as GPIOPinTypePWM for the AFSEL to be set as well.

    Regards
    Amit
  • 0 in reply to cb1
    Guru 27665 points
    It may depend on what you mean by cycle by cycle limiting. In the degenerate case you have to be off for multiple cycle times to stay within the power dissipation limits. Cycle by cycle limiting becomes cycle suppression.

    With a latched limit, the PWM remains off until the SW gets around to re-enabling it. There are alternatives but it is a reason to latch the disable.

    Robert

    At least there are 10 contributors, sometimes such requests are met only with deafening silence
  • 0 in reply to Robert Adsett
    Guru 47900 points
    "Buy me, Gimme, Get me" alive well - this/other forums.

    Posters are willing to "unload their personal needs/desires here" not so much in the attempt to aid the forum as a whole! Not good!
  • 0 in reply to Amit Ashara
    Intellectual 295 points
    Amit,

    I am developing a generic controller. It will be used in applications, where for safety reasons, it will have to be able to shut down a channel completely if a fault has occurred. It will also be used in applications where current limiting is a valid option, in which case, I have developed a section of code that functions as cb1-mobile described in a previous post. I agree with cb1-mobile, that the 'auto-retry' method is much easier to develop and manage.

    I do have another section of code that deals with the initialization of all I/O. All channels used as PWMout and PWMfault are all initialized as GPIOPinTypePWM.

    I will add in the interrupt enabling you mentioned in your first reply and hopefully that will allow the fault to handle as a latch.

    Thank you.
  • 0 in reply to KM01
    Guru 47900 points

    KM01 said:
    for safety reasons, it will have to be able to shut down a channel completely if a fault has occurred

    Devil - once more - alive/well & buried in such, "details."    Language, "Shut down a channel completely" may require further definition.

    While anecdotal - our findings may prove of interest - as our, "Fault Management, MCU Output, cessation mechanism" received "Agency Approval." (in fact they commented very favorably upon the "automatic - SW-free" method we employed - [client loved this as well]   Note this was done w/out use - and the corresponding "extra MCU code execution" of any/all PWM based MCU interrupts.   Achieved entirely w/in LX4F's (TM4C predecessor) HW only!

    SW was required to set-up/config - yet if we, "got that far" all further PWM and/or current limiting was fully automatic.   On a revision of that product we did "tweak" the PWM_MIN value dynamically - as/if/when required.

    Along with proving extremely robust - this method proved superb in rejecting, "dreaded latched, PWM Shut-Downs" which had plagued their previous (self directed) efforts.   Method I've described is ideal for, "Killing all (or select) PWM outputs in response to a nuisance/transient event - and automatically "Re-trying" at the next PWM Cycle.   Our experience reveals - that for most disturbances - the simple act of "killing" the PWM outputs caused the issue to substantially reduce - and often disappear.

    Every use-case & design application enjoys (subtle) differences - but our vote remains solidly w/"PWM_MIN" over "Fault Latch."