How many PWM clocks must pwmA pulse width remain above PWMnDBRISE when PWMnDBCTRL enable bit are toggled.

Hi Amit,

It seems not so much an application constraint as it is a hardware limitation with no documented PWM_CLKS pwmA must be kept high relative PWMnDBRISE.

The application directive has no idea how long the HW takes to transition PWMnDBCTRL bit enable up to PWMnDBRISE considered valid steady state. Without a number PWM clocks we have no way to gauge an exact minimum pwmA remains high to steady state relative transitions of PWMnDBCTRL. Seems that not an issue when DBCTRL bit is left persistently cleared pwmA cycles yet is an issue when DBCTRL toggles relative to pwmA duty cycle changes.

Hi Amit,

Once again blown 15 amp fuse after 2 hours run time with 240ns dead band set PWMnDBRISE/FALL.  Additional padding sets 1us minimum pulse width well above FET blocking time 100ns.  The blown fuse error flag always sets DCUV (under volts) when that happens. Yesterday had several random PANIC flags with 200ns dead band one with faint pop sound others were silent. Today with 240ns dead band a loud pop heard from motor (fuse blew) and not a single M0nFault trip to indicate MOC (motor overcurrent). The odd thing is some days motor will run 4-5 hours without any issue so must be solar flares to blame. lol

Seems like a FET shoot through occurs from dead band generator anomaly that randomly skips PWMnDBCTRL bit set directive for unknown reason.  That is odd because the PWM pulse period is vey low 80us (12.5Khz) and the duty cycle is roughly 78%.

First is the formula being used to set the minimum pulse width. Next code sets dead band prior to turning off any active FETS on pwmA before PWM output enables others true. Do you see anything odd that might lead to what is described?

//
// Compute the minimum pulse width in PWM clocks (16.6us).
// Formula adds 300ns into MinPW of produced waveform. 
//
    g_ulMinPulseWidth =    ((((g_sParameters.ucDeadTime + 2) * 20) +  //DeadTime=14.4 (16.6ns periods)
                            (g_sParameters.ucMinPulseWidth * 120) +  //Min=0.4us
                            (PWM_CLOCK_WIDTH - 1)) / (PWM_CLOCK_WIDTH));//CLKS=16U

Update:

Have added 10 more to each SW parameter (* 30,  * 130) guessing a few more PWM clocks couldn't hurt solar flares. Scope has pwmB static minimum pulse (950ns) and pwmA pulse much wider 9-10us with 200ns dead bands being randomly added. That produces static 79us low side on time and 60-70us high side on time yet the inverter +/- phase pulses are roughly equal and much shorter. Static pulse width pwmB simply refers there is no duty cycle movement but the pin state still changes yet PWMnDBFALL value is never being added or subtracted from CMPB. 

Hi Amit,

Posted similar capture some time ago and observed something new occurring late yesterday on pwmA. Zoom reveals 50ns (3-PWMCLKS) delay between the PWMnDBRISE pulse and duty cycle changes of pwmA rising edge. The duty cycle change pwmA rising edge originate from the PI phase current and speed regulation SW. Had noticed space past was roughly 20ns and considered might be edge jitter or perhaps silicon latency, no big deal or was it?

The 3 PWM clocks delay added to the minimum pulse is likely required PWMnDBCTRL set/clear enable bit setup time plus any latency.  Those edge positions are real time relative pwmA duty cycle and requires video to show. Will try later in the new week to capture evidence of the 3 PWM clocks delay. 

Hi Amit,

It was actually closer to 2 PWM clocks (33.2ns) measuring 50% slope. The pwmA new edge position asserts on either side (yellow box) of the existing position (green box) and jitters a while (33.2ns) prior to committing the new PI and duty cycle 4ms in the synchronous generator updates. So the new position of dead band in the pulse width of pwmA jitters in the duty cycle before steady state occurs. I don't believe such wide gap (33.2ns) prior to adjusting formula a bit more and it simply appeared as rising edge jitter with no gap. 

Sometimes it seems as if the jittering edge is only 1 PWM clock base falling edge trigger CH1 and the jitter is actually occurring on the rising edge. That scope capture is difficult to capture across the local network in 1 second updates. The real time event of edge movement is very constrained by PI in the duty updates.

BTW: I was calling the gap between the first occurrence of rising edge pwmA and additional edges in the gap jitter (not shown). Upon widening +/- gap (33.2ns) reveals it might be required setup time (2-PWMCLKS) for dead band generators rising edge delay as it presented in the duty cycle pulse width update. The gap time acts more like a minimum required edge time for dead band generator 10 bit counter setup reflective of PWMnDBCTRL enable bit being rapidly set and cleared.

The delayed edge (33.2ns) flashes on/off many times in the same position before going solid prior to the next update and edge movement in the duty cycle.

Hi Amit,

Upon review after having several panics increasing dead band 220n to 240ns and having (*20, *120) in minimum pulse width formula the fuse blew. And (*30,*130) formula with dead band (200ns) a gap 33.2ns occurs assume in (4ms) gen sync local global updates of the duty cycle. Only had one silent panic last night after 45 minutes and none at all several hours of testing morning hours.

I suspect the 33.2ns gap becomes the minimum pulse width at certain times in dead band and duty cycle updates. Any thoughts?

The 33.2ns gap might actually represent the remainder of the minimum pulse (400ns) after HW subtracts required setup time or propagation delay of pwmA signal asserting dead bands occurring later in PWM output control block local synchronous updates. The odd part is pwmA off time hovers near 9-10us in the duty cycle and the minimum pulse width constrains minimum off period in the duty cycle. Any thoughts?

My gut tells me to again make the formula multipliers even higher but don't know why logically that should matter?

BP101 said:

previous full explanation and posted control code.

Neither are present or referenced in this thread anywhere.

BP101 said:

The magnitude of waveform (fully explained) is frankly irrelevant when the discussion is regarding edge times and delays of them.

Unless, of course, in the very likely event that the loading that causes a very much reduced signal also affects the timing.

BP101 said:

Not sure you are grasping CH1 represents the captured real time events of pwmA and the control of it's progression of numerous 4ms synchronous update cycles.

It would help if you told us what ch1 represents. It looks as if you have done four separate captures and simply pasted the images together. That might be valid if you told us what the trigger was, then it might be possible to determine what relationships should exist. Frankly, right now, it looks like random images.

BP101 said:

How else is one to post a real time wave form that varies rapidly and has more than one HW constraint without actually posting a video of the scope screen.

OK, they are random images, which makes any conclusions drawn worthless. As to how you capture you set up a proper trigger. Digital scopes in particular have a wide range of possibilities and if those fail you can use an external trigger.

If you don't have a trigger now then you would expect the edge to not be synchronized with the scan.

Robert

CH1 is pwmA edge times in the 50ns grid. One has to consider the 2 vertical lines (200ns) remain static, all the grids align. The left right side vertical line establishes the update time of each successive real time edge position. That is the thing about pulse width changes occurring temporary point in time, they don't hang very long in the same position order to make a point in a forum post relative a SW code piece asserting and constraining them. lol

BP101 said:

CH1 is pwmA edge times in the 50ns grid. One has to consider the 2 vertical lines (200ns) remain static, all the grids align. The left right side vertical line establishes the update time of each successive real time edge position.

So four separate captures of the same waveform with unknown trigger. Worthless without knowing the trigger.

BP101 said:

That is the thing about pulse width changes occurring temporary point in time, they don't hang very long in the same position order to make a point in a forum post relative a SW code piece asserting and constraining them.

indecipherable

Robert

BP101 said:

>"Worthless without knowing the trigger"
Again an irrelevant point in the context of discussing the edge times of the same signal repeated in the same grid.

Highly relevant. Without a trigger those waveforms do not have a common reference point. Without a common reference point you cannot say anything about the timing differences between them. That the grids on different screen snapshots may be pretty but is irrelevant.

Let me try an analogy. Let's say you are traveling on the prairies and and to know how far you are from Saskatoon. A songbird crosses your path, how far away from Calgary are you. A little while later a raptor crosses your path, now how far away from Calgary are you. That's the equivalent of making a time comparison between waveforms without a common trigger.

BP101 said:

>"indecipherable"
Your past complaint to open a real time video capture this Tiva forum and again control SW relative edges is posted above.

Semi-indecipherable and what can be understood is a non-sequitur.

Robert

Rising edges mentioned several times infers a scope triggers polarity falling edge, to the left of the displayed edge. Again trigger is not the issue focus, rather the edge positions in time relative to last sequence in the fixed grid are and remains 50-100ns time base no mater what 3D space a single grid exists. Seems pointless to argue the obvious and gets off focus.

How many PWMCLKS must pwmA remain above PWMnDBRISE???. The real question seems to be not so much how long PWMCLKS must pwmA remain above PWMnDBRISE as it is how often must it be checked to ensure pwmA edge time does not fall below that.

BP101 said:

Rising edges mentioned several times infers a scope triggers polarity falling edge, to the left of the displayed edge.

Such makes PERFECT SENSE - does it not?   "Rising edge infers a trigger polarity falling edge!"   Really - when - where - and upon what Planet?

And:

BP101 said:

Answer to question might lay in how pwmB receives dynamic duty cycle updates

May I vote the post (above) as the least deserving of "Verify?"   (Yet - we just knew - that in time - such would happen...{has many times, before})

Kidz - always beware of "Self-Awarded Verification" (and ghost triggers - and 4 channels (all labeled "CH_1") produced via Cut/Paste...and ESPECIALLY "Rising edge infers a trigger polarity falling edge!")

BP101 said:

Rising edges mentioned several times infers a scope triggers polarity falling edge, 

If it had, I would have asked a different question. That is, in fact, the last thing I would have suspected.

Now that you've answered, let's see if I have this correct

1. You are measuring the position of the rising edge of pwmA (presumably low side)?
2. You are triggering on the falling edge of the same waveform
3. Finally, this measurement is being taken while the micro is running a motor control algorithm.

Does that summarize the measurement correctly? If not then what is different?

Robert

The point of 1st capture: Show mysterious 33.2us gap often occurred on either side of 200ns delayed edge.

Again the trigger is irrelevant since the declarative paragraph details the captured edge. Most datasheets never indicate trigger polarity captured wave forms. Still no engineer this forum directly identified gap as PWM zero interrupt delay time, hence answer awarded well deserved CB1. Amit was close to identifying the gaps origin "HW count remains same, if DB rise value never changes." Though the gap may occur after pwmA filters into pwmB dead band edges or between, hard to know exactly since edges transition so dang fast.

Good reason for needing a timing diagram of PWM peripheral dead band generators relative the PWMCLK. 

The zero interrupt global synchronous update caused the gap to narrow for 2 updates and arrested the problem. Gap seems to do with the minimum pulse width rising edge can under shoot PWMnDBRISE value, the LM3S errata #10 prohibited such.

BP101 said:

answer awarded well deserved.

Nope

Robert

BP101 said:

The point of 1st capture: Show mysterious 33.2us gap often occurred on either side of 200ns delayed edge.

No gap is evident since there is no apparent reference point, thus the question about the trigger.

BP101 said:

Again the trigger is irrelevant since the declarative paragraph details the captured edge. 

No

BP101 said:

Most datasheets never indicate trigger polarity captured wave forms

Polarity is part of the question but we also need to know what signal is being used for the trigger.

And there's a good reason data sheets don't need to provide trigger information. They have the relevant timing reference points embedded in the diagram. The times are either referenced to another visible waveform or some other visible part of the visible waveform. This is not the case in your screenshots. You need a reference point before you can draw any conclusions from your screenshots.

Since you have yet to fully address the issue, I shall ask again

Let's see if I have this correct

1. You are measuring the position of the rising edge of pwmA (presumably low side)
2. You are triggering on the falling edge of the same waveform
3. Finally, this measurement is being taken while the micro is running a motor control algorithm.

Is this summary correct? If not please indicate where it is wrong.

Robert

>No gap is evident since there is no apparent reference point, thus the question about the trigger.

Disagree: Elaborated 200ns vertical lines establish a time frame - right side vertical establish gap in all other following edge times CH1.

1. Quite obviously pwmA is high side CH1 (review the dead band PWM output control algorithms posted). How else can pwmA be shown contrary PWMnDBRISE value. IE: pwmA may shoot below not always cause a catastrophic failure in the PWM peripheral. Fact is 1 update removes any edge gaps yet AC line voltage sags may still have same issue, the question up or down in counts updates to keep undershoot. As reported the basic SW was written around LM3S8971 with errata #10 (no dead band enables) and may have timing issues TM4C1294 if the minimum pulse is allowed to shoot to far below dead bands. Since there is no such listed errata TM4C1294 we have to assume past #10 LM3S was corrected at the silicon level.

So it may be that a certain time in PWMCLKS is required after a dead band delay edge occurs till safe to output a PWM pulse pwmA or pwmB under certain conditions. As you can see in posted code pin state change outputs occur a few instructions later and only during local synchronous updates of the PWM control block outputs (not PWM gens) which are global synchronous updates constrained by number of zero counts in the pulse width update (not shown). Newer PWM control block architectures may have timing issues with how often dead bands occur during an undershoot condition if or when global synchronous updates are delayed further up in the PWM architecture. Hence undershoot can become significant during a rapid brown out as pwmA/B pulse width may narrow up to the minimum and shoot below dead band.  Other wise the DC current is to close to the fuse rating yet never so much in the past SW that set a persistent static delay low as (120ns) only on pwmB.

2. Rising edge trigger (real time) captures of each edge position relative right grey vertical in 50ns/cm grid.

3. Obviously the PWM is running and zero interrupts are occurring, in this case are used to control duty cycle in a typical inverter scheme. 

BP101 said:

1. Quite obviously pwmA is high side CH1 

Not obvious actually, up until this point I had assumed it was low side.

BP101 said:

2. Rising edge trigger

OK, this contradicts your previous assertion that you were triggering on the falling edge. Please confirm either way.

BP101 said:

3. Obviously the PWM is running

OK.

Please confirm which edge you are triggering on

And also

4. What kind of PWM are you generating. Is it centre aligned?

Robert

I believe it not as important how the edges are measured, rather a GAP being identified and when or how often GAP occurs in synchronous updates pwmA. The SW is updating the duty cycle every 1ms plus requested accumulated updates assuming pwmA/B never drops below DBRISE (LM3S errata #10 prohibited occurring).

New info: The generator synchronous update only occur if phase current constraint sets a zero flag every 1ms regardless of the requested updates to maintain in each period were made 1,2 or even 100.

That is an important detail (1ms updates) that could lead to pwmA under shooting DBRISE value under certain conditions, perhaps DC power glitches lasting 1 second or more. Both captures are center aligned PWM and pwmB 600ns (yellow capture) near dead center pwmA (CH1) scope set single trigger (rise) versus ALT alternate.

Below SW constraint tests the requested updates, seems to me logical OR more fitting than logical AND. So either the 1ms duty update sets the zero flag signaling an update request OR the number of accumulated zero interrupt counts (mush faster 80us periods) determine how often to preform a generator synchronous update. That OR might arrest pwmA edge ever falling below DBRSIE 200ns delay (not captured). 

What say engineers make && an || to update on the accumulated PWM zero interrupt counts or leave it set 1ms plus the accumulated zero interrupt counts? Again how many PWMCLKS must pwmA remain above PWMnDBRISE may be relative to a value of accumulated PWM periods required to arrest undershoots of pwmA. What happens when pwmA undershoots DBRISE ? does the dead band generator output remain high both pwmA/B if set high before an undershoot?  

    //
    // See if it is time for a new PWM duty cycle, based on the correct number
    // of PWM periods passing and the availability of new duty cycle values.
    //
    if((g_ulPWMPeriodCount > g_sParameters.ucUpdateRate) &&
       (HWREGBITW(&g_ulPWMFlags, PWM_FLAG_NEW_DUTY_CYCLE) == 1)) //&& change ||
    {        
        // Update the duty cycle.       
        PWMUpdateDutyCycle();
        
        // Clear the 1ms duty cycle update flag.       
        HWREGBITW(&g_ulPWMFlags, PWM_FLAG_NEW_DUTY_CYCLE) = 0;
    }

BP101 said:

I believe it not as important how the edges are measured

Not important how a measurement is taken!?? This may be silliest thing you've said yet.

BP101 said:

rather a GAP being identified and when or how often GAP occurs in synchronous updates pwmA. The SW is updating the duty cycle every 1ms plus requested accumulated updates assuming pwmA/B never drops below DBRISE (LM3S errata #10 prohibited occurring).

We've yet to identify that a gap actually exists. You won't share the information needed to determine what your screenshots mean.

So yet again lets see if we can determine what you are measuring, a repeat of the questions you have yet to answer.

BP101

2. Rising edge trigger

OK, this contradicts your previous assertion that you were triggering on the falling edge. Please confirm either way.

Please confirm which edge you are triggering on

And also

4. What kind of PWM are you generating. Is it centre aligned?

Robert

Robert answered your question several times, 1st capture posted (CH1) was falling edge, second post (CH2) likely rising edge. Again it is your opinion as to trigger polarity when It really don't even matter. The words steady state was mentioned several times implies the edges (pwmA) after dead band delay control should not be creating a moving (GAP). Hard to show that real time event happening with only screen capture when video would right away have removed questions from your thought process. 

After patching the update period count tracking routine SW (not posted) then noticed PI controller speed loop Integral setting after some time arrests random speed hunting in the 1's digit position of digital RPM. Monitored RPM should lock to the target setting at some point after rotor steady state, not forever remain hunting as it was 1-5 RPM around the target. Reason for pinging sounds was occurring from constant speed correction in pwmA edge moving so much after each dead band cycle. That gap occurred after 200ns dead band trailing edge and was moving in either direction relative to speed changes (1st capture) PI closed speed loop and should not remain hunting after the rotor load (63lbs+belt driven load) reaches steady state. 

Even after the gap stops moving disappears in a heavily loaded steady state, random inverter Panic can often inflicts MCU. Random MnFaults being tripped yet current was well below 12-14 amps peak at 130vdc @160v unregulated (sags). It seems to me hearing a pop sound during fault ain't good and signifies a random edge event of dead band timing may be to blame. 

Answer 11.11.2016: Synchronous updates of multiple generators must be made single directive, regardless if local dead band update mode is configured. Panic issue was covered in another post, for details search VDDA+ or VREF+.

BP101 said:

Robert answered your question several times, 1st capture posted (CH1) was falling edge, second post (CH2) likely rising edge.

Contradictorily and this is the first time you've mentioned using different triggers. but I was only ever addressing your first image (your assertions with the second set of captures appear to have more issues at first glance, let's clear up whether your initial question has any basis first)

BP101 said:

The words steady state was mentioned several times implies the edges (pwmA) after dead band delay control should not be creating a moving (GAP).

There is no steady state in a running motor control.

BP101 said:

Hard to show that real time event happening with only screen capture

Nonsense, that's what oscilloscopes are routinely used for.

Now let's take a look at what you can actually say from your first set of captures. I will assume you are correct in your 'most likely falling edge' assertion. I will also assume edge aligned PWM for simplicity since you appear not to be able to answer whether it is or not.

Here is what the waveforms for high and low side will look like in a running motor control

t1 to t3 is the PWM period which will remain constant

t1 to t2 is the duty cycle D which will vary as the control runs.

You trigger on t6,68,t10 And show in the capture a portion of of the high side showing the rising edges t7 and t9.

You are claiming that there is an evident gap shown by those captures.

So what determines where the edge t7 and t9 are? It will be the low period t6 to t7 for t7 or the low period t8 to t9 for t9.

What determines the low period? The duty cycle D (t2-t1 for t7 or t4-t3 for t9) and the deadband (such as t1-t6).

If we assume that the deadband is constant (as we would expect) do we expect the edge position to vary? Yes we do since the duty cycle will vary. There is no way to determine there is a variation in the deadband from these capture and indeed no reason to suspect that there is.

Robert

Invalid measurements lead to incorrect conclusions.

>If we assume that the deadband is constant (as we would expect) do we expect the edge position to vary? Yes we do since the duty cycle will vary. There is no way to determine there is a variation in the deadband from these capture and indeed no reason to suspect that there is.

You have made several assumptions in your assessment of capture edges and even that motors don't have a steady state which is a false conclusion. Your posted low signal does not indicate slow decay where the duty cycle would be much higher than shown. Most all TI data sheets signal diagrams indicate fast FET avalanche current decay is in play.

When the target speed and duty cycle matches the actual measured rotor velocity the duty cycle reaches steady state. That is to say the integral in the PI no longer has to adjust duty to maintain the target speed since it then matches. Dead band cycles are not constant, review of posted code makes that very clear. TI seminar teaches the very same scenario to interleave DB cycles into PWM, not keep constant thus driving down efficiency. There is no variation in the dead band and the two edges on either side of the rising edge indicate duty cycle changes driven by the PI controller integral hunting for a lock to a target match. Obviously I didn't know that was the case in posting 1st capture and assumed the 33ns gap was only update related, later discovered has more complexity at times.

BP101 said:

>If we assume that the deadband is constant (as we would expect) do we expect the edge position to vary? Yes we do since the duty cycle will vary. There is no way to determine there is a variation in the deadband from these capture and indeed no reason to suspect that there is.

You have made several assumptions in your assessment of capture edges and even that motors don't have a steady state which is a false conclusion.

You are running a motor, they will vary. A DC motor in open loop, fed by a fixed setpoint that might have a fixed duty cycle. An AC motor (such as a BLDC) will not have a fixed duty cycle.

Robert

Nope, that drawing is pretty much the definition of deadband. Sure the two deadbands don't have to be the same but they usually are and it wouldn't change the discussion even if they weren't.

At this point all you've shown is that the edge of a varying PWM changes. Quelle Surprise

Now there is a way of measuring the actual deadband. It doesn't require a video capture and it even lends itself to showing you any jitter visually and quite indisputably. It's not even difficult.

Robert

>You are running a motor, they will vary. A DC motor in open loop, fed by a fixed setpoint that might have a fixed duty cycle. An AC motor (such as a BLDC) will not have a fixed duty cycle.

No - BLDC motor in this case runs from simulated AC current created via trapezoidal wave form. The PI speed loop is closed and the integral frequency of duty cycle attempts to lock at the target rotor speed. Rotor speed often locks for several minutes if the DC supply does not vary much after the PWM frequency lock of the integral. In that case the rising edge pwmA remains steady and the 200ns delay randomly added to the end of the pwmA pulse width which directly subtracts 200ns from the minimum at the same time.

>Nope, those drawings are pretty much the definition of dead band.

The data sheet suggests a center aligned signal can be created by the PWM generator, it don't say by what means or in all cases. In slow decay (pwmB kept near 100% duty or less), each generator then produces left or right aligned signals depending on trigger polarity (NOT center aligned). Actual center alignment occurs across 2 generators (pwmA to pwmB) of co-phase partners. Once a generators CMPB has been set less than 50% of CMPA count, CMPB then refuses SW directives to reduce the pulse width in global synchronous updates. Once PWM module enters slow decay it remains in slow decay (indefinitely) no matter the changes sent to the PWM module during synchronous updates. Seems to be an inerrant limitation of the PWM module or something is wrong in the time base.  

Have discovered each generators counts are not incrementing exact same values even after a time base synchronize. Or the PWM module is reset prior to setting the enable clocking bit in PWMnCTRL registers. Either way the comparators lock to the correct value but all 3 GENS are not producing synchronized counts (CCS debug) as expected.

BP101 said:

>You are running a motor, they will vary. A DC motor in open loop, fed by a fixed setpoint that might have a fixed duty cycle. An AC motor (such as a BLDC) will not have a fixed duty cycle.

No - BLDC motor in this case runs from simulated AC current created via trapezoidal wave form. The PI speed loop is closed and the integral frequency of duty cycle attempts to lock at the target rotor speed

Yes, you have a closed loop system with feedback. Noise, roundoff, a non-dc output requirement all mean the pulse width will vary. So yes, it will vary.

BP101 said:

>Nope, those drawings are pretty much the definition of dead band.

The data sheet suggests a center aligned signal can be created by the PWM generator, it don't say by what means or in all cases.

Centre or edge aligned, the definition of the deadband is identical. The drawing I made would not change although the reference point would. Though the fact you don't know if you have a centre aligned PWM is rather worrying.

Robert

>Yes, you have a closed loop system with feedback. Noise, roundoff, a non-dc output requirement all mean the pulse width will vary. So yes, it will vary.

Agree that parasitic noise entering the closed loop can break the closed frequency loop and the edges start moving again. The 33ns moving GAP edge acts like human sticking toe into cold water before jumping into the pool. It moves back and forth from the grey right side vertical then locks on either side of the previous dead band pulse rising edge and becomes the new pulse width position only if speed varies.

>The drawing I made would not change although the reference point would. Though the fact you don't know if you have a center aligned PWM is rather worrying.

The data sheet only makes a claim in light of the generator discussion a pair of center alligned signals can be created. Leads one to think they mean a single generator can produce a pair of center aligned signals in any PWM mode. In Synchronous generator mode pwmB pulse center aligns with pwmA of any other generator but never its' own pwmA. That is what is occurring regardless.

To again clarify your posted signals are not qualified in (PWM_GEN_MODE_SYNC) and reflect a capture of a single generator producing center aligned signal pair by (PWM_GEN_MODE_NO_SYNC). The latter also effects dead band timing and MODE_SYNC dead band delay can be captured across two generators never one alone. Amazes me how vendor assumed everyone would grasp that detail as it simply is not ever disclosed in datasheet text. Piccolo F28x may have corrected some timing issues in the enhanced PWM module. Yet Piccolo 3 phase PWM signal diagram seemingly does not qualify for TM4C1294NCPDT PWM module behavior in MODE_SYNC.

Perhaps a few in this forum should pay attention to posted captures. Try to be open minded that different modes may stray from the data sheet peripheral details provided and making assumptions of undocumented details can lead to wrong conclusions.

BP101 said:

Might be due to pwmB duty cycle being so high compared to pwmA

Using your own words, "Nonsense & Busted" - you seem to CONTINUE TO MISS THE FACT that "Enabling Deadband" causes PWM_B to be an, "Inverted SLAVE to PWM_A" which differs from a (perfect) inversion by the presence of the deadband.

Your writings imply that you believe that PWM_B may be independently set/adjusted - and that is patently untrue when deadband is enabled.   Again - during those conditions - PWM_B is Slaved to PWM_A.   Is this your understanding or do you hold this (well known) fact in dispute?

You speak (repeatedly) of "Syncing Deadband among & between DIFFERENT PWM Generators!"   And yet NEVER have you described, "Why you believe that to be necessary!"   Deadband must prevent "shoot-thru" - ONLY & ALWAYS - upon a SINGLE PHASE FET PAIR!    (in your (and my) BLDC World.)   There is NO NEED for deadband to be imposed upon any other Phase at the same time (as only ONE Phase at a time is the recipient of "Complementary PWM Drive Signals" which benefit from such, "deadband").   Thus, "WHY is ANY "Multi, PWM-Generator" DEADBAND SYNC (w/in BLDC Motor applications) A REQUIREMENT?"   

You've never/ever made the attempt to justify such requirement - is not that (why Deadband SYNC is needed - across different PWM Generators) FUNDAMENTAL?    And - for SO long - passed completely over w/in your multiple forum protests/complainings...

Via PM I've sent you a "PRO" Commutation Table Timing Chart which clearly reveals Complementary PWM Signals (which benefit from and/or require deadband) to be ACTIVE UPON "ONE AND ONLY ONE" MOTOR PHASE AT A TIME!   Thus there are NO SYNC DEADBAND REQUIREMENTS for BLDC APPLICATIONS!

Many here would love to learn why you believe:  (and via this writing - PAST believed!)

• PWM_B is "Other than a Slave to PWM_A - when Deadband is enabled.
• And why you believe Deadband must be "Synced" across multiple (different) PWM Generators.   (especially as only ONE PHASE at a time is deadbanded!)

Again you have made it abundantly and very clear you still have a lot to learn, that is the fun of it after all. Choosing to banter over posters presentation rather than focus on substance is an ATTACK on poster and does not help the poster find an answer.