Enabling multiple PWM Generators with "full" Deadband Control...

Hello cb1,

Thank you for your diligence and for setting the record straight!  We commonly use all 4 PWM generators, both with and without deadband, and have never observed odd effects either.  Nice of you to lay potential suspicions to rest though.  In our case, the parts are TM4C123xxx and the API is TivaWare (which has also been unfairly maligned in the past;-)

Regards,

Dave

Thank you, Dave - as always it's enjoyable for staff/cb1 to register (another) Dave/Da Source sighting.    (crack staff seeks, "More Dave!)

Now we number "two" who have succeeded w/multiple PWM Generators and "healthy" Deadband - achieved upon both (current) and (past) vendor MCUs.

Beyond the (likely) errant report of "troubled deadband" - readers were advised that only by, "Launching & then "Pausing" a VIDEO" - could the deadband's defect be noted.    I cannot (ever) recall  such (paused, video-view ONLY) requirement.   (Say what?)

No such outrage is inflicted w/in the (video and pause-free) multiple PWM Generators (under deadband) screen-cap - presented above...

Poster reporting his deadband defect would do well to employ KISS...   Most likely PWM & Deadband configuration and/or set-up code produced poster's issue... (which only a "paused video" may (sometimes) reveal...)

Again, greetings.    Let the record show that our "PWM/Deadbanding, Protesting Poster" would not accept the screen caps (kindly) provided earlier here (above) - and "moved the cheese" - seeking "New Caps" with two different parameter values.   Not one to "duck such challenge" the new screen caps (once more) demonstrate vendor's TM4C123 MCU to "CONTINUE" to perform to spec!   (note that LM3S16xx and LX4F23x also performed to spec!)

Protesting PWM Poster has been asked - repeatedly - to provide the shortest code blurb which demonstrates his (claimed) "BREAK" of PWM_B when deadbanding.   (poster claims "runt" or other distortion - which has NEVER been replicated by poster "Source 2" or this reporter.

Suspicion must fall upon protesting poster's set-up and/or config of PWM and/or deadband.

Presented (below) is PWM_B (CH4, green) w/parameter LAG > Lead.   NO Issues noted.

And here - Lead > Lag.   Again - NO Issues.

And finally - at protesting poster's request - a "blow-up" of PWM_B (green) - which displays NO Sign of poster's (claimed) "ringing."

It appears prudent for "protesting poster" to re-examine his code - and "work-arounds" as several here have been unable to replicate his (strange) findings...  

Any fair review would note vendor's PWM (under deadband) to fully & properly maintain specification...   (we continue to "welcome" poster's, "smallest code blurb which "Breaks" this PWM under deadband.")   (history of Rome - multiple incidentals - NOT so much!)

Oi - our PWM PUZZLED PROTESTING POSTER (4P) (how clever is that?) moments ago claimed that "PWM_B" would "BREAK" if one loaded smaller parameter values.   Of course firm/I doubted that - yet in the interest of "defending this vendor" we ran "4Ps" directed test.

We always (and only) employ the safety & security of StellarisWare 9453 - aimed at our TM4C123 - w/this line of code:

PWMDeadBandEnable(PWM0_BASE, PWM_GEN_2, 3, 10);   // thus parameters are (now) 3 & 10, our SysClock is 50MHz

And the following scope-cap resulted:

I told "4P" that such small parameter values would be unrecognizable on screen.   (unless I key on just the initial pulses rising edge)   Clearly the deadband DOES NOT SUFFER FROM THE MALAISE our protesting poster reports.

And again - others & myself have requested the MINIMUM CODE WHICH BREAKS "PWM_B" and it (still) is not forthcoming.  

Absent poster "4P's" presentation of such mimimum code - firm/I (and multiple others) must conclude that poster's report and/or methods are flawed - and that vendor's MCUs and API behave correctly...