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.

LM5160: LM5160: LM5160: Sometime not start (part2)

Part Number: LM5160
Other Parts Discussed in Thread: TPS386000

Hello,

I start this new thread because the last was locked (after only 1 month ?).

The initial thread is on this link:

https://e2e.ti.com/support/power-management/f/power-management-forum/975785/lm5160-lm5160-sometime-not-start/3639501#3639501

At the end, we think the problem comes from the input EN behavior

1) At the start, the EN input is directly link via resistor bridge to the input voltage (24V). But when the input voltage was noised, the chip not start and was blocked, the output voltage was 1 or 2V.

2) We link EN from an TPS386000. By this, the problem comes when input voltage grow up very slowly. In fact, when the input voltage overpass the input threshold of the TPS386000 (17V), the EN input was enabled. The LM5160 start. But its start lead to load the input and generate some minor noise, but this was sufficient if the input voltage nt grow enought, to goes under the TPS386000 threshold hysteresis. THen its output lock again the EN Input, and after few ms enable again. (If the input voltage grow up fast, there is no problem).

Then we can conclued the LM5160 has a strange behavior and will be blocked if EN input is not stable and evoluate too fast. I reproduced a simplified chronograme:

From the point 2 observation, we validate this conclusion by only place a manual switch on the input EN. We easily reproduce the problem when we make move this switch fast (< 100ms). THis could be easily reproduced on your side.

Bellow the schematic we finaly design to correct the problem

/resized-image/__size/1576x925/__key/communityserver-discussions-components-files/196/0143.Schema.jpg

What is your opinion on my analys? Is possible you reproduce this problem on your side?

Regards and thank for your support.

  • Hello,

    Regarding statement #1, noise on EN pin should not latch the controller in an irregular state. Some irregular behavior on turn-on/turn-off could occur if you are holding EN in the "gray zone" around UVLO, but sufficient EN voltage in accordance to EN rising parameter should result in regulated output

    Regarding statement #2, when EN rising is exceeded controller should be full-on. with fast ramp (normal ramp) on enable, is device regulating appropriately?

    Have we confirmed that the BOM is indeed stable?

  • Sorry for the thread getting locked. That is a rule by the TI leaders to prevent people hijacking old threads and to ensure that the thread gets attention.

  • Hello,

    For the #1, The problem occurs when EN goes 3.3V whereas state was between 0.35V and 1.24V (Standby mode)

    Then with the TPS386000 we forbid this intermediate state.

    For #2, Yes if Input groes up fast, no problem occurs, no "glich" occurs on EN input. You can Try, Place 24V on input, EN = 3.3V, output power is Ok.

    Place EN to 0 and then to 3.3V slowly => Ok, not make a brieve falling/rising edge (> 5ms) then the ouput fall and never rise to 24V. We must apply a new low level on EN pin (>100ms) to start correctly (This with input voltage level set to 24V stable)

    For the Bom we use the same as application note.

  • Hello,

    I would recommend avoiding slow ramp if your design allows for this.

  • Hello,

    We cannot control the 24V supply of our customers. It can be subjected to disturbances and must always restart after these

  • Hello,

    Do you have ability to add comparator before EN pin so we can get sharp edge?

    My hypothesis is slow ramp is causing issues with device logic.

  • Hello,

    In fact, with the TPS386000 we already have sharp edge. But we have a short time High Logical on EN (few ms).

    I think this is the problem.

  • OK. I believe ms, which is usally considered DC to our device, should be sufficient to toggle the state

    This statement is troubling to me:

    "

    For #2, Yes if Input groes up fast, no problem occurs, no "glich" occurs on EN input. You can Try, Place 24V on input, EN = 3.3V, output power is Ok.

    Place EN to 0 and then to 3.3V slowly => Ok, not make a brieve falling/rising edge (> 5ms) then the ouput fall and never rise to 24V. We must apply a new low level on EN pin (>100ms) to start correctly (This with input voltage level set to 24V stable)"

    From my interpretation it described a latched-type behavior on EN. Assuming you fall or rise above the threshold + hysteresis on this pin, the state should change.

    I would like more clarification on this statement if this behavior is still being experienced.

  • About EN input, We use the TPS386000 to drive EN pin,

    Then EN input voltage is either 0V or 3.3V (via pull-Up).

    Rise and falling time of EN pin is the rise/falling time of the TPS386000. (about few ns)

    Then the mecanisum threshold of the EN pin (via the adding of current source) has no effect with this schematic.

    But, the TPS386000 has a Trigger threshold input. If 24V power decrease under 17V, output (linked to EN pin) fall to 0. If rise above, output rise to 3.3V.  But the 17V threshold has also Hysteresis inside TPS386000. And we noted that when input voltage rise above TPS386000 threshold, has as consequence to make fall a little the 24V power. If the current power rise slowly, this little fall is sufficient to pass under the TPS386000 Low threshold and make output fall again. So this generate a small pilse on the EN input pin.

    To summarize, a fairly short high state on the EN input, then a short low state too, before going back to the high state definitively, is enough to block the component.(Like given on the above chronograme)

  • Thank you for clarifying.

    Could you please share oscilloscope capture that resembles that of your drawn chronogram?

    I went thru your old thread and could locate anything similar.

    I would like to address this issue to the rest of the team to get their thoughts.

  • Hello,

    Currently, I must modify again our hardware to restore the original schema to make a screenshoot.

    I havn't hardware under my hand today.

    I will try to do this into next days,

    But i don't think this prevents you from passing on to your team, because the chronograme given above is very similar to the scope.

    Regards

  • Hello,

    This hasn't been seen before as far as I am aware, thus I would like a scope shot to both verify problem and to share.