Can PWM generators be configured concurrently for fault input pins and digital comparator trigger.

BP101 said:

can PWMGenFaultSet() set (Group 0 | Group 1) in a single configuration statement?

You do not list "why" you believe there's key/critical advantage via, "single config. stmnt."

Below reveals code my small firm has used w/great success in enabling, "Cycle by Cycle" PWM control:

    ROM_PWMGenFaultTriggerSet(PWM0_BASE, PWM_GEN_0, PWM_FAULT_GROUP_0, PWM_FAULT_FAULT0);
 
    ROM_PWMGenFaultTriggerSet(PWM0_BASE, PWM_GEN_2, PWM_FAULT_GROUP_0, PWM_FAULT_FAULT0);   
   
    ROM_PWMGenFaultTriggerSet(PWM0_BASE, PWM_GEN_3, PWM_FAULT_GROUP_0, PWM_FAULT_FAULT0);

We've made no attempt to reduce this to a single statement.   After all - this is "set-up code" which must be implemented prior to its invocation.  

Note that this code runs nicely upon (retired) 64 pin QFP LX4F - and we harvest 6 PWM outputs - suitable for 3 Phase BLDC Motor - via "just" Group_0.   (I've not tried intruding into a 2nd group...)

Your question expands into digital comparator usage.   We've found - far superior (in our opinion) use of the MCU's in-built Analog Comparator - its output tied directly (and just 2 pins distant) from the PWM Fault Input pin.   The analog comparator provides far greater resolution than the digital comparator - and operates without reliance upon correctly executing/running software - which adds robustness to our over-current detection and orderly PWM "relaxation."

We still (by far) prefer our "SW free" MCU analog comparator as the (main) means to trigger the MCU's PWM Fault Input pin.  As stated - those digital comparators provide very coarse switching levels - not to our (or our clients' liking).

Should you desire - at some point - to sell in volume - you'll find that "Regulatory Agencies" much appreciate the "SW-free" orderly "Cycle-Skip or Shut-Down" - which the PWM control method we've outlined - uniquely & robustly provides...

You may always - quickly/easily - "Or" the PWM Fault Input pin - accomplishing your, "Multi-fault Shut-Down or Cycle-Kill."   (such may (additionally) be accomplished by injecting an appropriate analog voltage into the analog comparator's input...)

Multi-channel method you suggest places far greater reliance upon a "properly" running MCU - which may prove "unwise" when key/critical disturbances have been detected - and total reliance is placed upon the MCU & complex software - to prevent disaster...

>You may always - quickly/easily - "Or" the PWM Fault Input pin - accomplishing your, "Multi-fault Shut-Down or Cycle-Kill."

This method retains  3 external PWM generator current fault pin inputs. Yet adds another layer of sensory that requires ADC1 samples of analog data from two TI LM94022Q temp sensors. Sensors now report MOSFET temperature into the user display.

Little SW configuration to have digital comparator also trigger PWM extended faults. The course COMP0/1 values you state are not so course. Selectable bands and trigger points also have  4 selectable levels of hysteresis triggers or interrupts.

Still need to know if these two groups can co exist like the datasheet text states (and/or) (PWMnFLTSRC0 and PWMnFLTSRC1)?

Typical digital comparator configuration timer asserted polling of Trigger_Processor:

    /* Disable ADC1 Sequence 2 as not to cause a sampling upon configuring. */
     ROM_ADCSequenceDisable(ADC1_BASE, 2);

    /* Set the ADC comparator to trigger a PWM Fault when
     * ADC1 SS2 output transitions into the high-band region. */
     ROM_ADCComparatorConfigure(ADC1_BASE, 0 , ADC_COMP_TRIG_HIGH_ONCE);
     ROM_ADCComparatorConfigure(ADC1_BASE, 1 , ADC_COMP_TRIG_HIGH_ONCE);

    /* Set triggerd assertion comparator 0/1 regions COMP0, COMP1 values.
     * Regions are used to detect crossing region tempeatures
     * in MOSFET Q1/Q5 monitored by two LM94002Q sensors.
     * TempValueLow = -25c  TempValueHigh = 115c (120c=973) */
     ROM_ADCComparatorRegionSet(ADC1_BASE, 0, 2965, 1044);
     ROM_ADCComparatorRegionSet(ADC1_BASE, 1, 2965, 1044);

     ROM_ADCSequenceConfigure(ADC1_BASE, 2, ADC_TRIGGER_PROCESSOR, 2);

     /*Configure ADC1 digital comparator sample sequence compare.
      * Note: Sample sequence data is not stored in the FIFO-2 */
      ROM_ADCSequenceStepConfigure(ADC1_BASE, 2, 0, PIN_MOSTEMP_LOW);  //ANiChan 7
      ROM_ADCSequenceStepConfigure(ADC1_BASE, 2, 1, PIN_MOSTEMP_HIGH | //ANiChan 9
    	      		   ADC_CTL_SHOLD_4 | ADC_CTL_CMP0 | ADC_CTL_COMP1 | ADC_CTL_END);

BP101 said:

The course COMP0/1 values you state are not so course

May we note the (correct) homonym - as modeled (earlier) by this reporter:  Coarse (adjective) - rough or loose in texture or grain.

Digital values are indeed extremely coarse - when compared to the (near) continuous voltage settings any analog comparator provides!

There's little we can agree upon here - time for (another) self-awarded, "Suggested Answer."

I stand by the earlier writings & the code block provided.   Note that my small firm has delivered several thousand such BLDC Controllers - where "cycle by cycle" PWM control is most (and classically) desired - and this "automatic" PWM-modulate method recognizes & protects against transient over-currents - while standing ready to "re-launch" PWM upon the very next PWM cycle.

Your original post - and post title - strived for concurrency - yet that need has descended into the noise...

I have read the text - so well in fact - that we've (long) been able to design/build/ship and ring the cash register...

Again datasheet above post suggests both groups INT and or TRIG can be used for PWM fault detection.. The Tivaware function asserts and text appear to state just the opposite. Question is how to configure both Gen fault input pins interrupt and comparator 0 trigger faults / (groups) as datasheet text suggest is possible?

Amit needs to clarify if both PWM Gen0-3 INT fault input pins and ADC1 Comp 0 TRIG PWM Gen0-3 faults are a valid concurrent configuration.

//*****************************************************************************
//
//! Configures the set of fault triggers for a given PWM generator.
//!
//! \param ui32Base is the base address of the PWM module.
//! \param ui32Gen is the PWM generator for which fault triggers are being set.
//! This parameter must be one of \b PWM_GEN_0, \b PWM_GEN_1, \b PWM_GEN_2, or
//! \b PWM_GEN_3.
//! \param ui32Group indicates the subset of possible faults that are to be
//! configured.
* This parameter must be \b PWM_FAULT_GROUP_0 (or) \b PWM_FAULT_GROUP_1.
//! \param ui32FaultTriggers defines the set of inputs that are to contribute
//! towards generation of the fault signal to the given PWM generator. 
*
//! \b For PWM_FAULT_GROUP_0, this is the logical OR of \b PWM_FAULT_FAULT0,
//! \b PWM_FAULT_FAULT1, \b PWM_FAULT_FAULT2, or \b PWM_FAULT_FAULT3.
*
//! \b For PWM_FAULT_GROUP_1, this is the logical OR of \b PWM_FAULT_DCMP0,
//! \b PWM_FAULT_DCMP1, \b PWM_FAULT_DCMP2, \b PWM_FAULT_DCMP3,
//! \b PWM_FAULT_DCMP4, \b PWM_FAULT_DCMP5, \b PWM_FAULT_DCMP6, or
//! \b PWM_FAULT_DCMP7.
//!
//! This function allows selection of the set of fault inputs that is combined
//! to generate a fault condition to a given PWM generator.  By default, all
//! generators use only FAULT0 (for backwards compatibility) but if
//! PWMGenConfigure() is called with flag \b PWM_GEN_MODE_FAULT_EXT in the
//! \e ui32Config parameter, extended fault handling is enabled and this
//! function must be called to configure the fault triggers.
//!
//! The fault signal to the PWM generator is generated by ORing together each
//! of the signals specified in the \e ui32FaultTriggers parameter after having
//! adjusted the sense of each FAULTn input based on the configuration
//! previously set using a call to PWMGenFaultConfigure().
//!
//! \note This function is only available on devices supporting extended PWM
//! fault handling.
//!
//! \return None.
//
//*****************************************************************************
void
PWMGenFaultTriggerSet(uint32_t ui32Base, uint32_t ui32Gen,
                      uint32_t ui32Group, uint32_t ui32FaultTriggers)
{
    //
    // Check for valid parameters.
    //
    ASSERT((ui32Base == PWM0_BASE) || (ui32Base == PWM1_BASE));
    ASSERT(_PWMGenValid(ui32Gen));
    ASSERT((ui32Group == PWM_FAULT_GROUP_0) ||
           (ui32Group == PWM_FAULT_GROUP_1));
    ASSERT((ui32Group == PWM_FAULT_GROUP_0) &&
           ((ui32FaultTriggers & ~(PWM_FAULT_FAULT0 | PWM_FAULT_FAULT1 |
                                   PWM_FAULT_FAULT2 | PWM_FAULT_FAULT3)) == 0));
    ASSERT((ui32Group == PWM_FAULT_GROUP_1) &&
           ((ui32FaultTriggers & ~(PWM_FAULT_DCMP0 | PWM_FAULT_DCMP1 |
                                   PWM_FAULT_DCMP2 | PWM_FAULT_DCMP3 |
                                   PWM_FAULT_DCMP4 | PWM_FAULT_DCMP5 |
                                   PWM_FAULT_DCMP6 | PWM_FAULT_DCMP7)) == 0));

    //
    // Write the fault triggers to the appropriate register.
    //
    if(ui32Group == PWM_FAULT_GROUP_0)
    {
        HWREG(PWM_GEN_BADDR(ui32Base, ui32Gen) + PWM_O_X_FLTSRC0) =
            ui32FaultTriggers;
    }
    else
    {
        HWREG(PWM_GEN_BADDR(ui32Base, ui32Gen) + PWM_O_X_FLTSRC1) =
            ui32FaultTriggers;
    }
}

>We still (by far) prefer our "SW free" MCU analog comparator as the (main) means to trigger the MCU's PWM Fault Input pin.

Perhaps you missed in all the noise ADC samples feed the digital comparators then trigger PWM fault pins. This method Removes the need of writing SW to read the ADC samples. Static levels in the 3 bandwidth regions add HW trip point constrains disconnecting the PWM control block outputs. The only SW involved is the ADC sample sequencer and digital comparator setup.  

Currently have group 1 analog comparators PWM fault pin interrupts and desire to add that second layer of protection.  That adds long term thermal protection for encounters where the analog comparator may not even come into the picture at all. So we can run attendant free knowing MOSFET junction temperature is being watched like a hawk. 

Rather use the SW-less digital comparator method versus a interrupt vector with SW (<= | =>) no comparator and data based on FIFO samples alone.

And/or infers both groups are possible concurrently, seems plausible since each PWM Genblock has both int/trig fault source groups feeding into each generator module. 

Tivaware posted above states can be group 1 (or) group 2 not a logical OR of both groups as the datasheet text infers and appears even possible.

The regulatory agencies I noted did NOT include FCC. To sell your product widely - in many locales - Safety Agency Approvals are mandated.

I bow to your superior knowledge of/experience with - such agencies...

I don't believe either of the two you recently list qualify as "Safety Agencies."    What labels are "on the rear" of most of your appliances and office equipment?    

Again - you reject the advice/guidance I've provided (never in the spirit of frustrating you) - but in the attempt to reveal why, "our method works - we've gained necessary agency approvals!"

Even where they do not, insurance companies may. Especially in areas of high litigation.

Reading the applicable UL/CSA/IEC/CE etc... standards are illuminating. For instance the requirements for bringing a mower blade to a stop are quite stringent.

Robert

@ friend Robert,

Bingo - indeed "your" biz-experience/awareness reveals - those are the key/critical agencies which require (hoop-jumping).   And charge (dearly) for that jumping privilege.

And - as stated (to the exhaustion of all) methods which "encompass" a locked MCU are viewed far more favorably - thus my small firm's "software-free" method of PWM shut-down.   (past proved/blessed/certified by multiple of the agencies you've just listed...)

And...re "Areas of high litigation"  such would include all 53 US states!   (as one past proclaimed...)

Hi Amit,

Thought that might be the case yet still questionable for reasons listed below.

Are the extended fault mode PWM GEN fault trigger inputs directly coupled to ADC DCMP, automatically set by the ADC1 DCMP configuration shown above? Or is a Mux set required: Must we set the PWM GEN Fault ADC DCM trigger for both INT/TRIG groups in the PWM configuration?

Yes - use PWMGenFaultTriggerSet() separately for each group.

The latter method seems to be missing in (pwm.c), as there is no method of setting DCMP trigger fault mode in PWMGenConfigure(). Though extended fault mode is mentioned there and in the ADC DCMP configure Doxygen text.

We can easily set the GenFault Interrupts but is then missing the second group (DCMP trigger sources 0-7). 

    //
    // Enable each PWM generator block interrupt Fault interrupt 10000h.
    //
    ROM_PWMIntEnable(PWM0_BASE, PWM_INT_GEN_1 | PWM_INT_FAULT1);
    ROM_PWMIntEnable(PWM0_BASE, PWM_INT_GEN_2 | PWM_INT_FAULT2);
    ROM_PWMIntEnable(PWM0_BASE, PWM_INT_GEN_3 | PWM_INT_FAULT3);

And for those seeking to conserve pins - gain full fault monitoring over all 3 phase currents - and meet Regulatory Agency requirements - the code (long ago) posted here (first response) achieves PWM Shut Down via a single PWM Fault Input pin!

I've no opinion upon the code o.p. posted (above) other than it requires that the ADC run fully/correctly - across 3 channels - which "holds hostage" any PWM Shut Down should the MCU, "lock up or should any one of those 3 ADC channels run amuck."   (bring a very deep check-book - and months of time - to the testing agency should you choose poster's method...)

> don't believe either of the two you recently list qualify as "Safety Agencies."
FAA/TSA views ISO9002 and more recently ISO14000 indeed holding accountable most every safety related standard of an organization. Aviation company some I have past worked view annual inspections with gritting teeth. Outlook public folder safety contents being made readily and easily viewable by all employees across the corporate network in expected surprise department inspections where, how to find OSHA related requirements.

>should any one of those 3 ADC channels run amuck

Disagree entirely on the premise the analog comparator input/output is not beholding nor is the current shunt to any single PWM drive or analog input. A single analog interrupt can occur just as easily when one or all three analog fault monitors are in play.

What ever regulatory agency made that particular nonsense up; 1. That 1 fault input is better than 3 independent analog HW monitors, 2. Adding are NOT dependent on any condition the SW drivers may be asserting at any time, is a far stretch. Look at it from the point in time the current fault occurs mostly when the Low side is firing and not as much drop on the High side MOS which is far less stressed in all 6 PWM transition steps. Possible only advantage is in slow decay PWM current faults occurring on the high side with single current shunt monitor ever the low side gate drive is off. Then again to have DC source electron current flow in the phase it must pass through the low side current shunts and MOS drivers to reach any would be single shunt on the B+ side. The critical key word is source current, the most damaging aspect should PWM SW go amuck.  

BP101 said:

Disagree entirely on the premise the analog comparator input/output is not beholding

When does a "premise" become hard fact?  

Prime Regulatory Agencies for those here - as poster Robert listed - allow that an MCU is able to initialize - then launch an output process - and then such output process must come to a safe, controlled (i.e. graceful) halt upon the MCU's (unwanted) hang.  (which such agencies will deliberately cause/induce/bring about)

Has your "entire disagreement" been backed up by your test of the MCU's analog comparator's performance - after being initialized - and then having the MCU's external xtal interrupted and/or shorted?   (such is one of the Regulatory Agencies', "Tests for Compliance" - there are others...)

Desire to be "right" should not trump a well conceived "test/verify" - especially when "Disagreement is to assume entirety!"

>Has your "entire disagreement" been backed up by your test of the MCU's analog comparator's performance - after being initialized - and then having the MCU's external xtal interrupted and/or shorted?   (such is one of the Regulatory Agencies, "Tests for Compliance.")

Same goes for the single analog input source doesn't it have just as much a chance at failure as do 3 analog inputs. I really don't get how the compliance test would be any different in either scenario. The only real system that limits current when SW goes amuck is an ICL in series with B+. Surely TI insures the analog comparators are not beholding to the MOSC or PLL and that part of the PWM output control block is not reliant on an oscillator.

From my take of extended PWM fault handling (TM4C1294) The analog comparators triggered interrupt is only used for the exception fault process but the PWM output  control block will still be switched disabled cut off even if the trigger interrupt is not asserted.  That's why we must hard wire the output of each comparator pin back into the input on each PWM Generator making the process SW free. Perhaps the 3 gens fault interrupts are OR'd and use the legacy PWM block fault interrupt 25 when enabled. Not sure yet on the latter but it seems plausible. Any case have just the function to handle that interrupt source.

PWM block fault handler interrupt 25

void
PWM0GensFault(void) //ToDO
{

	//
	// Clear the extended faults PWM0_Gen 1-3 or legacy PB3 Pin 71 Fault interrupt
	//
	PWMFaultIntClearExt(PWM0_BASE, PWM_INT_FAULT1 | PWM_INT_FAULT2 | PWM_INT_FAULT3);

	MainEmergencyStop();

	//An external fault has occured call the main.c fault handler
	MainSetFault(FAULT_EMERGENCY_STOP);

}

BP101 said:

Surely TI insures the analog comparators are not beholding to the MOSC or PLL

Case 0: Comparator triggering an interrupt. Obviously clock dependent

Case 1: Straight analog comparator. Two analog inputs feeding into a comparator, no digital processing. Probably not clock dependent but verify implementation. Some implementations in particular may synchronize the output with the CPU clock.

Case 2: Comparator feeding off of A/D conversion. Obviously clock dependent since the A/D is clock dependent.

Clock dependency of the output trip is implementation dependent. Needs to be verified. Again some implementation may synchronize the shutdown. More likely for latched shutdowns. My expectation would be that it is probably clock free but not certain and would need verification.

Robert

Once we've configured the Analog Comparator into that mode - and directly connected the comparator's output into the (single) PWM Fault input pin - and employ NO/ZERO Interrupt scheme in that process - our LX4F's analog comparator performs exactly as desired - even if - and especially if - the MCU is (reasonably) disrupted.

It is our finding that such regulatory agencies have the "expectation" that software dependencies have not proved as robust as (near) hardware only implementations - which is what we've strived toward in our 3 phase, BLDC Controller design.

We should note too that our design ALSO provides the classic, "Cycle by Cycle" current limiting/PWM Shutdown upon over-current.   Can & does "restore" PWM output upon the very next PWM cycle - when the analog comparator signals, "all is well."   This method eliminates "nuisance shutdowns" so often caused by "normal" transients - which prove disruptive/unwelcome - and so well managed (i.e. avoided) by our implementation...

Time invested here exceeds the allotment - entirety of bp disagreement (i.e. "guess") not withstanding!

Those what if's seem to come out of nowhere.

Like what if an employee gets his hand stuck in the conveyer belt system and the analog comparator cut off is constrained by PWM auto resets every 900ms when only (PWM_GEN_MODE_FAULT_MINPER ) was configured (No fault interrupts). Seems the motor keeps running under it rotor inertia yet the PWM drive Panics at a 900ms 18us interval. Hardly enough time for that poor employee to pull his hand out even possibly dragged up the line a few 100 feet or so.

The automatic emergency stop motor fault interrupt is viewed by OSHA as a life saving SW implementation. So CEC may not be concerned with the human aspect or should be if they want to keep their ISO9002 certifications. Seems we can have our cake and eat it too with the right PWM configurations

> Can & does "restore" PWM output upon the very next PWM cycle - when the analog comparator signals, "all is well."

This food has me thinking about ISO9002 safety valve in such a robust topology:
Perhaps an auto brake drive would be more fitting if current exceeds the maximum while (PWM_GEN_MODE_FAULT_MINPER) strikes the 18us PWM bell more than a few 100 times.

Wonder how that might be implemented?