• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 62 subscribers
  • Views 603 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

UCD3138 DPWM Overflow Errors

David Yellin
Prodigy 115 points
Other Parts Discussed in Thread: UCD3138

Hi,

We are developing a totem-pole PFC based on UCD3138. We use the example code from the PFC EVM.

We are having a problem tracking down why the MCU sometimes stops the DPWM module.

We notice that each time this happens the DPWMOVERFLOW bits PWM_A_CHECK and PWM_B_CHECK go high.

Is there any TI documentation explaining when and why this happens?

The only explanation we can find is that "1 = Failed check (override required to enable output)".

It may be relevant that we have paired the outputs DPWM0 and DPWM1 so that we can use the A side of DPWM0 for switching the primary FET during the positive line half-cycle and the A side of DPWM1 for switching the primary FET during the negative line half-cycle. 

In other words DPWM0A and DPWM1B are tied together, as are DPWM0B and DPWM1A. The unused channels are set as inputs.

Thanks for the assistance.

  • 0
    TI__Genius 17090 points

    I have never seen those bits go high, but I think that is because we always set the CHECK_OVERRIDE bit in DPWMCTRL1.  Do you have this bit set?  While you're at it, I'd suggest setting the PWM_A_PROT_DIS and PWM_B_PROT_DIS bits as well. 

  • 0 in reply to Ian Bower
    Prodigy 115 points

    I tried setting those bits, but it doesn't seem to make any difference. I'm wondering now if it has something to do with the frequency compensation of the converter. It seems to enter a state where both A and B channels have a very short pulse once per period, even when the B channel is set to be GPIO and off.

  • 0 in reply to David Yellin
    TI__Genius 17090 points

    I'm not sure what is going on.  To find out when the issue happens, it's often helpful to run the DPWM in open loop mode.  In effect, you take control of the frequency compensation and put out a fixed pulse width to the DPWMs to see where the issue occurs. 

    The easiest way to do it is probably as follows:

    1.  Make sure there's no power going to the FETs, as you are going to remove the feedback loop

    2. Have the system running - you may have to disable fault detection to keep it running without any power output

    3. Put FILTEROCLPHI and FILTERCLPLO to the same value.  This clamps the filter output to that value

    4.  Experiment with different filter output values to see where the phenomenon occurs.

    Happy Debugging,

    Ian Bower

  • 0 in reply to Ian Bower
    Prodigy 115 points

    Hi Ian,

    I tried clamping the output at 20% duty cycle using this technique. 

    Strangely, it seems the PWM Check bits are now always high. If I set the PWM override bits as suggested:

    Dpwm0Regs.DPWMCTRL1.bit.CHECK_OVERRIDE = 1;
    Dpwm0Regs.DPWMCTRL1.bit.PWM_A_PROT_DIS =1; //disable asynchronous protection
    Dpwm0Regs.DPWMCTRL1.bit.PWM_B_PROT_DIS =1;

    Then the whole DPWM module is disabled.

    Without setting these bits, the PWM output is correct as long as there is no load attached..

    However, when actually switching the live circuit the signal cutoff phenomenon happens as we raise the voltage.

    We are working with low DC voltage for testing right now. at 30 volts everything is fine, but as we raise the input voltage to 40 or 50 volts we start seeing the many of the outputs on the MCU go down to zero for a few seconds at a time.

    We also tried reducing the duty cycle, and basically it seems like the phenomenon is proportional to total power going through the PFC. The more power, the more it happens.

    Maybe it's some kind of EMI issue. It seems strange though because the logic and driver supplies are isolated and we have a six layer PCB with separate power and  ground planes, etc...