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.

TM4C1294KCPDT: PWM A/B outputs are not overlapping after Reset or POR

Guru 55993 points
Part Number: TM4C1294KCPDT


After Reset or POR first few cycles of PWMENABLE REG-1  gated output (250us) produce voids in gate drivers outputs. PWM generators are configured for down count synchronous mode with local generator dead band update and global synchronous updates. The voids in A/B drive output are consistent up to 250us then PWM generators appear to partially self correct. 

Overlap voids self corrects after the reset or POR event and the PWMENABLE produces output where dead band generators are being toggled. Attempting to turn on/off dead band or preload PWMENABLE with dummy data and output into space does not correct strange overlap voids after POR. That suggests GEN A/B duty cycle is not being synchronized by PWMSYNC REG-2 time base call, no matter how many times REG-2 is called after the generators are configured. The 3 generators outputs seem are not fully synchronized after reset or POR!

What is the work around to insure the first few duty cycle changes of PWM0 generators maintain synchronicity of A/B overlapping signals for the applications first use of PWMENABLE REG1?

Missing pulses were thought to be a phasing issue of the generators and it was directly related but not the cause.

  • Hello BP101,

    I am not sure what workaround to recommend.

    Can you provide example code for a LaunchPad so I can look at scope signals to observe the behavior where the signals become out of sync after POR and then see what could be done in software to workaround the issue?
  • Hi Ralph,

    Below are scope captures, may perhaps give clue to what is going wrong after EK-TM4C123G issues hardware reset via LM Flash or MCU reset pin to ground. Tried everything known in software to trick the PWM generators over lapping phase shifting into proper alignment. Notice the PWM frequency 50Khz in second capture but is actually 40Khz when zoomed out. Does the same misaligned phase shift  at other PWM frequencies. Lower capture is after first PWM run cycle, where proper GEN A/B center alignment of phase shifting duty cycle occurs. Notice the phase shift is causing missing pulses in the top capture waveforms. The shift issue is consistent with every reset top capture is produced.

    Seriously doubt you will able to see or capture incorrect overlapping phase shift without gate drivers attached. Two gate drivers working together create the signal below.  Scope is set on single trigger to capture the first 250us where phase overlap gets ugly after.

  • Found the issue was not directly PWM related as it seemed from captures. Rather GPTM1 a trigger for PWMENABLE was loaded with a 0 period from a static defined variable as 0 value. The application incremented said variable and never returned it back to zero after the function ended. PWM0 phase shifts so fast in the period it is difficult to judge exactly how pulses were missing relative to the captures taken well after a reset.
     
    Is it not correct to believe a static variable should resume its defined value after the function returns control back to the CPU? Also seeing some static variables not directly #defined VariableName = 0; gain huge values in CCS debug. Are not static variables supposed to automatically assume a zero value?

    According to Microsoft VS notes relative to static defined variables, they assume when defined,,, a zero value and retain value during interrupts.

  • Only took two days to figure out this odd phasing was a result of one value not being returned to 0 until reset. It was expected the CPU would after the function was released from the call stack or is that volatile variable will return to 0.

  • Other words the top capture would always have been produced every start period 250us, not produce the second capture which results only after the value was incremented.