• State TI Thinks Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 4 answers
  • Subscribers 63 subscribers
  • Views 2397 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.

UCD3138: NO DPWM OUTPUT UNDER SOME TEST CONDITION

jun yin
Intellectual 875 points
Part Number: UCD3138

We met one strange DPWM behavior on UCD3138 in one of our projects; under some test condition, there is no output signal for all DPWM;

We use UCD3138 as the controller of full bridge converter and use DPWM in normal mode; in this strange situation, through memory debugger, Dpwm0Regs.DPWMFILTERDUTYREAD shew that there should be max duty cycle output; while there is no PWM signal on all DPWMs;

 

We checked DPWMCTRL0.PWM_EN, LoopMuxRegs.GLBEN and MiscAnalogRegs.GLBIOEN, all of them enabled the DPWM;

MiscAnalogRegs.GLBIOEN’s reading was 0x14004000, if we write 0x1400407F to disable DPWM and write 0x14004000 to enable DPWM again, without changing anything else, there was still no DPWM output;

LoopMuxRegs.GLBEN’s reading was 0x50F, if we write 0X50F again, the write was success, but there was no DPWM output; if we write 0x500 to disable DPWM and write 0x50F to enable DPWM again, without changing anything else, all DPWM came back; 

DPWMCTRL0.PWM_EN’s reading was 0x01, if we write 0X01 again, the write was success, but there was no DPWM output; if we write 0x00 to disable PWM and write 0x01 to enable PWM again, without changing anything else ,this DPWM would come back;

The DPWM could recovery by reset LoopMuxRegs.GLBEN or DPWMCTRL0.PWM_EN, but their original values were right to enable DPWM, why?

  • 0
    TI__Genius 17090 points
    If the DPWM gets a fault, it will require disable followed by enable to start it up again.

    Notes:
    1. If you are using DPWM interrupts on some of the older family members, they will be stuck on when you disable the DPWM.
    2. Some A series devices have a FLT_RESTART bit in the fault control register in the DPWM block. A falling edge on this bit will have the same effect on the DPWM. It has an additional benefit that if only 1 of the DPWM pins is disabled by a fault, for example DPWMB being used as a synchronous rectifier control, you can restart DPWMB without stopping DPWMA
  • 0 in reply to Ian Bower
    Intellectual 875 points

    thanks

    we're using UCD3138;

    is it possilble that DPWM got stuck by hardware noise? because our converter works normally when the switching noise is low; while under some test condition, the switching noise is very high and we saw this kind of issue;

    noise on which pin could cause this kind of latch? we saw DPWM0A, DPWM0B, DPWM1A, DPWM1B were both disabled;

  • 0 in reply to jun yin
    TI__Genius 17090 points
    I suspect that you are getting a fault when the switching noise is high because you are not doing enough either filtering or blanking of the fault signals.


    What firmware are you using? Our EVM firmware normally has some faults enabled.


    If you look at section 6 in the UCD3138 technical reference manual www.ti.com/.../sniu028a.pdf ,you will see how faults are enabled and how they effect the DPWM.

    The UCD3138 has comparators on some of the ADC pins, and they can be programmed for things like overcurrent and overvoltage faults.
  • 0 in reply to Ian Bower
    Intellectual 875 points

    Yes we're using fault detection by analog comparator; we also use its interrupt; we disabled and enabled DPWM after interrupt;

    after disabling the fault detection, the DPWM never latched;

    so the fault of analog comparator 100% triggers the DPWM fault detection and interrupt, right? why some times we can't clear the DPWM latch by disabling and enabling DPWM agaIn?

  • 0 in reply to jun yin
    TI__Genius 17090 points

    I suspect that the analog comparator is generating a fault again, or still, when you are done disabling and reenabling the DPWM. 

    If you are using and interrupt to clear the fault, make sure that you use the DPWM fault interrupt, rather than the fault mux FAULTMUXINTSTAT based interrupt.

    The DPWM fault interrupt is actually on a parallel circuit with slightly different delays.  Sometimes there will be quick glitch that may trigger the DPWM fault but not get latched into the FAULTMUXINTSTAT register. 

    We've never seen an issue with the analog comparator logic like you are suggesting, other than what I describe above.

  • 0 in reply to Ian Bower
    Intellectual 875 points

    you mean for some quick glitch, DPWM fault may be triggered by analog comparator, but FAULTMUXINTSTAT may not be got latched? while if DPWM fault interrupt is used, it would works once DPWM fault is triggered, right?

    the DPWM fault interrupt you're talking about is priority 26,27,28,29 of CIM, right?

  • 0 in reply to jun yin
    TI__Genius 17090 points
    Yes, you've got it right.
  • 0 in reply to Ian Bower
    Intellectual 875 points

    thanks a lot;

    then what's the minimum pulse width for analog comparator to trigger DPWM fault detection and what it is to trigger FAULTMUXINTSTAT register? for example 0.1v overdrive on analog comparator;

  • 0 in reply to jun yin
    TI__Genius 17090 points
    it's going to be very short, say less than 64 ns on the output of the comparator, but if you are just close to the threshold, it's hard to tell on the outside. I may be wrong on this issue. I've talked to design, and they haven't confirmed this issue. There is a related issue if you read from the Fault Mux register at the same time as it's being set, it will be cleared, and you won't ever see it. That is confirmed.

    All of this requires very precise timing, and tends to happen very intermittently. If you are getting it consistently, I suspect it's a more coarse issue that you need to fix with filtering or blanking.
  • 0 in reply to Ian Bower
    Intellectual 875 points

    no, it didn't happen all the time;

    and we confirmed that analog comparator triggered the DPWM fault detection but not the FAULTMUXINTSTAT and its interrupt; this could be also proved that if we set AB_MAX_COUNT larger than 5, the issue never happened; we set AB_MAX_COUNT as 0 before; the signal on ADC is a ramp up waveform with some noise; due to some limit, it's hard to filter out the noise;