Dead band pwmB pulse is shorter than pwmA seems reverse of datasheet illustration.

Mon ami - as requested (privately) your writing is not the easiest to understand.

Your post BEGS for Scope Caps - showing:

• Both PWM Outputs (labeled A, B) during NO/ZERO dead-band assertion
• Both PWM Outputs (labeled A, B) during SLIGHT dead-band assertion
• Both PWM Outputs (labeled A, B) during MAJOR dead-band assertion

Such would far better illustrate your issue.

While you (claim) code is easy - so often posters make that claim - and then (significant) error or misinterpretations are detected.

Suspect the suggestions herein will be welcomed by vendor staff...

Top trace dead band generator pwmA 1.2-4us RED pulse 120ns falling edge up to 37us of inverted rising edge pwmB (bottom trace) is the programmed falling edge delayed FED producing single 120ns pulse. The 37us +120ns rising edge delay could perhaps be transparent between the top and bottom edges never no less than 120ns. Yet that does not explain why such a wide on time (4us) pwmA where seemingly pwmB should include inverted 120ns FED + any duty cycle. The pwmA may include 120ns RED but it can't be triggered explicit as pwmB FED. 

Scope cap (just one) you provide is as mysterious as your writing.   (and that's confirmed by vendor's inability to understand, as well)

Requested was Three SCOPE CAPS:

• PWM A & PWM B with NO/ZERO dead band assertion
• PWM A & PWM B with SOME dead band assertion
• PWM A & PWM B with LARGE dead band assertion

Your helpers' efforts would be eased if you generated PWM pulse w/near 50% duty cycle & 10KHz frequency - so that (both) PWM A & PWM B could be clearly viewed.   This is necessary so that any timing differences between PWM A & B can be quickly/easily/EFFECTIVELY noted.   As it now stands - scope trace is w/out value!

It was also suggested that ANY load (other than 10K R to ground) should be removed from both such PWM outputs!   Unknown if that's been done - think KISS (always)!

Hi Chuck,

May have need to add capture and question is from the perspective of high side dead band generator An1 and low side Bn2. Across generators as it were, not A/B on the same generator. Just seems odd there is no way to view the high side 120ns delay and we end up with a longer on off time versus the 120ns programmed delay.

Have noticed when both A&B are low in the capture above the An1 side has minute zero vector inflection where Bn2 is 120ns pulse. Capture represents startup motor speed (slow duty cycle) where say 960 270 RPM the high side delay An1 produces a 2us low pulse period and Bn2 120ns dead band pulse.

Was expecting both An1 & Bn2 to produce 120ns pulse for both sides across generators after any PWM periods both were previously high. So it seems only the low side is being protected from shoot through at any given time if the high side remains high during 120ns delay of Bn2.

@Chuck,

Amit, poster Robert et moi have (some) history w/poster "BP."   I suspect that he has the (incorrect) belief that "dead band" may operate across (different) PWM Generators.   I do not believe that to be the case.   I hazard the guess that he's monitoring "PWM_A" from one generator - and "PWM_B" from a second (different) generator.

BP is focused upon BLDC Control in which - at any one time - One Motor Phase High Side FET and a (different) Motor Phase Low Side FET are "ON/Active" together.   My sense is (this) is what BP believes to be controllable by "dead band."   Of course this belief is wrong as there is never any harm - even with ZERO dead band - when two DIFFERENT Phases are driven!   (via one Phase driven "high" - the other phase driven "low."

IMO - dead band refers to PWM_A and PWM_B w/in the SAME PWM Generator Module - not across different phases.   It is only this SAME Phase which may suffer (deadly) "shoot-thru" due to "cross-conduction" (the simultaneous passage of (near) unlimited current thru ONE Phase's High and Low Side FETs - thus completely bypassing the motor - and destroying both FETs!) 

NO such cross conduction is possible when driving "Phase to Phase!"   (the motor's phase windings preclude such)

It IS possible to implement "dead band" across all three PWM Generators individually yet the dead band appears - (always and only) - imposed between PWM_A & PWM_B of the specific PWM Generator.   (i.e. Gen_0, Gen_1, Gen_2, Gen_3)

Robert - thank you - over the years I've learned to (almost) interpret "BP" writings. (sometimes)

Privately (earlier) I did ask BP to provide scope caps of his "PWM_A and PWM_B outputs" from the SAME GENERATOR! (that's the only method that makes sense - as "Shoot-Thru" (only) inflicts its damage across the same PHASE PAIR of FETs - NOT across DIFFERENT PHASES! Those "different" phases impose (the safety) of a motor winding - thus NO deadband (imposed upon different phases) is required - nor desired - as it intrudes upon the maximum PWM duty cycle able to be delivered...

Improper understanding (often) leads to a cascade of "false conclusions" which insure that "house of cards" is built - but upon an unstable & uncertain (and questionable) foundation...

Hi Chuck,

The capture above depicts two different generators still should have somewhat symmetrical periods in 3 phase PWM. Sorry for using shorts to describe the dead band generators conditions.  Even if testing  the same dead band generator output pwmA/pwmB the signals are not symmetrical in pulse width top to bottom not by nanoseconds rather by microseconds.

Given that PWM- generators B output is dropped A inverted to form dead band delay A and B for the same 1/2 bridge the wave form. Seemingly the pulse widths should be more symmetrical yet inverted, appears as if dead band is all that is enabled on pwmB as there is no PWM generator pulse widths to match pwmA top trace.

Redacted earlier statement: Discovered both LM3S and TM4C1294 PWMnDBFALL register is not asserting the programmed value instead asserts PMWnDBRISE register value for PWMnDBFALL delay period. 

BTW:

For the record dead band generators should protect both low and high side MOFETS during phase pair transitions of each half bridge. That short rise/fall (programmed) delay occurs in real time as 2 phase partners are driving the very same inductive load. Hence 2 half bridge are driving the same phase pair and dead band is enabled for both active 1/2 bridge partners both sides uniformly pwmA and pwmB. That seemingly is not symmetrical delay period pwmB when active duty cycle is present pwmA.
 
Yet it seems dead band generator is disrupting the pulse width from the PWM generator output driving the dead band delay inputs but only on one pwmB output. Dead band generator pwmA/pwmB outputs are not re-producing wave form pulse width as it has been described in datasheet 23.3.5 figure 23-6.

TM4C1294NCPDTi3: PWMnDBRISE register is asserting as pwmB output delay and PWMnDBFALL register value has no effect on either the delay pulse/period shown in first posted capture bottom trace.

LM3S: It has been captured scope delayed samples pmwB fall delay period at times is present immediately following and directly on pwmA rise delay period output.  Seemingly both are not proper behavior of either TM4C or LM3S dead band generator described in 23.3.5 figure 23-6.

BP101 said:

@Hello World

Uncertain if the "clarity" w/in this twisting/turning thread is (suitable) for the "world."

As (usual) BP understanding differs from that of multiple others - it (must) be then that the group understanding (world's) is wrong!   (again...)

Some might choose to ignore the evidence put forth yet to the TM4C now engages Globally enabled Dead Band update versus a fixed immediate update mode past LM3S dead band generators. TM4C1294 PWMCTRL register has several more switches for dead band update than silicon past NDNR.

That said and LM3S firmware migrate flashed TM4C1294 may have carried a few discovered PWM dead band gremlins into the mix. Perhaps enough reason to move HV inverter over to TM4C gains global dead band update mode????

>> Chuck's comment "The relationship between the two may be more related to the timing/synchronization of the two instead of the dead band generation.

TM4C Dead band register:

Register 52: PWM0 Dead-Band Control (PWM0DBCTL), offset 0x068
Register 53: PWM1 Dead-Band Control (PWM1DBCTL), offset 0x0A8
Register 54: PWM2 Dead-Band Control (PWM2DBCTL), offset 0x0E8
Register 55: PWM3 Dead-Band Control (PWM3DBCTL), offset 0x128

If the Dead-Band Control mode is immediate (based on the DBCTLUPD field encoding in the
PWMnCTL register), the ENABLE bit value is used immediately. If the update mode is locally
synchronized, this value is used the next time the counter reaches zero. If the update mode is
globally synchronized, this value is used the next time the counter reaches zero after a synchronous
update has been requested through the PWM Master Control (PWMCTL) register (see page 1683).
If this register is rewritten before the actual update occurs, the previous value is never used and is
lost.

Hi Chuck,

That older LM3S motor ware firmware migrated to TM4C1294 may enable default dead band register, immediate update. Perhaps that is why a wider pwmA pulse LM3S firmware was thus transferred to the TM4c1294? Could even be the LM3S was never quite right in that area and pwmA is simply passing through, inverted delayed pwmB and no PWM generator pulse width payload.

It seems pwmA is proper pulse width perhaps includes 120ns delay and pwmB pulse width is somehow being kluged?  The low side FETS running hotter than high side FETS has been a long term issue LM3S, especially under heavy current loads. Have been searching long time for explanation why that might occur. Should not pwmB (lower trace) have the same pulse width as pmwA upper trace? Have I misunderstood the data sheet explanation of Dead Band delay? Perhaps this Lm3S may not be asserting dead band in the manor the data sheet suggests?   

See window movie video files below for example delay times. Please disregard other post captures as the intent to show pwmA to pwmB pulse width relationship has been compromised in the context it was produced.

If this scope cap (accurately) reflects a single PWM Generator's PWM_A & PWM_B outputs - it is ONLY your gate driver chip which is saving your FET power stage from instant destruction!     Never/ever should (both) PWM outputs - from the same PWM Generator - be active (high) - as this cap reveals!

And you - at one time - (surely) knew this!   What has happened?

You do your helpers - and yourself - disfavor by ignoring my (earlier & repeated) direction to produce a wider pulse via a ~50% duty cycle.

We would expect to see the lower trace "PWM_B" (maybe) - be "Low" whenever & wherever "PWM_A" is "High."   (i.e. active)   But both are predominantly "High" in this trace - indicating something is very, very WRONG.

As this trace results after you've "Self Awarded" a "Suggested Answer" - may we urge (all) Kidz, "do not try this arrangement on your board at home!"   (And/or "stock up" on adequate fire extinguisher and accessories...)

Oh Robert - always the " naysayer" - had you failed to note the newest, (self-awarded) "Suggested Answer" pennant - flying proudly upon (another) BP posting?

Deadband assumes "new ground" - how much longer before (self-awarded) "Verify Answer" pennant catches the (faint/dying) breeze of this "A pulse not present - (but it very much is) recital of (near) facts..."

Noticed that as well (scratched head ..etc..) then selected scope sample trigger switch (repeat) very sensitive to trigger voltage pot setting. Didn't post capture being unsure validity at the time but repeat trigger enabled the samples show very fine chopping pulses on either side of the 120ns sharp tooth and 2us valley. That still don't explain excessive 2us pwmA pulse width and very short 120ns pulse width during Dead Band times. Signals captured are derived from the same PWM generator and added 120ns delay. Explain that!  Storage scope go figure, my repost re-capture.

The issue of DB pulse position excessive width perhaps revolve around global update flags not being enabled prior to generators being configured in the LM3S PWM master control register. The default (generator immediate updates) if PWM master control has not been configured until later. These PWM Global update flags have been first enabled TM4C firmware, not from knowing they were asserted.

TM4C PWM control registers now include DBGSU and GSU bit setting:

ROM_PWMGenConfigure(PWM0_BASE, PWM_GEN_1, (PWM_GEN_MODE_UP_DOWN | PWM_GEN_MODE_FAULT_EXT | PWM_GEN_MODE_FAULT_LATCHED | PWM_GEN_MODE_FAULT_MINPER | PWM_GEN_MODE_SYNC | PWM_GEN_MODE_DBG_STOP | PWM_GEN_MODE_GEN_SYNC_GLOBAL | PWM_GEN_MODE_DB_SYNC_GLOBAL));

cb1_mobile said:

Never/ever should (both) PWM outputs - from the same PWM Generator - be active (high) - as this cap reveals!

And you - at one time - (surely) knew this!   What has happened?  

This is the key point which (somehow) has escaped your comment - is it not?

As you drill deeper - provide more & more (often "off-mark" & extraneous) detail - this CENTRAL ISSUE remains naked & unresolved - awaiting your (slight) note!

Just the point I was try to make that both channels are supposed to represent dead band delay time (according to datasheet). Notice pwmA top trace (high side FETS) were off longer than pwmB bottom trace (low side FETS) so there was no shoot through condition. Today the 120ns tooth mysteriously shifted over no matter triggering pwmA rising or falling edge. Note dead band generator creates real time events pwmA/B, not so easily saved to storage scope such rapid channel transitions may have been somewhat impaired or not.

Odd that channel B was triggering dead center channel A as it did.  Have seen it takes power off time for update flashed code changes to assert the boot loader copies into SRAM and software reset don't always effect the recent changes made. Perhaps making implicit comparator A/B Odd/Even matches is having an effect today. Suspect GSU should not merely reset PWM generator control registers (0x004) just after PWM gen initialization. Perhaps initialization should set bits in PWM master control (0x000) for the first PWM reload events as it does during each PWMUpdateDutyCycle asserts first time PWMSyncUpdate(). Perhaps that is the primary difference between load immediate (Local) and load synchronous (Globally) directly after PWM generator initializations.  We do that now for basic timers supporting PWM CCP mode and Amit mentioned odd things can occur with PWM load immediate.

 Regarding real time dead band events get some popcorn:

/cfs-file/__key/communityserver-discussions-components-files/908/DeadBandTimer.wmv

BP101 said:

... dead band events get some popcorn:

Love to - BIG Fan - yet Popcorn "popper" followed BP guidance, "Both PWM Outputs HIGH Together!"  

Soon as "smoke clears" poster Robert & I will determine "use case" for, "Pop-CHAR!"  

Viva Dead Band, balky scope pots, and the (incorrect) Subject report of, "PWM_A pulse NOT present!"   

If we cannot perform basic, 2 chan. scope cap - have we (any) chance to, "Roll 'Em and ACTION!"

Did you watch the video of a single phase dead band pwmA 120ns to pwmB 120ns. Stop the video any point in real time shows the dead band delay (pwmB lower trace) is exactly 120ns yet pwmA rising edge might include the 120ns rising edge??

Have confirmed TM4C pwmA/B pulse width changes exactly with changes in the dead band delay user parameter. How might both pwmA/B each dead band delay periods appear on a scope capture?

@Robert & CB1

Excuses do not bring answers to the table. Typically neither of you ever put forth YOUR captures in support of all to often posted snide comments. Past experience with CRT phosphor oscilloscopes adds  fade out persistence to the trace, camera CCD tends to extend the hang time. Traces lowering in intensity indicate a fading or past signal while brighter trace shows current time frame, how difficult is that. Please try to use some discretion before chastising your fellow form members only searching for answers.

The video reveal Dead Band time is a complex real time delay and has no meaning CB1 without pwmA falling or rising edge present to elaborate datasheet text so too posted for easy read. Again the point being made is pwmB is not following the datasheet dead band theory of operation explanation. The 2us pwmA upper trace (re-posted wave form ) represents the minimum pulse width + rise 120ns dead band and pwmB fall 120ns dead band pulse - 1.2us minimum pulse width. Might have been noticed or not that a minimum pulse width 1.2us present in pwmA top trace is completely missing from pwmB only present is the 120ns programmed (fall) dead band pulse.

Again according to the datasheet pwmB is the delayed inversion of pwmA, so where did the 1.2us minimum pulse width go pwmB?

TM4C is no better even adding in new control bits for global dead band sync there remains no programmed 1.2us minimum pulse width that is present in pwmA. That directly seems to indicate the dead band timer has internal timing issues both LM3S and TM4C that have not yet been reported or corrected in both peripheral silicon DIDO RA2. 

BP101 said:

...chastising your fellow form members only searching for answers.

Is "correction & redirection" the (new) definition of chastising?

Does not your forum Subject/Title NOT register as a question - but as a declarative statement - and it proves DEAD WRONG!   And post after post saw you (attempting) to defend it.   Might it be that you were NOT searching for answers - but instead - ramming (mistaken) ideas down reader throats?    Again - your "Subject's declarative sentence did not - at all - register as any search.   Instead - it was your presentation of fact - which could not be!

Perhaps the (very few) here who attempted to guide you - point out (obvious) mistakes, misunderstandings, miscues - are (only) guilty of caring - trying to assist.

(you'll note that vendor staff have retreated to "high brush...")

BP,

Unfortunately, I am unable to follow all of the posts and changing parameters in this discussion in order to adequately answer your question(s). The feature has been tested and proven to work as described in the Datasheet/technical reference manual. With that said, silicon bugs under specific circumstances are not unheard of. This is why I have requested you post a simple project that we can use to recreate the issue that you are seeing or to point out specific issues with the test case, if any are observed. To my understanding, this is what you are asking; is it not?

If the intent of your post is some other point such as announcing to the world and to TI that the feature does not work as a foregone conclusion based on your specific test case without any investigation to confirm your results, then so be it . If this is the case, we can close this thread/discussion with the simple conclusion that your code is not matching the datasheet when all of our testing has shown acceptable results. Why your testing is showing a difference will remain a mystery to us and to all others who read this thread.

Please let me know how you would like to proceed.

Hi Chuck,

There is no specific test other than an example project (PWM) must be modified to work with TM4C1294 also includes dead band.

More research indicates my work around adding minimum pulse width to pwmB fall delay register as it is automatically added to pwmA rise delay does not work. Not sure how much more simple this post can be made, something is not right in the dead band register programming function in Tivaware or other.

The issue revolves around Tivaware ROM function call may not be programming pwmB rise fall register with the parameter value or it being ignored. The work around below adds 120ns dead band + 1.2us minimum pulse width, a value 72 for pwmB  fall time delay register but doesn't change pwmB output pulse width as it should.  Seems pwmB pulse width only reflects the 120ns programmed for pwmA rise register which is producing a 1.2us minimum dead time pulse width, assume is from PWM generator perhaps may include 120ns payload. That pwmA register seems to be correct but for some reason pwmB fall register is either not being programmed or is assuming the value in pwmA rise register.

Update: This statement above had assumed the qs-bldc SW had been debugged to at least ensure DB was enabled if PWM was driving the outputs. It had been discovered a few years ago the opposite was occurring with Halls mode by simple program flow analysis. It had never been discovered the same dead band enable function was disabled soon after it had been enabled also for Sensorless commutation mode.

It would seem Dead Band generator should not output a fall delay or pulse pwmB if it is disabled however it does and fools unsuspecting noncompliance into the Dead Band Schema.

>Never/ever should (both) PWM outputs - from the same PWM Generator - be active (high) - as this cap reveals!
And you - at one time - (surely) knew this! What has happened?

The point being made in scope captures (assumed dead band was enabled) as the PWMxDBFALL register 120ns delay was exiting DBG pwmB output even when DBG was disabled. Long past did PM an plausible fix isolated to Halls & FOC commutation. Just as I years ago discovered DBG was disabled in Halls mode (programmatically) not by any kind of signal analysis as in this post. BTW some type of kluged dead band is being output when generator is disabled (point of video).

The point is that dead band generator is not really disabled as most everyone though and asserts PWMnDBFALL register value out pwmB.

Seems this dead band generator behavior (condition) has fooled even the brightest engineers into believing SW had indeed enabled PWMnDBFALL, PWMnDBRISE. The capture and video show lower trace pwmB asserting PWMnDBFALL register value when it is actually disabled. This bazar condition exists when pwmB changes pulse width relative to value disabled yet remains semi active PWMnDBFALL/RISE, perhaps even pwmA - hard to tell.

Enabling PWMnDBFALL or PWMnDBRISE severely reduces bridge power, low side MOSFETS having a longer off time seem to impact ADC current formulas. Had thought high side MOSFET pre-charge was being reduced after actually enabling dead band but that is not the case.  If this is the way dead band is supposed to work it has not been documented for the disabled condition in the data sheet.

Other words "Giving it all she's got captain but the BLDC motor is stuck in some kind of gravimetric vortex."

A new video showing what seems to be dead band pwmA/B rise/fall register programmed for 180ns on same 1/2 bridge, dead band is disabled. Had to reduce the video quality to keep size small but pause as before freezes the capture frame to relate the real time event.

The trailing ringing signal seems to be an artifact of the dead band generator pulse delay but how can 360ns delay exist when dead band disabled? We can prove that pre-charge function clears dead band (disables) but never re-enables post PWM outputs being turned on.

Again as stated Chuck when enabling dead bad generator (bit) (PWM_n_DBLCTL/ENABLE) after pre-charge we get two center aligned active high pulses pwmA/B, top pulse is shorter than bottom. Extremely low bridge power results and the motor will not start or even run. The PWM signals pwmA/B of copartner 1/2 bridge flip flop at 12.5kHz(80us) produce three 80us pulses 240us wide with 1kHz duty cycle between, will not start motor. That scenario produces no useable FET avalanche energy.

Past long ago interleaved Dead band into the PWM output enabled for Halls/FOC drive and motor would start/run. That routine checked if the low side outputs were asserting then (shortly) enables dead band generators, outputs 6 pins state then immediately cleared dead band (disabled). CB1 challenged me on that find then he conceded it was not enabled, later agreed with him that Halls didn't need dead band and backed out the patch. Now understand dead band still asserts PWMn_DBRIS/FALL register all along even when it is disabled. That seems to be the magic trick (condition) 1/2 versus full dead band generator protection mode or someone perhaps left out a few details in the datasheet. Also pwmB is not responding directly to values of PWMnDBFALL register and as stated earlier seems to assert or use PWMnDBRISE value for both rise and fall. That can be easily confirmed  by multiplying the PWMnDBFALL value x 2 has no impact on pwmB out pulse width.

/cfs-file/__key/communityserver-discussions-components-files/908/DeadBandTimer2.wmv

Hi Chuck,

Copied post back to this thread removed previous thread. Sorry for using term errata for describing an peripheral action that is not specifically detailed in the datasheet. We have confirmed on our part and presented to TI odd behavior of dead band generator over two years ago. Yet nothing has been updated post LM3S in the TM4C data sheet dead band section detailing PWMnDBRISE/FALL register are asserted even when the PWMn_DBCTRL Enable bit is not set. That seems to show some negligence on TI part especially since the (pwm) application has not been written to run on the EK-TM4C1294NCPDT-XL.

This dead band condition is asserting PWM0nDBFALL/RISE registers when disabled, perhaps result of a SW loop disabling it (edit unfounded)? Motorware SW was developed by TI engineering (qs-bldc v10636). It may be a perpetual gate driver capacitor charge state machine (pre-charge) is looping and perhaps asserts condition? (edit unfounded) This condition being necessary to build functional 1/2 bridge drive signals may be undocumented yet seemingly correct dead band generator behavior.

According to Fairchild engineers high side gate driver boot strap initial capacitor charging cycle asserts low side FETS for millisecond count, after boot strap capacitor is fully charged the gate driver preforms that duty not SW. The condition of PWMnDBFALL/RISE asserting pwmB when disabled thus drives low side FETS more often ON state except for 120-180ns dead band off times asserting (disabled) pwmB, in this case 12.5Khz(80us) PWM periods. Seems someone took advantage of a condition in the LM3S and it preforms equally as (undocumented) in the TM4C.

That condition creates a lot of 3 phase bridge power though unbalanced as a result. Disabled dead band generators are seemingly working in some kind of half protection mode. Robert and CB1 both acknowledge the first video does not specifically represent a dead band signal. Our V36 BLDC motor produces 1.5 horsepower but loading the bridge any further starts to drive both low an high side MOSFETS junction temperature as result of dead band being disabled in bazar (assume) is a dead band 1/2 protection mode when disabled????

CCS debug register view posted above shows the TM4C PWMnDBFALL/RISE registers in disable state even after previously enabled, suspect SW looping state machine (unfounded). If we ensure the PWMnDBFALL/RISE registers are enabled via setting PWMnDBCTRL bits and stop looping pre-charge state machine then the bridge looses all current drive except we hear phases emit duty cycle 12.5Khz frequency.

Esteemed poster CB1 does not receive "Mr." salutation...   Strange that.    Neither Robert nor I opened your video(s).   (scope cap far preferred)

Funny conversation, by the way ...

Strange that. Neither Robert nor I opened your video(s).

Neither would I. Albeit my PC is immune against some of the most notorious attack/troyans/hacks (using Linux), I'm always wary when the means (video) are not quite justified by the problem. That somehow reminds me on the phishing mail I got today: "There is a problem with your PayPal account, please log in and verify your credantials !". With the years, one just gets cautious.