Clearing a latched PWM fault LM4F232

Have given your code quick scan - can't quickly/easily see the problem.

Unsaid in your post - what is the nature & duration of the "fault signal" you inject into GPIO_PF4_M1FAULT0 ?   To test/verify the "Latch Fault" function - does it not make sense to initially generate a very brief pulse signal on PF4 - and then observe the PWM signals cease - even after the fault condition (in hardware - input to PF4) has restored to non-fault levels?  This would prove the "latching function" of your PF4 fault input. 

Next test/verify condition would be to "clear the fault" (as you've done) while insuring/observing that the PF4 input is not still @ fault level.  This may be the case you're presently encountering (fault condition persists on PF4).  Suppose also that this pin may not be returning to proper "known" state when not in non-fault (normal) condition.  Please detail for us - have you included proper pull-up/pull-down?  (fearful of internal R when used as PWM Fault Input)

This seems like quick/easy test for you to perform - we have smaller F4 MCU - can perform similar test for you should this diagnosis not prove correct.  Kindly attempt & report...

More details on the test I did:

I am using an EKK eval board where I am hardwiring a fault input to 3.3V through a 1k resistor. The following two cases I have tested:

UNLATCHED mode:

- Come out of reset with FAULT0 hardwired to 3.3V through 1k
- Remove 3.3V pull up, fault kicks in, PWMs go all low
- Reapply 3.3V pull up, fault self clears, PWM appear in all pins

This proves that the configuration of fault is correct and unlatched operation works as expected.

LATCHED mode:

- Come out of reset with FAULT0 hardwired to 3.3V through 1k, I get no PWMs
- Remove 3.3V pull up from fault
- Serial port query through PWMGenFaultStatus() and return a FAULT0 fault
- Reapply 3.3V pull up to fault
- Clear faults through PWMGenFaultClear(), still no PWMs
- Query fault through PWMGenFaultStatus() and returns no faults, still no PWMs

I am also running out of debug mode to make sure that debug mode is not interfering with the PWM generator. I am very suspicious about the fact that I never get any PWM activity when using LATCHED.

This description of your LATCHED Mode test much improved - we believe.  Surely you should be generating PWM with Fault0_pin @ 3V3. 

a) Have you tried multiple PWMGenFaultClear() functions (with delays between each) - in the event one or several of these clears are being swallowed? 

b) Like you to start the test from LATCHED Mode - w/3V3 signal applied to Fault0_pin. 

c) Are you continually monitoring PWM activity?  Is it possible that PWM "bursts" or "restarts" - after you've stopped monitoring?

d) You report, "running out of debug mode," - hard for my group to fully understand.  It is possible to program the PWM generator to continue running via PWM_GEN_MODE_DBG_RUN but you must be very, very cautious should you connect a motor or other power circuitry.  All of the tests you've outlined should be with your program running - is this the case?

e) This is "brute force" method - may provide a clue - ask that you observe & log all PWM registers while "UN-Latched" with PWM outputting normally.  Then repeat test from "Latched" - searching for differences w/in PWM critical registers.  (PWM output especially)  This hopefully will narrow scope of investigation - identify "smoking gun."

Not thrilled with test/verify via pull-up R mechanically inserted/removed.  Might your PWM_Fault pin "float" when you remove the pull up R?  (antidote is pull-down - much larger value than pull-up)  Again - I'm fearful upon reliance upon internal pull-up/down while the pin is in non-GPIO mode.

Perhaps an even better method for test/verify is to feed PWM_Fault pin from another GPIO configured as normal (push-pull) output.  In this manner you insure that signal level @ PWM_Fault is always valid - and via SW you can precisely control the duration of this fault-generating signal.  Wish that I had concrete "do this" - perhaps if you try/report we can identify something...

I followed your instructions, it never occurred to me to do a full register dump and hex compare both files.

I found the problem but I don't understand what is going on. It seems I need to clear the fault by calling two statements: fault clear and interrupt clear.

		PWMGenFaultClear(PWM1_BASE, PWM_GEN_1, PWM_FAULT_GROUP_0, PWM_FAULT_FAULT0);
		PWMGenFaultClear(PWM1_BASE, PWM_GEN_2, PWM_FAULT_GROUP_0, PWM_FAULT_FAULT0);
		PWMFaultIntClearExt(PWM1_BASE, PWM_INT_FAULT0 | PWM_INT_FAULT1 | PWM_INT_FAULT2 | PWM_INT_FAULT3);

A fault seems to set flags in PWMRIS (raw interrupt status), PWMSTATUS and PWMxFLTSTAT0 . The statement I was missing was the interrupt clear, though I could not find anywhere in the manual that this is the correct sequence to clear faults. Maybe I missed it or maybe I am just not getting along with this micro...

Thanks for the help

Glad that my guidance/interest helped - you deserve great credit for identifying the issue - and then following the plan as suggested - and then reporting your outcome.  (always so "uninspired-uncaring" when requesting poster's announce, "it works!" - giving no hint of what, where, why, how!)  My belief is that TI does not properly emphasize "forum-maximizing" protocols...  (this reporter now ducks...)

Bear in mind that many of these advanced PWM capabilities are newly introduced - those writing tech manuals are sometimes "too close" to the action to fully identify and safeguard all pitfalls.  I am in process of implementing BLDC motor control on a smaller scale M4F device - and had planned on using the latched PWM_Fault_pin to gain improved loop management.  Will run independent series of tests - and report findings & work-arounds here.  (hope is that additional "live/focused" data will be of value to TI tech staff)

Should state that "so far" our group has found "zero" PWM coding examples which exploit the rich PWM feature set of the new M4F...  (hopefully these are, "in the works" - but nothing at all - thus far)

Perhaps this finding (re: your listed code) explains your earlier issue:

PWMGenFaultConfigure(PWM1_BASE, PWM_GEN_1, 10, PWM_FAULT0_SENSE_LOW);    //   Your code - note your use of the 3rd parameter "10" here
PWMGenFaultConfigure(PWM1_BASE, PWM_GEN_2, 10, PWM_FAULT0_SENSE_LOW);

Now latest SW-DRL-UG-8555 advises wrt function PWMGenFaultConfigure()    Description:  This function configures the minimum fault period for a given generator along with the sense of each of the 4 possible fault inputs. The minimum fault period is expressed in PWM clock cycles and takes effect only if PWMGenConfigure() is called with flag PWM_GEN_MODE_FAULT_PER set in the ulConfig  parameter. When a fault input is asserted, the minimum fault period timer ensures that it remains asserted for at least the number of clock cycles specified.  Do note - you "seem" to have made this assertion via parameter #3 "10" - even though you have not formally declared PWM_GEN_MODE_FAULT_MINPER w/in your ulConfig parameter for this function...

Now moving to PWMGenConfigure() - again SW-DRL_UG-8555

Setting PWM_GEN_MODE_FAULT_MINPER allows an application to set the minimum duration of a PWM fault signal. Faults are signaled for at least this time even if the external fault pin deasserts earlier. Care should be taken when using this mode because during the fault signal period, the fault interrupt from the PWM generator remains asserted. The fault interrupt handler may, therefore, reenter immediately if it exits prior to expiration of the fault timer.  Does this not - to some degree - describe your issue and possible causal nexus?

I attempted to limit this unwanted effect by alerting you to a much more controlled, GPIO toggle of the PWM_Fault_pin.  (as opposed to mechanically keying a pull-up R)  My code is now instrumented - am able to monitor (and log) 6 channels of PWM activity - and will report the behavior of my M4F's PWM in response to various controlled duration signals upon the PWM_Fault_pin...

Thanks for the thorough explanation and appreciate you following up. One of the reasons I post solution code is that often I come here to look for other people's solutions to problems. I hope that whatever I post here contributes to the community.

Moving on to what you explained, I think I understand the following: ulMinFaultPeriod is a count of clock cycles that the fault is kept latched even if the fault pin is deasserted. In other words, if the fault coming from a gate driver at the fault pin lasts 2 clock cycles and the ulMinFaultPeriod is set at 10 cycles, the PWM will remain off for 10 cycles. This implementation allows a 'hardware way' to clear faults for a specific amount of time. I still don't see why the interrupt fault flag is asserted.

The fault input should not be sensitive to uncontrolled asserting. In many cases, the output of gate driver fault are MOSFET pull downs through an RC load. I have seen cases where hardware engineers would add signal conditioning that would make it worse. Still, with other micros that I worked with, they responded very well to a noisy fault input: once asserted, it latches and waits to be cleared by software or automatically if enabled.

In this case, I am clearing faults manually through serial port command, having a very large time delay from mechanically pulling fault up to sending a command to clear the fault. This should rule out the ulMinFaultPeriod.

What I found very interesting is that a fault for generators 0 and 3 affected, both in status and raw interrupt, even though generators 0 and 3 are NOT configured to operate or trigger faults. I chose to ignore this for now.

I am a bit disappointed with this micro and TI. I wish there were more examples on configuring peripherals and a bit better documentation. I had much less problems with other manufacturer's M3s and M4s. Worse yet, I have just scratched the surface of the problem: I still need to configure ADC linked to PWM to sample through DMA on interleaved channels with alternating configuration per control loop interrupt. I expect this is going to be a nightmare...

Thanks for your help. I will continue moving forward.

Hello Paul and CB1,

Thanks to this thread, I was able to lay my PWM fault reset issue to rest (for now).  Although I had specified "PWM_GEN_MODE_FAULT_NO_MINPER", I too needed to add the call to "PWMFaultIntClearExt" to reinstate PWM output (as Paul discovered).

Perhaps there is more to be revealed down the road, but for now I can move on to the next item in a long list...

Thanks again guys!

Regards,

Dave

Might there be a "still better" means to achieve your desired PWM, Fault Modulate, objective?

Your current method demands that your software recognize the fault - and then execute multiple, "PWM function calls" - to relaunch PWM output.  And - in some unfortunate instances - the disturbance which creates that PWM Fault may wreak havoc w/your running code.

Propose a fully "automatic" - MCU HW based method - which accomplishes your PWM modulated goals:

a) w/in function, "PWMGenConfigure()" change to include params: "PWM_GEN_MODE_FAULT_EXT" and "PWM_GEN_MODE_FAULT_MINPER."  Eliminate the "...NO_MNPER" param, of course.

b) add or adapt, "PWMGenFaultConfigure()" to include the time (in PWM clocks) for the MNPER to assert and add, "PWM_FAULTx_SENSE_HIGH" (if the fault is triggered by your PWM_Faultx pin going high.)

These 2 functions - when properly added - will "automate" the cessation of any (or all) active PWM outputs - for the prescribed MNPER duration - and then restore those PWM outputs w/out further intervention - upon the fault's clearing. No further interrupt handling is required.

This method is especially ideal for transient faults - the simple act of "killing" the PWM outputs usually will allow the fault condition to "self-clear" and PWM operation then restores quickly/efficiently - w/out reliance upon further SW mechanisms to, "save the day."  Should the fault prove severe - and PWM cessation cannot "cure" - all PWM outputs will remain inactive - and you may then employ further SW to detect & time this condition - and launch an orderly MCU shut-down.

Hi CB1,

The code was initially implemented, tested and verified as you describe.  By briefy asserting a simulated a fault, and then negating it, the PWM recovers as you described.  As you anticipated, motion stops and dynamics are "violated" during the fault.  (So much for continuous 3rd/4th order derivatives).

I'm using ACS711 hall-based current sensors which, unfortunately, contain their own latch - a latch which will only reset if VCC is brought down below 200mV!  So, there is no real recovery, gracefully or otherwise.  Nonetheless, I am more comfortable having the Tiva latch and defeat the PWM outputs.  The above mentioned current sensors were in place for evaluation purposes and their responsibility is now down graded to short-circuit protection only.

Regards,

Dave

@ Dave,

Oh well - automatic, robust recovery sacrificed @ the altar of, "latch, defeat PWM outputs - and (w/earlier, unresolved concern) "clear all PWM interrupts in sight..."

Such, "nightmare current sensor" may warrant further (superior) down-grade - local landfill always hungry/inviting...