TPS2493EVM-002: IMON spurious output

Hi Will,

Thanks for reaching out!

We have never observed that kind of behavior. Can you capture Vout, input current, UVEN, IMON in a single scope shot for the second test scenario where IMON pulse is observed and share it with us

Thanks, Rakesh

Thank you for the quick reply.  I apologize that I do not have the appropriate test equipment to perform the measurement as requested.

I have one additional piece of information which I dismissed but in retrospect may be important, and why you've never seen this.  During my very initial tests, using just a power supply and active load, one of the two MOSFETS failed.  It failed shorted Drain-Source (Gate/Source and Gate/Drain did not show a short).  I desoldered the failed MOSFET, and have been testing since using the remaining MOSFET.  The gate drive seems fine.  I cannot explain what happened that cause the MOSFET to fail.  It actually blew a blob of solder out from underneath it, when it heated quickly and then presumably failed.   Part of the thermal pad appeared discolored... perhaps the part had a coating flaw or contamination causing lack of reflow to the land, and subsequent hot-spot.

I assumed the TPS2493 was unaffected after this event, but perhaps whatever happened compromised the part somehow.

I should add that though I currently cannot capture 4 channels at once, the behavior I observe on the scope is very repeatable.  For example Vout looks the same the entire time the PRF is set to cause the IMON glitch.

How do you propose I measure the input current?  I assume you mean a direct measurement using a current probe?

Hi Will,

Thanks for the additional background details.

Do you have another TSP2493 device to replace on EVM and to check whether the behavior is repeatable or not? By this, we can also rule out that partial unknown damage for the original unit is not the cause.

 If you have current probe, measure the input current along with the IMON voltage to check whether they follow in time

Best Regards, Rakesh

Hi Rakesh,

I will order a few new parts, or another EVM altogether, and report back.

Continued testing shows everything else works as advertised (power limiting during startup, etc)

Will

Hi Will,

What are your target specs and requirements. ? 

Can you have a look at TPS25982, TPS1663x devices and let me know what you think.

Regards, Rakesh

Hi Rakesh,

Thanks for the recommendations.  Based on our requirements, it doesn't appear either are suitable unfortunately.

We are looking to run between 24-48V (surge to 50V), with up to 20A continuous current, with hardware-based fast transient overload protection, with slower MCU-based eFusing (i2t behavior).  The application will have about 20 of these output channels, so keeping power dissipation low per channel is important for passive heat rejection which is also a requirement for us.  I am looking at using the TPS2493 (or something equivalent) with an LM5050 ideal diode output in series (and a suitable TVS on the final output), with both controllers using NVMFS5C604NLWFAFT1G as the pass element.

I am open to other topology or part number suggestions.  This is what I've come up with after going through a previous design and prototype iteration, and new requirements being added (higher voltage, higher current, faster performance).

Also perhaps worth mentioning, I am looking to protect the main power input using an LM5060 and 4x parallel of the above listed MOSFETs, to provide OVP shutdown and gross overcurrent protection, with 100A steady-state pass current.  I just tested the LM5060 EVM and was happy with the performance.

Thanks,

Will

Hi Will,

LM5069 would be preferred over LM5060 device. LM5069 provides accurate overload protection, FET SOA protection (power limiting feature) and fast shutdown during short circuit events. 

The LM5060 is intended for applications where precise current sensing is not required, but some level of fault protection is needed. Examples are applications where inductance or impedance in the power path limits the current rise in a short circuit condition. Please refer 8.1.5 Overcurrent Fault in the datasheet.

Please refer http://www.ti.com/lit/an/snva683/snva683.pdf for configuring the device for surge support

Best Regards, Rakesh

Hi Rakesh,

I initially downselected to the 5060 vs the 5069 to eliminate the sense resistor, at the expense of a more uncontrolled current limit.  I will re-evaluate based on your recommendation.

Also, I have replacement TPS2493 parts coming, in addition to a new EVM.  I will post results once they arrive and I can repeat the tests.

Thanks

Will

Hi Rakesh,

Sorry for the delay in getting back. There was an issue getting the package delivered with the current state of affairs.

The new EVM behaves with the same spurious IMON output. I will attach a PDF with a graph of all the parameters of interest. Since I do not have a good way to probe the input current, I inserted a 10 Ohm resistor in series with Vin, and the measurement Vin represents the power supply output, and Vin' represents the input voltage to the TPS2493EVM board.

As in my original post, I can elicit this response by actuating the ENABLE switch on the PCB. For my testing, I connected a signal generator to UV(EN), adjusted the frequency until the problem arose, and then performed scope captures at each point in the circuit, at all times monitoring IMON to ensure the behavior was still present.

TPS2493_EVM.pdf

Also attached is the Excel file with the raw data I collected.

TPS2493_EVM.xlsx

Thank you for any insights,

Will

Hi Will,

I will check with the design team and let you know. Please allow time till end of this week.

Best Regards, Rakesh

Hi Will,

It seems to be taking more effort to analyse as the device is not designed for ON/OFF cycle applications. Can you please let us know whether the glitch on IMON is a concern for your system ? I hope you are using for current monitoring purpose, in that case can you initiate the monitoring after PG assertion. ?

Best Regards, Rakesh

Hi Rakesh,

Thanks for the reply.

We planned to use the IMON output to be read by an MCU, and provide i2t e-fusing capability for time-periods that extend beyond the very-fast acting built-in protections the TPS2493 provides.  We will be sampling at a rate that is high enough that we will see the IMON glitch, and it could activate the i2t algorithm (product still in design so nothing is solidified yet). And since the IMON output is full-scale during this glitch, it would appear as a catastrophic output current fault.  We could monitor PG line as you suggest, but there will be over 20 of these output stages in the system, so the GPIO count required increases by 20+ to monitor PG in real-time to compare/invalidate IMON readings.

I understand when you say the part isn't designed for On/Off operation - I assume you mean PWM operation, vs simply using the EN(UV) line to turn the part on once.  I had the signal generator running at around 5Hz for measurement convenience.  I also observe the IMON behavior when either manually using the enable switch or by using a signal generator set to below 1Hz. So in both cases the output was disabled for more than 1 second between EN(UV) assertions.  In my thinking, have a Toff of over 1 second constitutes "infinity" time for a part like this.  In other words, 1 second off, or 100 seconds off should be the same as far as the part is concerned.  Somewhere in the documentation I gathered that the part is a sampled-system internally.  If that is true, my guess is that if EN(UV) becomes asserted during the "wrong" clock-cycle, this problem occurs.  In our application Vin is always present, so I assume whatever circuits inside remain active even when the output is disabled.  By using a signal generator and slowly adjusting the frequency, it is fairly easy to elicit the IMON behavior by turning on the part "at the wrong time", every cycle.  And again based on seeing this behavior with a disable time being more than 1 second, it seems like random chance rather than the fact my testing uses PWM (for ease of testing and scope captures).

Understanding the part is not designed for PWM, how long must the part be disabled (but still have input power) before the condition does not arise?  If the part requires a 2 second blank period for example, we could probably accommodate that.  We are not looking to PWM the device, this is just an artifact of my test method.  But seeing it occur with an off time of over 1 second leads me to believe that this IMON glitch could happen at any power-on (when Vin is already present, and EN(UV) is asserted once to turn the output ON).  Also note that if I change the enable frequency from 4.9Hz to 5.0Hz (for example) the problem goes away.  I can find many various frequencies that will cause the IMON problem to appear and disappear with less than 0.1Hz change in frequency driving the enable line.  Even running less than 1Hz, a slight change in frequency will cause the behavior of IMON to change.

An alternate approach I have considered is to use the LM5069 and a part such as the INA282 to provide the IMON output.  It just increases BOM line count and layout complexity.

It would be interesting to find out if there is an OFF time (Vin present, not enabled) dwell time beyond which the part will not exhibit the IMON glitch at enable.  

Thanks

Will

Hi Will,

Thanks for the details and information on your additional findings. From your description,it appears to be of random in nature and can happen even at low frequency PWM cycling.

While we delve into the root-cause, Can you share your system requirements (max voltage, max load current) to suggest other options.

Thanks and Regards, Rakesh

Hi Rakesh,

Thank you for your most recent reply.

The nominal voltage ranges from 12-28VDC.  In the development of this product thus far, I have been trying to use at least 60V rated parts, but I can consider something with less headroom.

The maximum output current per device/channel is 20A continuous, with an instantaneous capability of some factor higher (5x or more?), to allow for startup inrush and longer duration i2t behavior.

Having a built-in current-sense output is a key feature we'd like to have, as I mentioned in an earlier post, to reduce BOM count and Layout complexity.  If the part already requires it's own current-sense resistor, then adding an external high-side amp such as the INA282 is something we could do.  We would like to have 5% accuracy or better on this measurement.  I have seen and used some parts that have a built-in mosfet switch which has a current-mirroring output sense signal, and those designs tend to be pretty non-linear at low currents (< 5A for instance).  We are interested to have linear response from below 1A to full-scale, as total current consumption of the system is a key parameter, in addition to providing accurate e-fusing capabilities.

I am only considering parts that are rated from -40C to +125C.  Due to other system factors, we are designing for continuous 100C temperatures at the PCB.

Thanks for the help you are providing,

Will

Hi Will,

Can you please look at TPS25982. It supports up to 24V, 15A continuous current and offers accurate load current monitoring analog output. If you can branch your loads into two, this device would be suitable. Else, parallel can be considered as discussed in app note http://www.ti.com/lit/an/slva836/slva836.pdf

Other option is TPS1663 up to 6A loads. Have a quick look and let me know your thoughts.

Best Regards, Rakesh

Hi Rakesh,

Thank you for the part recommendations, I just went through them.

The TPS25982 has too little of voltage headroom for me to be comfortable. Running at 28V, there is only 7% until absolute maximum is reached.

The TPS1663, paralleled, could work.  Total cost and part-size are almost a wash compared to my initially proposed solution (assuming layout doesn't get too bad with parallel parts).  But, as I had been planning on using an external MOSFET with about 1mOhm of on resistance, vs the 33mOhm on-resistance of this part, the heat dissipation issue becomes much larger.  A 5A channel for example goes from 25mW to 750mW Pdiss.  For these channels at least, I would need to do more computations to see if the standard PCB layout will pull out enough heat or if special heat-sinking is required.  At 20A, a single 1mOhm mosfet would dissipate 0.4W... a total of 4x TPS1663 in parallel would dissipate 3.1W (about 8x more heat).

One thing that I don't think I've seen addressed, is for the TPS1663x parts, can you parallel the IMON outputs and achieve a sum-total of the currents passing through each device? Or would you need to monitor each of them individually?

Thanks

Will

Hi Will,

Given these challenges, we have to go with the hot-swap controllers.

Regarding your question on TPS1663x:- the IMON output are current sources and can be tied together to get overall current information. The Rimon resistor has to be scaled appropriately (Rimon_eq = Rimon/No. of parallel devices)

Best Regards, Rakesh

Hi Will,

From our analysis, we saw that the current into IMON lasted till Gate reaches VOUT i.e., for ~200us. We want to verify whether IMON pulse has any dependency on the GATE rate-of-rise. I can plan to visit lab for testing but may see some delay due to restrictions now. If possible, can you test EVM by adding capacitance at GATE for two below cases. EVM has placeholder for that at C4.

1. C4 = 2.2nF 
2. C4 =10nF

Thanks and Regards, Rakesh

Hi Rakesh,

Yes I can test in the lab, by today or tomorrow (I am at home but can still go into the office if needed for lab work). 

I would like to confirm the value of R11.  I see the EVM datasheet recommends 1k.  Is this the value you'd like to see installed along with the C4 tests?

Thanks,

Will

Thanks Will

Install R11 also and use 1k for R11

Best Regards, Rakesh

Hi Rakesh,

I was able to repeat the test with R11 = 1k, and C4 = 10nF (I didn't have 2.2nF available)

The IMON spurious output appears to have remained the same duration.  I kept the x-axis scale the same as the prior tests, though due to the C4 action, it turns on slow, past the end of the scope capture.

Raw data and PDF plot attached here.

TPS2493_EVM_C4=10nF.xlsx

TPS2493_EVM_C4=10nF.pdf

Thank you.

One question: Why Vout is not reaching zero in OFF condition. ? Are you testing at no-load ?

Best Regards, Rakesh

Rakesh,

Hi Will,

Thanks for the confirmation.

Since it is bit old device, our designer is accessing the database to look into the issue. Please allow time till end of next week, we know it is going on for a while.

In the meanwhile, explore/carry out the paper work for alternate solution (LM5069 + current sense amplifier) and reach sif you have any questions.

Best Regards, Rakesh

Hi Will,

We have observed similar behavior in the design. The device uses clock for sampling the current and in some corner cases the IMON pulse was observed. The immediate solution is to do a workaround at system level to blank the IMON information as soon as the device is enabled. We would need few transistors and resistors to realize it. Please let me know your thoughts... whether to work towards a system fix for TPS2493 or explore alternate solution (LM5069 + current sense amplifier) ?.

Best Regards, Rakesh