• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 1297 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Why is PWM1 not decoupling from dead band generator and reverting pwmB inversion.

Genatco
Guru 55913 points
Other Parts Discussed in Thread: LM3S8971, DRV8301

TM4C1294NCPDTi3:

Configuring dead band inversion pwmB drive and not rolling that same protection at some point to pwmA creates an inefficient 1/2 bridge scheme.

That is to say one side of 1/2 bridge, typically the low side has a much longer On time due to pwmB inversion period being longer during dead band than non-inversion pwmA On times. The dead band FALL(FED) inverted pwmB On time is not of the same pulse width as pwmA RISE (RED) non-invert state. That assumes all FETS are N channel and require active High to turn them on.

Calls to PWMDeadBandDisable() should decouple CMPB yet don't decouple dead band generators pwmB from PWM0 or make pwmB inverted from pwmA state as expected. The same case exists in Stellarisware using the exact same syntax as Tivaware, assumed decoupling dead band was successful when all that occurs is pwmB signal inversion when enabled.

If we program PWMnDBRISE/FALL registers 0x0 and then clear PWMnDBCTRL Enable bit, the pwmB output reverts back to non-inverted state and PWM0/1 pass through dead band untouched. Otherwise PWMnDBRISE/FALL original configure values set in PWMDeadBandEnable() remains in effect and assert even when DBCTRL enable is clear.

So it seem we can not decouple PWM0/1 from dead band simply by clearing PWMnDBCTRL enable bit as PWMDeadBandDisable() asserts to clear enable.

Why?

If PWMDeadBandDisable() could clear pwmB inverted state it might some how be possible to invert both pwmA and pwmB in equal dead band wrappers every other cycle of RED/FED. That way the same active pulse width length can exist pwmA or pwmB at opposite time intervals.

From our view point this must be clarified by TI engineers in order the model in datasheet has any meaning to this find. Perhaps some undocumented Anomaly exist?

  

  • 0
    TI__Guru**** 196776 points
    Hello BP101,

    The pwmA and pwmB signals produced by each PWM generator are passed to the dead-band generator. If the dead-band generator is disabled, the PWM signals simply pass through to the pwmA' and pwmB' signals unmodified. If the dead-band generator is enabled, the pwmB signal is
    lost and two PWM signals are generated based on the pwmA signal.

    I will check the API.

    Regards,
    QJ
  • 0 in reply to QJ Wang
    Guru 55913 points

    Hi QJ,

    Have discovered clearing DBCTRL enable does not zero the dead band bit counters and pwmB remains in the invert state after disabling. If we clear FED/RED registers (0x0) prior to clearing DBCTRL enable bit then pwmB decouples from pwmA as expected and PWM0/1 pass through asserts. In this scenario we don't keep dead band active 100% on pwmB so it can receive pulse width changes via PWM1 in pass trough mode 50% of the time.

    Finding if we (0x0) RED/FED registers during PWMDisableDeadBand, SW controls  which side of 1/2 bridge has RED/FED thus allowing pulse width changes to propagate more evenly in desire to generate 50/50 RED/FED output inversion states.

    Seemingly if not clearing RED/FED registers (0x0) PWMDisableDeadBand then the pwmB is inverted 100% of the time. After SW change below pwmB gained only 1  missing pulse width updates during the edge transition pwmA RED.

  • 0 in reply to Genatco
    Guru 55913 points

    This patch produces a single 1.6us off time pwmB (mid 3.8ms cycle) LM3S8179. Yet pwmA has roughly twelve 46 off times to the single 1.6us off time pwmB in a 3.8ms cycle with 80us periods. All other off times pwmB are dead band pulses of 120ns. That's why it seems as if the dead band counter pwmB is not resetting to all pwmA rising edges facilitating the need for pass though cycles.

    My desire was to insert dead bands into the FET turn  off times (only) and enable pass through PWM1 all other On times. That seems futile and produces a single 1.6us pwmB off time each cycle with 120ns pulses on either side 3.8ms span. On the other hand pwmA has a 1.6us off time every 80us in the very same 3.8ms span. That causes one side of the bridge to work harder than the other side 75/25 versus 50/50 well balanced PWM bridge.

        /* Find the non-selected (OFF state) PWM drive pins */
     ulPWMSwitchOutBits ^= ulPWMOutBits;

    /* Activate synchronous dead band cycle for pwmB Odd pin drive
     * disables and protecting 1/2 bridge from shoot through */
    switch(ulPWMSwitchOutBits & (PWM_OUT_1_BIT | PWM_OUT_3_BIT | PWM_OUT_5_BIT))
    {
    	case PWM_OUT_1_BIT:
        HWREG(PWM0_BASE + PWM_GEN_0 + PWM_O_X_DBFALL) = usDeadTimePwmB;
        HWREG(PWM0_BASE + PWM_GEN_0 + PWM_O_X_DBCTL) = PWM_X_DBCTL_ENABLE;
        break;
    	case PWM_OUT_3_BIT:
        HWREG(PWM0_BASE + PWM_GEN_1 + PWM_O_X_DBFALL) = usDeadTimePwmB;
        HWREG(PWM0_BASE + PWM_GEN_1 + PWM_O_X_DBCTL) = PWM_X_DBCTL_ENABLE;
        break;
    	case PWM_OUT_5_BIT:
        HWREG(PWM0_BASE + PWM_GEN_2 + PWM_O_X_DBFALL) = usDeadTimePwmB;
        HWREG(PWM0_BASE + PWM_GEN_2 + PWM_O_X_DBCTL) = PWM_X_DBCTL_ENABLE;
    }

    /* Activate synchronous dead band cycle for pwmA Even pin drive
     * disables and protecting 1/2 bridge from shoot through */
    switch(ulPWMSwitchOutBits & (PWM_OUT_0_BIT | PWM_OUT_2_BIT | PWM_OUT_4_BIT))
    {
    	case PWM_OUT_0_BIT:
        HWREG(PWM0_BASE + PWM_GEN_0 + PWM_O_X_DBRISE) = usDeadTimePwmA;
        HWREG(PWM0_BASE + PWM_GEN_0 + PWM_O_X_DBCTL) = PWM_X_DBCTL_ENABLE;
        break;
    	case PWM_OUT_2_BIT:
        HWREG(PWM0_BASE + PWM_GEN_1 + PWM_O_X_DBRISE) = usDeadTimePwmA;
        HWREG(PWM0_BASE + PWM_GEN_1 + PWM_O_X_DBCTL) = PWM_X_DBCTL_ENABLE;
        break;
    	case PWM_OUT_4_BIT:
        HWREG(PWM0_BASE + PWM_GEN_2 + PWM_O_X_DBRISE) = usDeadTimePwmA;
        HWREG(PWM0_BASE + PWM_GEN_2 + PWM_O_X_DBCTL) = PWM_X_DBCTL_ENABLE;
    }

  • 0 in reply to Genatco
    Guru 55913 points

    Some in forum might have noticed the dead band timers were being selective enabled via PWNnDBCTRL above posts or that is we thought was occurring. The point is we don't require dead bands during FET turn On events, but only during turn Off events.

    Clearly a few Stellaris group folks knew years ago LM3S8971 dead band was being enabled when it was actually being disabled via SW function call PWMDisableDeadBand() and never corrected the library or datasheets. The PWMEnableDeadband() set the PWMnDBRISE/FALL registers values then (unknowingly) disabled the enable bit reverting back to pass through mode 0.

    The data sheet register 52,53,54,55 enables work backwards; 1 is clear (pass through) and 0 is enable dead band. That still does not preclude the fact pwmA 10 bit dead band counter OFF times are not being evenly distributed inverts pwmA to make pwmB and drops the many OFF periods present in pwmA.

    That logically relates to poor efficiency and unbalanced commutation in any bridge design, leaving dead bands fully engaged during commutation. After all it is the FET turn OFF event that is prone to cause shoot through, not the turn ON events. That is why earlier engineers named them dead bands as they (guard band) the FET turn OFF events.

    9/7/16: Discovered PWM CMPB was being unintentionally jammed setting the initial static duty cycle near 100% as dynamic pwmA pulse width varied the duty cycle. That jam caused future synchronous updates of CMPB to fail when it was later made to have dynamic value changes.

  • 0 in reply to Genatco
    Guru 55913 points

    The good news is the TM4C1294 pwmB dead band RED pulse width is not truncated when PWMnDBENABLE bit is set inverse as described above. LM3S8971 software migration to TM4C1294 produced the same issue. Truncated pwmB RED pulses occur when the DBENABLE bit is disabled during the dead band enabling call PWMEnableDeadBand() in opposition to the intent of enabling dead band.  

    Patch below seems to clear dead band, decouple PWM0/1 from pwmA/B dead band generators both LM3S8971 and TM4C1294. The inverse with disable after setting PWMnDBFALL/RISE registers seems to latch the banding mode 6 thus inserting RED/FED delays into the pulse width pwmA as intended pwmB not so much. The original Tiva enable dead band mode did not produce any change to RED/FED delays as expected. Oddly RED/RED register values seem to be a smaller multiple of PWM clocks than calculated. Clearing RED/FED dead band registers 0x0 before setting new and latched values did not seem to help. 

    6-21-2016: The RED/FED delays are appearing on opposite co-phase 1/2 bridge partners in cycles. Mentioned above saw no change (FED/RED) same 1/2 bridge simply remained static roughly 200ns when the delay registers explicitly set to a new values and re-tested. The diagrams do not show a cycle scheme (RED/FED) co phase pairs as being the real time event (High to Low co-phase). The RED/FED delays are drawn statically each generator with out any mention of 1/2 bridge crossing behavior being indicated in the table. That explains dead band is not being fully elaborated in the data sheet text and scope captures in real time events are in opposition to the simple Figure 3-10. 

    PWMClearDeadBand(void)
{
	unsigned short usDeadTimePwmA = 0;
	unsigned short usDeadTimePwmB = 0;

    // Clear the dead band PWMnDBRIS/FALL registers.
    HWREG(PWM0_BASE + PWM_GEN_1 + PWM_O_X_DBRISE) = usDeadTimePwmA;
    HWREG(PWM0_BASE + PWM_GEN_1 + PWM_O_X_DBFALL) = usDeadTimePwmB;
    HWREG(PWM0_BASE + PWM_GEN_1 + PWM_O_X_DBCTL) = PWM_X_DBCTL_ENABLE;
    HWREG(PWM0_BASE + PWM_GEN_2 + PWM_O_X_DBRISE) = usDeadTimePwmA;
    HWREG(PWM0_BASE + PWM_GEN_2 + PWM_O_X_DBFALL) = usDeadTimePwmB;
    HWREG(PWM0_BASE + PWM_GEN_2 + PWM_O_X_DBCTL) = PWM_X_DBCTL_ENABLE;
    HWREG(PWM0_BASE + PWM_GEN_3 + PWM_O_X_DBRISE) = usDeadTimePwmA;
    HWREG(PWM0_BASE + PWM_GEN_3 + PWM_O_X_DBFALL) = usDeadTimePwmB;
    HWREG(PWM0_BASE + PWM_GEN_3 + PWM_O_X_DBCTL) = PWM_X_DBCTL_ENABLE;
} 
  • 0 in reply to Genatco
    Guru 55913 points

    Several posts ago was challenged for seeing oddness in dead band as it has been depicted in table 3-10 as a static event. Several threads back thusly attached a project showing the effect of 2 PWM generators dead band behavior in the TM4C1294. Behavior noted above post very much described the RED/FED delays actually appear across 2 co-phase pair 1/2 bridges and not specifically a scope trigger event of any single 1/2 bridge working alone.

    Does equal pulse widths pwmA/B make for a better PWM efficiency?

    The BLDC motor runs PWMDisableDeadBand() called end of each duty cycle update yet is difficult to start and sounds like a rock tumbler and lower RPM is achieved. That includes PWMDeadBandEnable() call made prior to any pin state changes.  Pulse width changes pwmB occur in the inverted state but the duty cycle update routines are far from keeping any peace.

    Would be interesting to see how the F280 Piccolo + DRV8301 BLDC motor driver Booster pack deal with this issue of dead band and low side PWM modulation. A spanking new 30Mhz Tenma 2 channel storage scope could not capture the same real time dead band delay as our 1987 Tektronix 2430. It touted a 50Mhz BW,150Mhz effective band width @250KSPS via a 8bit ADC and 32 bit serial shift register CCD that has a heat sink larger than Titanic, easily melts icebergs known to sink ships. Well it has been an asset until channel 1 CCD U350 -- dearly departed we gather here today........