This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TM4C1294NCPDT: Diagrams of PWM0 dead band generator structure seem at odds....

Guru 54027 points
Part Number: TM4C1294NCPDT
Other Parts Discussed in Thread: INA240, LM3S8971, DRV8305, INA282

Can TI please provide a better illustration of the dead band generators and delay counters structural gating and timing logic so embedded software can be made to properly control them?

Dead band generator PWMA input won't trigger on a rising edge per data sheet 23.3.5 figure 23-6 as no delay even occurs in the output of PWMENABLE bits if the PWMnDBCTRL is enabled after setting those bits high. The setup of the PMWA delay should be done when the binary code change is presented to the output pins of MCU but that is not physically possible, so the dead band cart comes before the PWM horse If you will. 

Dead band delay of signal output PWM0-A  actually seem to occur on the next falling edge of PWMA when specific PWMENABLE outputs are thus local synchronous updated by PWM0 generators.

More specifically if PWMnDBCTRL is used to control signal delay of PWMA in cyclic calls which enable the DBCTRL bit after the rising edge of PWMA bits are set high in PWMENABLE has no effect to delay the signal.

Only after these output bits are first switched low does PWMA signal then have a pulse width increased by the delay period set in PWMnDBRISE/FALL registers. That behavior seems to indicate the dead band delay counters only trigger when the PWMA edge changes from high to low (falling edge) and not low to high (rising edge) as stated 23.3.5. Figure 23.2 shows PWM0 generators dead band structures exist before the PWMENABLE register which connects signals to MCU pins and there is no delay counter reaction to a pin state change on the rising edge of a binary code change in PWMENABLE register to set up a delay for the falling edge event of PWMA via embedded SW.

We must insert the delay (extend the pulse width) on the high to low transition of FET gates to ensure all FET are actually off for the next turn on in order to avoid inverter shoot through of a single generator.

So it also seems the structure is of incorrect design in order to achieve better control of the output pin state delay and the embedded SW engineer is forced to control both PWMA/B delays together when they should be separate enable bits.

  • How have you configured the DBCTLUPD field of PWMnCTL register?
  • Hi Bob,

    DBCTRLUPD is configured for gen mode sync local to coincide with PWMnENABLE output updates. Generator sync immediate with dead band cause electrical issues of random POR of launch pad.

    In fast decay mode truncated pulses are produced near ground depending on how low the minimum pulse width is set but never a full pulse width results. The bad thing is very small remnant +/- PWM spikes ride that same area in slow decay where PWMB is set static near 85% duty cycle yet well above dead band (140ns) in order to avoid overheating low side MOSFET junctions. Will later post capture of these remnant pulses.
  • Captures of PWM:

    Notice the fast decay mode 1us pulse (green box) is well above 120ns Dead Band delay setting. The pulse low side (yell box) fast decay mode is actually pwmB dead band generator even at a 2us minimum pulse width (MPW). Still no PWM0 pwmB (pass through) pulse is getting into the PWMENABLE register.

    The single pulses (red boxs) are actually dead band pulses as shown in the zoomed (yellow box) when the duty cycle is well below 85% or fast decay mode.  The first capture (red box) random pulses occur 1us MPW, the last capture with a 2us MPW yet the pulse CH2 is roughly 800ns or less.  So when the high side pwmA dead bands the low side goes with it in the next code change to PWMENABLE output. This is not fast decay mode with low side PWM since the pass through of PWM0 -pwmBn never seems to occur. CCS debug  PWM register shows the setting and clearing of the PWMnDBCTRL enable bit succeeds as expected.

    Captures seem to indicate pwmB inversion is not decoupling the dead band delay counter fast enough to pass through using an embedded (|=) directive on the control bit or PWMnDBCTRL enable bit simply latches up when being cleared in both decay modes.

    Previous issue captures: https://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/p/582954/2142605#2142605

  • It is noted that your post begins w/"Green Box" & then "Yellow Box" - yet their scope traces appear at the (very) bottom of the scope captures.   (FURTHEST from their description - forcing extra scrolling - and possible loss of meaning - upon your helpers.)

    Note also that CH1 appears @ 2V/div setting - which suggests this as an MCU's PWM output.    (likely being fed to a gate-driver IC)    

    That said - w/out explanation - then CH2 appears at 5V/div (top caps) and later 10V/div (bottom caps) - suggesting that this is the output (NOT from the MCU) but from the gate-driver.    If this proves true (which I believe it will) then any/all delays - introduced by the gate-driver - and its effort to enhance the attached Power FET's gate - create a "Less than" Apples to Apples comparison of the effect which "Dead-Band" imposes upon a PWM Generator's two "MCU ONLY" outputs.    (in addition - it (may) be true that (other) gremlins may be introduced upon CH2's pickup & display - resulting from its connection & proximity to the Power FET.

  • cb1_mobile said:
    then CH2 appears at 5V/div (top caps) and later 10V/div (bottom caps) - suggesting that this is the output (NOT from the MCU) but from the gate-driver.

    Yellow pulses are obviously the inverter trapezoidal signal output and volts scale zoomed into show low level pulses near ground. How else could eye glass weary folks see details so low level.

    cb1_mobile said:
    (in addition - it (may) be true that (other) gremlins may be introduced upon CH2's pickup & display - resulting from its connection & proximity to the Power FET.

    Scope probe located 1.5" from any FET's.  The trash being thrown on ground from red devil pulses at bottom capture also results in INA240 output signal distortion.

    cb1_mobile said:
    "Less than" Apples to Apples comparison of the effect which "Dead-Band" imposes upon a PWM Generator's two "MCU ONLY" outputs.

    Have to say don't think so as the pwmB pulse width is far smaller than 2us MPW setting output pwmA and inverter but not posted. The 1us pulse capture was to show the MPW setting is not causing runt pulses especially ones that cause massive dv/dt thrown to ground. So high side FET recirculation current (slow decay) is extinguished mostly by the phase coils and fast decay by design pukes all over ground. That seems unlikely and a DB timing issue is causing massive switch node spikes (dv/dt) in fast decay mode.

    BTW have made an interesting Tina circuit tester for that low sided 240 beasty and think issue with both 282/240 differential input bias is possibly missing or wrong pin identified in datasheet etc...

    https://e2e.ti.com/support/amplifiers/current-shunt-monitors/f/931/p/583896/2144513#2144513  

  • If you are critiquing vendor's MCU "Dead-Band" implementation - your extension of key/critical signal measures - EXTERNAL to the MCU - will PREVENT (any) vendor agent (or interested outsider) from being able to "re-produce" your issue.   And clearly precludes, complicates & renders questionable your critical "scope-cap" presentation.     Is that likely to best serve your interest?...

    Is it not each poster's obligation to present their, "Request for Assistance" in the clearest, most direct & efficient method?    Yet - your opening (detailed) scope-trace description - appearing at the very top of your posting - could not have been (more) separated from the related scope captures!   (which appear (shockingly) at the absolute bottom of your post.)     Does that reveal great organization, thoughtfulness, or caring?

    Everyone here is rushed/pressured - yet we (each) owe it to these dedicated, vendor forum experts (and too - to ourselves) to present our "data, findings & issues" as clearly & invitingly as possible...

    You have struggled w/this issue for beyond a year now.    You seek, "Expert analysis & insight" to uncover key operational findings & their implications.    While you (claim) that your (undefined) scope caps are "obvious" (after earlier stating they "suggest") - they did NOT register as such to me - and (likely too) - vendor experts.     Might your use of "suggestion" - rather than clear/proper "signal labeling & detailing" - add time/effort (thus discourage) the, "Expert analysis & insight" you so require?

    "Conforming to Technical conventions" (i.e. (some) labeling of scope channel data) & "easing the efforts of others" (i.e. via close placement of narrative to clarifying scope caps - rather than maximizing their separation) may warrant consideration...

  • cb1_mobile said:
    "Conforming to Technical conventions" (i.e. (some) labeling of scope channel data) & "easing the efforts of others" (i.e. via close placement of narrative to clarifying scope caps - rather than maximizing their separation) may warrant consideration...

    The scope captures have nothing to do with request for better diagrams other than to show PWM peripheral is not behaving as designed or elaborated to in data sheet. Not only has this issue defied all imagination it stumped major industry specialists LMI and TI lab engineers. They obviously misunderstood the very same text or never bothered to inform supervisors things ain't working so good in dead band control register.

    Proper timing diagram of dead band counters might indicate a triggering/clocking limitation is possible when rapid R/W transitions PWMENABLE occur in close proximity with PWMnDBCTRL bit set/clearing.

    The point again of captures was to show Bob an elementary 1-2us rising edge output pulse width is not being produced by pmwB when it is recovering from PWMnDBCTRL enable bit being cleared in cyclic calls. Low side inverted pwmB DB pulse is so obvious again (yellow box) pulse don't belong there when PWMnDBCTRL is cleared. Yet there it is right between the eyes you just have to take my word the enable bit is being cleared by SW yet PWM0 pwmB pass through never occurs as it should.

    One WA is not to Ever enable fast decay and that still doesn't clean up the remnants left behind (second red rectangle) on ground from PWMnDBCTRL bit set/clearing and the pwmB DB counter spews glitches onto ground. 

  • Many here would like to see you succeed - that success may benefit others, too. My interest is in aiding that process.

    While expensive - FET vendors have suggested that a, "Differential scope probe" wil yield much cleaner pictures.

    Are you familiar w/the technique of, "Removing scope's 3-4" ground lead" - and making a (much) shorter/more direct ground connection (via a wire loop or Y) from pcb ground to the scope probe's ground (metallic) sleeve? (which becomes visible/usable when the ground lead is pulled.)   Often this method improves a single-ended measurement.    I can provide a diagram or photo - although illustration of the technique is (bound) to exist on the web.    

    I sense that such improved measurements will make your scope caps "more real."      My small group doubts that the, "devil pulse" you present springs from the MCU's PWM_B output.   Displaying (only) the gate-driver output (devil pulse) is suspicious - and not sufficient to "convict" the MCU of fault behavior.      (i.e. Conviction in Absentia..)

  • cb1_mobile said:
    Are you familiar w/the technique of, "Removing scope's 3-4" ground lead" -

    Yes probes  have GND spring for direct PCB contact but one has to hold probe and capture simultaneous. Yet 12.5Khz slow PWM 80us period not much is gained at higher voltage in my opinion. 

    cb1_mobile said:
    I sense that such improved measurements will make your scope caps "more real."      

    Can't get much more real 10kps depth when dv/dt shows face upon inverters B+/GND and double capacitance of snubber reduces the spike level in half.

    Perhaps the method of changing value in PWMENABLE register step 1 so close to an actual code change of the PWMENABLE register step 2 might cause said glitches DB spikes step 3. That is step 1 - 3 all being done in the same call during local GEN updates might seem to cause far to much noise in the PWMEBABLE register gate latch.

    For instance if you look closely at CH1 above (red box) pwmB gate driver signal you will notice similar glitches surfing on top the wave. Perhaps a clue PWMENABLE register local update is not so quiet in the interactions with dead band generator or PWMnDBCTRL being toggled rapidly step 1 and PWMCLK timing wise very close to the next commutation cycle of PWMENABLE register in step 3.

    I have been bitten by similar gate control edge timing dogs in the past.

  • BP101 said:
    For instance if you look closely at CH1 above (red box) pwmB gate driver signal

    Note that there exists, "No red box" w/in your (most recent, 26 Mar, 07:33) posting.   (it is usual to provide a link to diagrams/documents not included w/in the "open/current" posting.)

    That said - by going WAY above (to post 24 Mar, 08:28) I find (TWO Red boxes!) and one green & one yellow one, as well.   Have I found the correct "red box?"

    Now - if I've found the correct box (pair) - neither shows the MCU's direct output - instead the high signal level reveals - most likely - gate-driver output.  

    When trying to establish & document an MCU shortfall - should not the "facts in evidence" be confined to the suspect MCU I/O - NOT a probing from some, "downstream" IC?   Would not your case be made vastly more compelling by a scope cap (2 channels, simultaneously captured - NOT "cut/paste manipulated") with the "suspect MCU I/O pin AND your "downstream IC pin - BOTH, simultaneously, captured & presented?   That's the normal/customary manner by which MCU shortfalls are documented - your presentation of a "Downstream glitch ONLY" is NOT customary - thus proves non-compelling.

    Understand - I am attempting to impose myself between your request and vendor staff - who but for Amit (and myself) - have had far less involvement w/your "trials/tribulations."    If I have difficulty w/your claims & writings - it is reasonable to assume that "so too" will (more recently arrived) vendor staff.    (vendor's Bob & Charles - both quite talented - yet w/out your "history")

    In terms of a "real" scope cap - it remains unclear if you removed the scope's ground lead.    As CEO - surely you can request one of your staff - to, "Trigger the scope upon your command."

    I'm rather certain that if a "proper case can be made for an MCU issue" - your odds for resolution ramp up substantially.    Measurements (far) from the MCU - (probings from external, non-vendor ICs) - are unlikely to convince vendor staff that their "high-volume" device suffers as you (inconclusively) claim...

  • cb1_mobile said:

    That said - by going WAY above (to post 24 Mar, 08:28) I find (TWO Red boxes!) and one green & one yellow one, as well.   Have I found the correct "red box?"

    Now - if I've found the correct box (pair) - neither shows the MCU's direct output - instead the high signal level reveals - most likely - gate-driver output.  

    Some common sense prevail on the part of reader to recall the context remains relative to the thread, what other red boxes had this thread related there being indication of trouble.  If a gate driver output looks like CH1 then your forgetting gate charge typically have a 10v to 15v level and not 2.9v to 3.0v tops as CH1 shows. CH1 is also the trigger source for CH2, but that is obvious. Gate driver FET output signal has some interesting character well beyond CH1 but the Fairchild gate driver is not the issue of this thread. Not to say it couldn't be but if was the case why would TI make a production run of 1000's of RDK using the same driver if known to have such issues with Stellaris PWM peripherals and encourage a fast track to production, highly unlikely that case.

    cb1_mobile said:
    In terms of a "real" scope cap - it remains unclear if you removed the scope's ground lead

    Why would anyone remove the probe ground lead when that would indeed invite ghosts and other gremlins to the party.

    cb1_mobile said:
    Measurements (far) from the MCU - (probings from external, non-vendor ICs) - are unlikely to convince vendor staff that their "high-volume" device suffers as you (inconclusively) claim...

    Case made in thread the MCU produced CH1 mentioned several times was pwmB delay being suspect of trapezoidal wave form switch node spikes, far reaching tentacles from inside the MCU.

  • BP101 said:
    Why would anyone remove the probe ground lead when that would indeed invite ghosts and other gremlins to the party.

    In my post yesterday -just prior to today's in sequence - I "detailed" the removal of ground lead and its REPLACEMENT w/a wire loop and/or "Y" stake to make a FAR shorter (thus noise rejecting) ground connection.   The loop or Y stake contacts the ground ring - visible when the 3-4" scope ground lead is removed.    Yesterday your writing signaled (recognition/understanding) of this method.    Today you (unfortunately) have either "forgotten" or simply seek to resist/attack...    (neither my problem)

    As "CEO" - should not you "invite" such suggestions?    The desire to be "right" - AND to always blame the MCU - (never operator technique) - may (predictably) result in your (long & on-going)  plight.

  • cb1_mobile said:
    AND to always blame the MCU - (never operator technique) - may (predictably) result in your (long & on-going)  plight.

    Seems I disagreed above post to using said GND technique as being non-valid at +24v dc and +/-10v spikes reduced by doubling snubber capacitance cut that down to +/-5v.

    So your saying it is impossible for PWM timing issue steps 1-3 being relative to how pwmB might not release from dead bands grasp in the next binary code change? Still find it odd actually need two delay both GEN pairs to protect the 1/2 bridge thus loosing pwmB in the process. Yet PWMnDBCTRL enable bit sets both PWMnRISE/FALL delay counter JAM values, those seemingly relative to each individual GEN output pwmA/B.

    My analysis below and scope captures above seem to indicate PWM dead band timing issues are causing switch node spikes, repeating current surge cycles and fast decay (low side PWM) failure when under an 800ns pulse width is set.

    That said it is impossible to add a delay for the falling edges turning off two FET at a time on any co-phase 1/2 bridges without disrupting both sides of the un-switched FET in those same 1/2 bridges. The runt pulse of fast decay seems to originate in that issue, when the next binary code change occurs pwmB is still recovering from being cleared. So that un-switched FET pair then become delayed in that code change cycle before the pulse is even output to the inverter and that truncates the pulse width of pwmB in the process.      

  • You reject each/every one of my suggestions - even though they seek to make your issue far clearer - and more inviting - for skilled vendor staff who (alone) have superior access & insight to MCU behaviors.

    BP101 said:
    So your saying it is impossible for PWM timing issue steps 1-3...

    As "CEO" is it your habit to force skilled staff to search/scan thru 20+ writings (postings here) - to determine what's meant /included by "steps 1-3?" Time means (something) to those of us involved in "profit-seeking" enterprise.   Earlier I clearly noted your habit of, "forcing extra time/effort" (inviting distraction/error) upon forum aid staff (captive & outsiders) by failing to, "co-locate" - or at minimum to "link to" - such data.    (i.e. your referenced scope caps (post 24 Mar, 3:28) were placed AS FAR AS POSSIBLE from their narrative description!)      

    Should not "you" have made the effort to search for, find & then "paste" - steps 1-3 - w/in your new post?    More than one person will likely read your post - you force each/every one to invest (more) time/energy by (individually/serially) conducting that search - do you not?     Does this display fair/proper (care/consideration) toward your forum aids?    (even after - and especially after - you've been notified of such unwelcome tendency.   (unwanted, excess time/effort - forced upon helpers)) 

    Thus far I'm alone in identifying these "post roadblocks."   In each case - as I was taught - I've presented "alternative forum methods" which aim to, "Speed, Ease & Enhance" reader comfort, understanding and time savings.     Do you believe that to be unjust?     (i.e. Is it ONLY your time/effort which must be guarded?)    

    The serious Tech Analysis & Insight - which you (so often) seek (here) - is unlikely to arrive in the volume & force you require - "when your time/effort/ease trumps that of ALL OTHERS!"

  • cb1_mobile said:
    Should not "you" have made the effort to search for, find & then "paste" - steps 1-3 - w/in your new post?

    The 1-3 step thread link is top of scope captures and figured it was mentioned this thread somewhere steps in PWMENABLE call produce these low side glitches and runt pulses.

    Compared to other TI datasheets of PWM peripheral dead band layout, the TM4C seems to derail facts of functionality makes a claim that proves to be incorrect in actual operational mode. The falling edge seems is delaying pwmA dead band into pwmB, not the rising edge as the datasheet claims. There is no way to get a full width period from pwmB delayed that ever matches pwmA rising edge delay so the pulse widths are unequal even when CMPA/B registers are loaded with the same match counts.

    The green box is first mentioned since it proves even a minimum 1us inverter output pulse is being generated when runts/spikes occur. The actual MPW period is not from the PWM generators perspective, it is from the inverter perspective. To indicate pwmA/B actually produce a 1us off time in the inverter they must be made much wider by 100's of nanoseconds. Otherwise if we try to make pwmA/B exactly 1us periods the inverter is roughly 650-700ns of off time well under the MPW.   

    cb1_mobile said:
    The serious Tech Analysis & Insight - which you (so often) seek (here) - is unlikely to arrive in the volume & force you require - "when your time/effort/ease trumps that of ALL OTHERS

    Perhaps you are making things more complicated and try to discredit findings as being to difficult for anyone to grasp. These captures indicate not noise or bad grounds rather BAD timing is occurring in PWMENABLE output control register in receiving proper pwmB delayed pulse widths from the dead band generator. Why or what causes this has been asked and so far NOT been answered.  

    I reported failure and ask for better technical info to determine why or if embedded C code control of HW is not functioning as the datasheet describes. The TI debug tools are not revealing the answer why so it must be a timing issue perhaps even self inflicted by the nature of PWM peripheral being stretched beyond the architectures capability. I'm starting to lean with the latter but have a few more tricks up my sleeve, since this MCU is 150 DMIPS it surely can handle rapid global synchronous update counts 60MHZ PWMCLK in dead band pass through recovery unlike the earlier LM3S8971 MCU.

  • cb1_mobile said:
    Understand - I am attempting to impose myself between your request and vendor staff - who but for Amit (and myself) - have had far less involvement w/your "trials/tribulations."    If I have difficulty w/your claims & writings - it is reasonable to assume that "so too" will (more recently arrived) vendor staff.    (vendor's Bob & Charles - both quite talented - yet w/out your "history")

    Umm nobody especially asked for you to do any such thing and you are far off topic in the thread posted as if almost a personal attack in some way in trying to use post against a request for better clarification.

    cb1_mobile said:
    are unlikely to convince vendor staff that their "high-volume" device suffers as you (inconclusively) claim...

    This shows that you do not clearly understand or have forgotten over time how the inverter produces pulses from a combination of PWM generators working together to form such pulses which can not directly be captured at the MCU outputs unless an inverter is attached. Unless you have some kind of PWM generator signal analyzer hooked up to the MCU pins this issue shown in captures would not be detectable via an oscilloscope capture. Again your point is far from that which was requested in the thread posting.

    Why not try to give real solutions for this issue - otherwise please stay neutral and the CEO judgment name calling is unjustified.

  • We note "CEO" sits atop your forum profile.

    Does suggesting methods to make your forum requests more understandable - and less time/effort consuming for (all) your helpers - qualify as, "Off topic?"  Offering alternative means to, "Present your case" does NOT "come near" to a personal attack.    

    It is far easier to sit back - do little (nothing) - yet I made (repeated) efforts to present alternative view-points - each clearly intended to strengthen your postings.    That you (try) to label these suggestions as, "personal attacks" - instead of (somewhat) accepting (and then testing for their possible validity) - speaks to a (very) closed mind.    Should you not display (some) interest in improving your postings?

    You may note the (single) response from vendor - which appears to confirm my assessment of the need for more, "Care, organization, reader ease & clarity" w/in your postings.

    I continue to wish you success and cede this battle-ground to others...

  • cb1_mobile said:
    We note "CEO" sits atop your forum profile.

    No it does not if you check again it says president and engineer for 6 months on end. The use was demeaning and seems an attempt to belittle me in the context it was used. You don't need to apologize to forum but to keep insisting captures are not understandable much a Robert professed in another thread and BTW he was dead wrong about scope aliasing causing HUGE PWM voids when MCU VDD was near shorted to GND. That behavior strikes me as being extremely closed minded to real world silicon failures and he was assuming all is well in Kansas when the EF4 tornado was just over head.

    I even migrated this application into the TI-RTOS kernel testing MCU load using UART logger and CCS debug RTOS-HA did not show the PWM was causing divergent interrupts from any generator. That was some kind of silicon failure at the substrate level or worse and I finally after 5 months decided to check VDD to GND resistance, that launch pad is history. Next time tell the user to test findings against another LP when PWM gets that bad. you could hear the audible difference as the motor phases stopped pinging Morris codes to U2 boats in the Pacific.   

    cb1_mobile said:
    You may note the (single) response from vendor - which appears to confirm my assessment of the need for more, "Care, organization, reader ease & clarity" w/in your postings.

     

    Quite an attempt it seems your part to characterize forum FE are naïve when he has shown quite the knowledge base in past issues. 

    So it seems you go no further in deductive reasoning being convinced posted PWM captures spikes/runt pulses indicate ground noise inflicting PWM.

    Does anyone this great forum or other TI forum FE have any valid suggestion that might arrest these spikes?

    Are such spikes and repeating cycles of current surges normal motor noise with DRV8305, seems unlikely. Are TM4C1294 dead band timings being forced beyond PWM peripheral ability to control the PWMENABLE binary code latch in all update modes. Seems likely there are timing limitations in this area of the PWM peripheral even at 80us periods with a minimal 160ns pulse width on pwmB and 120ns BD delay pwmA.  

    These are questions a proper timing diagram of dead band generators delay counters might quickly reveal or root out SW directives R/W PWMENABLE may have limitations in this area of PWM peripheral. There must exist timing information of the PWMENABLE register R/W access timings and how PWM clock relates to global dead band updates in that access relationship. Is that access timing 100Khz, 1Mhz or a single PWMCLK tick of 16.6ns when PWM clock is 60Mhz?

  • Perhaps TI lab could determine why pwmB seems to latch up and refuse to inter pass through after CMPB was set with a far lower value than CMPA. And PWMnDBCTRL bit is being rapidly enabled/cleared inside the same cyclic call used to change binary codes of PWMENABLE register and set the active pin states false each cycle. If CMPB dead band generator is re-entering pass through mode why is the duty cycle not producing equal size pulses pwmA/B in the global synchronous updates of the generators? 

    Seems I have revisited this PWM issue in one form or another several times and have yet to reveal what embedded SW routine might be causing a latch up in PWM0 CMPB or creating excessive switch node spikes shown in captures. It would seem those inverter spikes are reeking havoc on the INA240 shunt monitors PWM rejection input filters of 400Khz differential amplifiers.

    Previous issue was not concerned with spikes/runt pulses at that time:

    https://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/t/533844

    Below is faster way to turn off all active PWM pins from a previous output cycle using fewer instructions and without a stack call made to Tivaware. Do suspect the next output of PWMENABLE of the binary code change is perhaps violates an undocumented immediate B2B R/W of the PWMENABLE register.  

    /* Get the PWM control block active pins state */
     ulPWMEnable = HWREG(PWM0_BASE + PWM_O_ENABLE);
    
    //ROM_PWMOutputState(PWM0_BASE,
       //ulPWMOutBits ^ (PWM_OUT_2_BIT | PWM_OUT_3_BIT | PWM_OUT_4_BIT |
                       //PWM_OUT_5_BIT | PWM_OUT_6_BIT | PWM_OUT_7_BIT) ,
       //false);
    
    /* Improved method: Mask disables GEN0 and will
     * turn off all active pins GEN1, GEN2, GEN3 */ 
    HWREG(PWM0_BASE + PWM_O_ENABLE) &= ~(ulPWMEnable &0xFC);

    /* Enable PWM selected (enabled) pin mux outputs gating PWM */
    //ROM_PWMOutputState(PWM0_BASE, ulPWMOutBits, true);
    HWREG(PWM0_BASE + PWM_O_ENABLE) |= (ulPWMOutBits &0xFC);

  • Great news the low side larger 10v spikes at inverter output are now gone when 80vdc B+ linear supply is online. There still ringing in the high side FET turn on event showing up on pwmA/B at GND level. Perhaps 100 ohm series resistors placed inline PWM pins leading to gate driver inputs might stop back EMF from riding into MCU or visa versa. That was never a problem with the LM3S8971 GPIO pins being +5v tolerant or at least LMI never included series resistors to the gate drivers. Though 10ksps scope probe picks up all the bad signal gremlins the engineer might need to investigate and clean up.

    The INA240 output signal is +1.65v above ground with a 570mv floor into the ADC channels and analog comparator inputs. Both INA282 and INA240 outputs with REF1/2 tied to GND was violating datasheet mode analysis, at times was crossing ground.

    The AC looking aliased captures of INA282 output crossing GND was due to the PI controller speed regulator. The negative going PWM pulses in the INA ratio metric output ramps were not having much effect in the ADC sample variable to regulate a steady speed. The INA240 shunt inputs measure bipolar CMM in two directions (AC) but more effectively positive than negative current.

    Both directions are necessary for the PI controller to regulate motor speed effectively when the ADC sample array variables must count differently. The scope was detecting two directions in both INA282/240 monitors but the ADC sample was not getting half the necessary information above shunt GND required to regulate torque more effectively being the current is more AC like than DC. The motor speed is being maintained within 1 RPM rather than 8 as it was and current meanders in the scope widget when the PI controller is regulating motor speed.
  • Refresher for the group who might use an inverter connected to the PWM module TM4C1294. Notice the DUT is tested near the high side FET close to B+ and dv/dt might easily inflict a single voltage offline switching power supply. A linear 80vdc supply with faster FET switching duty cycle seemed to arrest 10v di/dt spikes near ground at the inverter but not the dv/dt riding on B+.

    For some reason B+ dv/dt might seem to get into the PWM generators and cause +/-4v spikes riding on pwmA/B near ground between off times but the timing is wrong. The +24v used to produce +5v is isolated from 80v transformer winding and a parallel toroid choke +24v feed into +5v buck down feeding the +3v3 LDO made no difference to stop them.

    The Fairchild gate driver producing PWM pulses into the MCU where they originated seems unlikely.