LM5066IEVM-626: UVLO Gate Masking Behaviour

Hi Daniel,

Thanks for reaching out!

I will go through the above one and get back early next week. Hope this is fine for you.

Best Regards, Rakesh

Hi Rakesh,

Just to confirm what you mean: By masking the GATE for any fault event - will this reset the gate repeatedly or only once when masked?

The reason I ask is because we are experiencing some undocumented behaviour.

By keeping UVLO tied low and gate masking the fault, the LM5066I repeatedly retries to turn on the mosfet after 1 timer timeout (20ms period on the EVAL board). This leads to what I said earlier - any fault condition is not latched (i.e. OC or OP).

A completely different set of behaviour is experienced when using the OLVO fault to ensure the mosfet is off at power up, by connecting OVLO to Vcc. In this case, when the OVLO fault is masked, OC and OP faults thereafter are in fact latched and the mosfet is not repeatedly turned on.

I have attached scope traces showing the gate and timer pin behaviour for both cases during a short circuit.

Can you explain to me why there is a difference in behaviour between masking UVLO and OVLO, and why when masking the UVLO fault, it repeatedly resets all faults and prevents latching?

Kind Regards

Daniel

UVLO Gate Masked (and tied low), Retries set to 0:

UVLO Gate Masked (and tied low), Retries set to Infinite:

OVLO Gate Masked (and tied high), Retries set to 0:

Hi Daniel,

This is not the common use case in general. Can you help us understand the purpose of GATE masking in your system. This would help our designers to analyze the issue as we don't have much validation details for this rare use case.

Best Regards, Rakesh

Hi Rakesh,

We are trying to ensure that the mosfet is off at power up.

To do so we tie UVLO low, then when configuring the LM5066I, the UVLO fault can be gate masked and the rest of the hotswap functionality is as expected.

But by doing it this way we lose the latching functionality of the OC and OP faults.

An alternative method is to tie OVLO high and gate mask it. This does not prevent the OC and OP fault from latching and the hotswap controller functions as expected.

Is this the best way to achieve our requirement of ensuring the mosfet is off at power up?

Can you recommend another method?

Kind Regards

Daniel

Hi Daniel,

One way is to pull the UVLO/EN pin LOW as shown in Figure-16 in the datasheet

The other method is to issue OPERATION command 00h immediately after powerup (before the insertion time expires, refer Figure 13) to keep the system in disable state. These two are widely used and proven methods.

Best Regards, Rakesh

Hi Daniel,

Do you have any followup questions.?

Best Regards, Rakesh

Hi Rakesh,

Background:

  I can provide a bit more background. We are using the LM5066 to provide soft-start, short circuit protection, & diagnostic functionality on several power outputs (16 outputs). As Daniel mentioned we want these outputs to be off on startup. Hence artificially causing a lockout with UVLO/EN then masking the error once we have software control.

An additional complication is these LM5066 are on different electrically isolated sections. I2C control is very convenient as it only requires 2 signals to cross isolation.

Finally we are using the dV/dT startup configuration to allow large capacitance to be turned ON but with a fast fault timer in case of problems (Fault = 0.5ms)

Problem:

The fault mask register provides the ability to mask individual errors. Table 33 list all the errors which can be individually masked. It has undocumented effect on the UVLO/EN pin, this pin affects ALL faults including the overcurrent AND circuit breaker faults. Internally it appears to clear the fault in a way that makes the system detect an EN toggle (which clears all faults). e.g the mask affects both UVLO and EN part of the UVLO/EN signal internally.

OVLO fault masking appears to work more as intended and only affects itself.

Keeping MOSFET OFF at TurnON Options

TI Suggestion: One way is to pull the UVLO/EN pin LOW as shown in Figure-16 in the datasheet

Our Comment: We are doing that by keeping UVLO tied low. Unfortunately we cannot release it as per figure 16 since that would require an additional signal to cross electrical isolation, for each LM5066. (we are using 16).

TI Suggestion:The other method is to issue OPERATION command 00h immediately after powerup.

Our Comment: Good idea, we did not consider this. Timing constraints will very tight as our 10nF timer capacitor would give us about 7.8ms startup time. Realistically i dont think we can guarantee having communicated to all LM5066 with-in that time 7ms.

Follow Up Question:

1. Would you be in a position to confirm the exact behaviour of the UVLO/EN mask and how it affects all other faults?

2. With UVLO masked it appears to clear ALL faults either every ~100ms or ~20ms depending on the retry setting(retry, or not) but we have been unable to relate either time to the timer capacitor setting. Is it a hard-coded internal retry period?

3. Able to confirm this issue is confined to the UVLO/EN fault and that OVLO will work as documented?

Hi Daniel, John,

I understood the challenges in using the UVLO/EN pin for control or the OPERATION command 00h in your system.

I need to verify the behavior and discuss with our design team to find the root-cause. Please allow some time.

Best Regards, Rakesh

Hi Daniel, John,

I am yet to visit lab for bench verification. How critical is it at your end ? Have you explored any alternate ways to realize this function at your system level ? I just want to inform you that I can make some progress in the next week. 

Best Regards, Rakesh

Hi Rakesh,

 Having experimented using the OVLO error & masking we feel it will be an acceptable alternative to keep the device OFF until communication is established, and software control taken by masking this OVLO flag.

We loose the ability to turn off during an overvoltage but the trade-off is acceptable.

OverCurrent and Short Circuit are both operating as expected and latch-off with no retries.

I nonetheless feel this is an unexpected behaviour of the UVLO/EN error masking and the effect it has on clearing unrelated faults in addition. Maybe a note on on the datasheet if it ever gets updated?

Regards,

Alexis