BQ25750EVM: Damage with 48V battery

Hello Kris,

Kris Parrent said:

So far, we have not been able to get I2C working on multiple computers through Battery Management Studio or the TI charger GUI using the EV2400 with the EVM or our board. Very frustrating. It seems most of the responses from TI on similar issues are to "try a different computer". However, we are able to establish communication with a BQ34Z100 EVM through the same setup.

This issue has not been resolve as of now, we are working to get it resolve. However this issue is related to hotplugging the battery, so I'm not sure if this is related to what you are seeing.

Can you explain more on your setup. What is the adapter voltage? Do you have a system load?

Kris Parrent said:

So far, we have not been able to get I2C working on multiple computers through Battery Management Studio or the TI charger GUI using the EV2400 with the EVM or our board. Very frustrating. It seems most of the responses from TI on similar issues are to "try a different computer". However, we are able to establish communication with a BQ34Z100 EVM through the same setup.

The online TI charger GUI use the USB2ANY device to communicate with the charger. If you are using EV2400, you will need to use BQstudio.

Can you provide an image of BQstudio when the device is not communicating?

I also recommend using just the adapter when trying to communicate to the device for the first time.

Best Regards,

Christian.

Hi Christian,

Thank you. My apologies, I did try the USB2ANY with the TI Charger GUI. It was not detected on either computer after trying both the chrome extension and offline bridge packs.

This issue did happen when hot plugging the battery. We have not tried it without. We need to build a new board because it burned up the pads and traces on the IC. I was applying 48-50V with DC power supply to VIN on our custom board which is very closely related to the EVM (basically removed the DNP pads and modified the resistor dividers per the datasheet).

Do you have an expected ETA for a fix? Or recommendations for trying? Is this guaranteed to only be an issue when hot plugging? We have seen pretty big sparks on connecting the battery without first using a DC supply to charge up the caps.

I will reply with the image from BQStudio from the other PC.

Please note Device ACK error

Hello Kris,

Kris Parrent said:

Do you have an expected ETA for a fix? Or recommendations for trying? Is this guaranteed to only be an issue when hot plugging? We have seen pretty big sparks on connecting the battery without first using a DC supply to charge up the caps.

The engineer who is working on resolving this issue is out this week and will return on Monday, and he will provide further details on what the next steps are.

The issue with the I2C commuication: Can you confirm that you are testing on a new board, it's possible the I2C could have been damage from hot plugging the battery.

Is SCL/SDA pulled high?

Best Regards,

Christian.

Christian,

On the EVM, we are seeing a short to ground keep reappearing on ACUV after replacing the charger IC a few times. We have removed all other things from this net (resistor divider). Do you have any thoughts on other components that may be damaged which are causing this to keep reappearing?

On our new board that just ran, the board seemed to be working when we applied just battery. We had multiple MOSFETs fail as soon as 50V DC power was applied to VIN. Do you mind if I send you the schematic through E2E for a quick review?

Thanks,

Kris

Update: The damage on the new board was a power supply issue. We are now successfully charging a battery at a lower current rate (1 A). However, we are seeing that the ACFET gate voltage is changing with the input voltage which was caused one of the ACFETs to fail.

At 49V, the gate voltage is exactly 10V as described in the ACDRV section of the datasheet. However, if we change to 48V it drops to approximately 2.5V which greatly increases the RDS of the MOSFET and it overheats. At 50V we see approximately 9V. At 49V we see approximately 8V. Why is this voltage not stable?

The scope image below shows the ACDRV gate voltage at 49V input and then transitioning to 48V input.

Second update: This seems to have some relation to the battery voltage. As I let the battery charge, 49V stopped driving 10V on the gate, and I had to increase it to 50V on the input to get the 10V on the gate. The battery voltage at that time was 46.8V.

Both of these waveforms are using the common source of the ACFETs as a reference. Blue is VIN and Green is the gate voltage. This is just manually turning the supply on for just a moment at 48V (so I don't overheat the MOSFET). There is quite obviously an issue here, but I'm not certain where to go from here. It looks like we could use a capacitor in to absorb the oscillating spikes after turning off, but that won't help the < 10V on the gate issue.

Can you give more information on how ACDRV works? For what it is worth, without any diode on there we do not see any voltage change on the gate when VIN is applied. I have also replaced the zener with three brand new diodes of different manufacturers and all behaved the same way. So it seems this is likely related the ACDRV signal.

Why does the EVM have a zener on the ACFET gate but not the BATFET?

Hello Kris,

The Zener diode is used as an input protection gate-source clamping diode. This diodes protects the gate to source voltage from getting to high, it needs to clamp the voltage at around 15V.

Are you seeing this on your board or the EVM?

Best Regards,

Christian.

Hi Christian,

This is on our custom board. The EVM has a short to GND on ACUV that keeps reappearing so it is unusable.

We replaced the IC as well and still have the issue. The gate voltage changes with every volt change. Interestingly, the gate works well enough (5V) from 25-40V and 50V. I also noted that it moved up a volt as we charged the battery a little bit. So for some reason, it seems to be following the battery voltage which is at roughly 46V.

Do you have any thoughts of things to try based on our schematic? I also tried removing the VAC resistor divider for VAC and tying ACUV to VAC through a 1k resistor and ACOV to GND through the bottom resistor to make sure it wasn't an issue with the divider logic.

Thanks,

Kris

Hello Kris,

Kris Parrent said:

On the EVM, we are seeing a short to ground keep reappearing on ACUV after replacing the charger IC a few times. We have removed all other things from this net (resistor divider). Do you have any thoughts on other components that may be damaged which are causing this to keep reappearing?

To clarify, if you tie ACUV to VAC, it's still shorted to GND. Are you able to read the registers?

I'm not sure why the ACDRV is not stable. I will have to review this information, and update you after I gather more information.

Best Regards,

Christian.

Hi Christian,

We have never been able to establish I2C communication with any of the BQ25750 devices on multiple computers. I sent the screenshot previously. If you have any suggestions please let me know. We had ACUV tied to VAC through a resistor, but I can replace that with a 0 ohm resistor if you think it will make a difference. 

This is a high priority project for our client. We would greatly appreciate any thoughts or guidance on things to try as soon as possible.

Thanks,

Kris

Hello Chris,

I'm sorry for the delay, We've have limited bandwidth this week.

Kris Parrent said:

We had ACUV tied to VAC through a resistor, but I can replace that with a 0 ohm resistor if you think it will make a difference. 

I'm sorry for the confusion. I meant this as a question. If you tie ACUV to VAC, is it still shorted to GND? If this is the case, and you already replaced the IC, the PCB trace may be damaged. My only suggestion for this is to order another EVM.

Kris Parrent said:

We have never been able to establish I2C communication with any of the BQ25750 devices on multiple computers.

On your board, are the I2C lines pulled up? 

Best Regards,

Christian

Yes, they are pulled up. I am able to get a response directly from the charger via the MCU over I2C. It is clearly a driver issue happening on multiple PCs or an issue with Battery Management Studio / TI Charger GUI. What information do you want me to pull from it over I2C from the MCU? Please provide specific commands. The same setup works for the BQ34Z100 on the same bus from the same program.

I have a new EVM and will test this again without hotplugging the battery.

If I were to remove the ACFET and BATFET circuits which are "optional", what is the end impact of that for the application? Does the BAT automatically go through the DC/DC to power VSYS when VAC drops out, or is there more to it? What is VSYS regulated to in that case?

The below image is from another brand new BQ25750EVM. I added external resistors for charge current and number of cells (JP2 and JP3) and removed the stock jumpers for those two (JP1/JP4) , but otherwise it is set as from the factory.

I cannot get I2C communication from Battery Management Studio.

I applied VIN and checked the ACDRV signal and it appeared to be working steady at +10V referenced to VIN. I disconnected the power supply and connected a 48V battery with exactly 48V on it. The kit is not working. BATDRV is not being driven high and so VSYS is low. Please see the below image.

Has this kit been tested with a 48V battery? Please let me know what else could be wrong, but I can't find anything in the datasheet which says BATDRV should not be high when there is 48V on the battery so it appears this kit is also now damaged or was defective from the start. This is getting expensive real fast.

Hello Kris,

Thanks for being patient with this. I just started taking over this thread after coming back from a long vacation so I'm still ramping up.

For the EVMs being damaged, the fast rise time of the battery being hot plugged is probably damaging the EVM.The fast rise time causes a current spike which damages the IC and BATFETs.

There are 2 ways to work around this. The 1st is to use the IC's auto reverse mode. To activate auto reverse mode, you'll need to remove the BATFETs, set EN_AUTO_REV=1, WATCHDOG=disabled, and VSYSREV to your desired system voltage.

The 2nd is to modify the BATFETs to slow down the turn-on time. We are still working on validating this.

To test that the IC can communicate over I2C, I recommend starting at a much lower voltage, like 10V or so, on VBAT.

You'll probably also want to to fix the EVMs that have had a 48V battery applied to them as well. You'll probably need to replace the IC, BATFETs (Q7, Q8) and the SRN/ SRP resistors (R22 and R25). You'll want to measure R5 and R6 to make sure those resistors are 10Ω. If those resistors are bad, you'll need to replace Q5 and Q6 as well and the resistors.

This is a lot of information at once so let me know if you have any questions or something wasn't clear.

Best Regards,
Ethan Galloway

Hi Ethan,

Thank you for the information. This second kit I did not hot plug the battery. It seemed to stop operating on the first battery connection which was after the power supply was removed. On the first kit, I did hotplug the battery a few times meaning when the power supply was also connected and on.

At this time, the higher priority issue for me is with the ACDRV being unpredictable in the design. Can you help review that? I have performed a workaround by disconnecting the ACFET gate from the charger and driving it with an external component that activates when power in is applied, however, this is a temporary fix and we need to understand that issue better before proceeding. I need to get a few samples out for load testing and validation, and then I can come back and evaluate the EVMs.

Thank you,

Kris

Hello Kris,

I'm looking into the ACDRV issue right now and I'll get back to you before the end of the week. Thanks for being patient with this.

Best Regards,
Ethan Galloway

Ethan,

Regarding the BATDRV damage, on our custom board we have the capability to put two 48V batteries in parallel. We had validated a board with a workaround on the ACDRV that had the same functionality and was running solid with one 48V battery connected. We had charged fully, drained the battery down, cycled and started/stopped charging several times, no issues. Disconnected batteries, reconnected batteries, etc. Everything was running perfect.

I was confident in testing two batteries in parallel now. I plugged the batteries in and the system powered up fine. It's important to note that the batteries have two separate connectors so it was plug one in and then add the second. I started charging, and that worked as well pulling the correct amount of current, batteries charging, etc. When I turned the power supply off, the BATFETs and associated circuit got damaged. This was not a hotplug scenario.

In addition, the 48V battery that was used for the EVM was larger than the two batteries used for this demo (more cells in parallel). It seems like this is NOT a hotplug only issue, and it may be related to the battery current sourcing capabilities.

Would this make sense based on the issue you are investigating?

Hello Kris,

Thanks for the new information. I'll need to do more tests on my side to confirm this.

That problem you described might be related. The main issue for the FETs is having a delta V of greater than 30V. We already have a potential solution that I can share with you if you would like.

Best Regards,
Ethan Galloway

Ethan,

Sure! I'm in the thick of this so I would be happy to try any solutions that you may have. That is much easier than trying to work around it.

I will also send you a message with our schematic just to make sure there isn't anything else going on, but it seems like the damaged parts are exactly the ones you identified.

Thanks,

Kris

Hello Kris,

I'm in the process of replicating your ACDRV test at the moment. What was your charge current during the test? Is there anything else about the test that you can tell me?

For the BATDRV solution, we recommend using FETs with min VTH of 2V or higher and using a 10nF capacitor on the FET gate (C36 on the schematic). We are still in the process of testing this though.

Best Regards,
Ethan Galloway

Thanks Ethan. Confirming I am using the BATFETs from the EVM which are over 2V Vgs(th).

I added the 10nF cap as a starting point and scoped out the BATDRV with one battery. This is with the probe referenced to the common source of the BATFETs.

There are some pretty nasty spikes in here which is likely where the damage is happening (curious how big this spike was BEFORE the cap). Is there any reason that we wouldn't want to put a 15V zener across this similar to the ACFETs to protect from the initial voltage spikes?

Hello Kris,

Thanks for your measurements.

BATDRV is referenced to BATSRC inside the IC so that pin doesn't need a zener diode. Because ACDRV doesn't have a pin similar to BATSRC, ACDRV needs the zener diode to prevent the gate from rising 20V above the drain.

For your bottom image, are you measuring BATDRV with a diff probe? The IC limits the inrush current to 8A. The spikes are the IC turning on the BATFETs and turning the BATFETs off when the current gets too high. This mode is active only when the power path is switching over.

You can see this FAQ for more information about the power path switchover.

Best Regards,
Ethan Galloway

Hi Ethan, 

My apologies, I should have described the captures better. They are both the same capture which is a system with no power and the battery connection triggers the scope. The first image is zoomed in on the initial spike from when the battery was connected. The second capture is just zoomed out to see the gate stabilize. 

There is no power applied to VAC so there should not be a power switchover. Any thoughts on where to start there? I'll add a probe to VAC just to make sure it's not making it through the ACFET somehow. I do have the ACUVACOV set to GND/VAC. Could this be startup noise making it onto the resistor divider? 

The only load on the system in the capture is a few DC/DC modules which do not have a load applied to them

Ethan,

Can you point me to the documentation on this text from your link:

"The BQ25750 will turn-off the ACFETs or BATFETs if the current through the FETs is greater than 8A"

Our system load is not currently, but once we are in a production system, be over 8 A. Is this 8A limit an inrush only measurement, or a BQ25750 limitation? I can almost guarantee that our inrush current is over 8 A, but I have not measured it. In the datasheet it says:

• "Adjustable input current regulation (RAC_SNS) from 400 mA to 20 A with 50-mA/step using 5-mΩ resistor"
• K(ILIIM) is also defined as a max of 52 A
• I(AC_ADC) is defined as up to 50000 mA
• I(BAT_ADC) is defined as up to 20000 mA

Great post. Thanks for the information. 

Ethan,

I tried auto reverse mode a few times, and it seems whenever VAC is on and auto reverse is on that I get a hardware fail of the IC, MOSFETs, resistors mentioned previously. I set register 0xC to 0x2580 (should be VSYS_REV = 48V), and enabled auto reverse.

- Auto reverse worked appropriately while operating on battery only without VAC. I saw 48V on the output as expected with a 43V measurement on the battery.

- I disconnected the battery and powered VAC to test that operation by itself before connecting both power sources. The system immediately popped and smoked.

I had also previously turned reverse mode on while charging a battery and also damaged that hardware. What am I doing wrong?

It's getting hard to see a path forward here. I sent the schematics in private messages in case you have not seen them.

Thanks,

Kris

Update - we did some board surgery and performed the bypassing the battery current sense resistor workaround with the BATFETs and we are successfully charging two batteries and able to turn the charger on and off. I should also note that we also experienced the "clicking" sound mentioned in several other forum posts every time we turned the charger off which has now gone away.

It seems very likely that the major and potentially only issue here was the undocumented 8 A current limitation cycling the FET gates on and off due to inrush current and causing havoc on the system. This costs us WEEKS of engineering efforts and was extraordinarily expensive to debug. I formerly worked at TI for several years as an application engineer, and I take quite a bit of pride in TI products and using them across many of the designs I do.

TI dropped the ball here.

From the start I was never able to get BQ Studio or the TI charger GUI to communicate despite trying multiple computers with both the EVM2400 and USB2ANY. I was able to get it to communicate via direct MCU I2C so this means it is a software or driver incompatibility issue. I blew up multiple EVMs on a somewhat known issue that was also undocumented (hotplugging issue). These issues/limitations need to get into the datasheets and EVM manuals as soon as possible.

I am available for a meeting with anyone who would like to further discuss the problems encountered here.

Hello Kris,

Thanks for being patient with this. We appreciate your input here. I know it has probably been frustrating working back and forth as we work through the problem. We are currently in the process of adding the information about the hot plug and the 8A current limit to the datasheet and EVM User's Guide.

For the communication problem, you might need to update the USB2ANY to the latest firmware. I'll need more information before I can diagnose the EV2400.

For your schematic, the schematic looks good and it sounds like you fixed the BATFET portion of the schematic.

I have few questions about your solution if you don't mind. Did you use the AONS66917 FETs and did you use a capacitor on the FET gates? Also, is hot plugging the battery still an issue for you here?

Let me know if you have any more questions. I'm still working on the solution for the hotplug issue. Also, let me know if you still are seeing issues with the ACDRV. I wasn't able to see any problems in the lab.

Best Regards,
Ethan Galloway

Ethan,

The EVM2400 works with the BQ34Z100 in battery management studio so I do not suspect it is an issue with that. That was updated to the latest firmware.

I believe USB2ANY was also updated to the latest firmware, but I will double check. At this point, I have already built most of the I2C library out on the MCU, but making that solution more seamless will definitely save headaches for someone down the road.

I am using the AONS66917 FETs with a 100n capacitor. This will likely get reduced at some point once I start checking it with higher loads and seeing how the voltage drops, but that was my next swing after the 10n was insufficient. I would guess this is going to be application dependent somewhere between the two. I chose 100n based on the LM74801 EVM inrush current limiter circuit on the gates of their FETs. The IPD100N06S4-03 have not failed once that the design uses for those have not failed once, but they are also coming off of a bench supply and not a battery at the moment so I understand that inrush is significantly limited in comparison. I will try it with a battery at some point. With the 10n I would never see the BATFETs fail when turning the charger on- it was always on turn off. At that point the system was in the BOOST stage, but it was a delta of 2-3V.

The ACDRV signal may have been related to the damaged 10 ohm resistors you pointed out across the VAC sense resistor. You probably have better insight into if that makes any sense- there's pretty limited information in how that works in the datasheet. I have not looked at it again since I swapped those resistors, but at this point I have a workaround for the ACFETs by detecting an input voltage separately and turning the ACFETs on.

Hello Kris,

For the EV2400 and the USB2ANY, I've never seen an EV2400 or USB2ANY not work like that. You've probably already checked this, but did you make sure to plug in the EV2400 before starting BQStudio?

Thanks for the information about the BATFETs. Make sure to make the gate capacitor bigger than it needs too. You probably already know this, but the threshold voltage of a FET will change over temperature.

Thanks for letting me know about the ACFETs.

Best Regards,
Ethan Galloway

Ethan,

Some additional information. We have one board that reliably works, but subsequent boards built with what we are pretty confident are the same changes are failing.

I added a 20 ohm NTC in rush current thermistor in series with the battery on those boards and put a current probe on the line that didn't trigger when set to 5 A. The same BATFET still failed on charger turn off (note the battery wasn't actually charging because of the series resistor size, but VAC was running the system successfully). I'm working on getting scope captures, but I believe this is a BATDRV gate damage issue and not an inrush current issue.

We are seeing a 30V spike on BATDRV referenced to BATSRC when the charger turns off which exceeds the Vgs max rating of the MOSFETs. This spike is also there when the battery is first connected to a dead system, but it is not as significant. There are a few scope captures which are all interesting in their own way.

This capture is BATDRV referenced to BATSRC when the battery is first connected to an unpowered system.

This is a zoomed in image of the same capture to show the spike timing of roughly 6.8 ms. Something clearly kicks into overdrive in the chip at this time as the slope of the gate rise dramatically changes for a moment.

This is a capture of the of BATDRV referenced to BATSRC when VAC is first powered. I'm not thrilled about what is happening here either, but I don't think this is necessarily what is causing the failure, although it certainly is not doing anything good.

Here is a zoom in on the gate oscillations from the previous capture from VAC power-up

This is a capture from the charger turns off, and where I believe that the failure is happening. Note the vertical scale has changed to 10V per division. We are seeing an over 30V positive spike at the same 6 ms timeframe from when BATDRV starts to a large voltage spike on the gate.

Zoomed in measurement from previous capture

This is what is on the gate after damage when the charger turns back on:

What is happening in BATDRV 6-7 ms after switching on that is causing this huge voltage spike? This looks like a silicon issue.

I am attempting to add a zener from BATSRC to BATDRV to limit the spike and go from there.

This is not a 6-7ms issue. It appears to be a 2.5V threshold issue when the spike happens. We removed the 100n capacitor from gate to source and replaced it with a zener diode, the same as used on the ACFET. The battery FETs have survived all of the cycling so far. We will remove the inrush current limiter and confirm that the issue does not reappear.

I took some higher resolution captures of the BATFET gate when the spike happens. This capture is showing a 47.8 MHz oscillation on the gate:

Here is a capture zoomed out a little further to see how significant this oscillation is- even with the 15V zener we are getting spikes that are +/- 25V and would clearly damage the FETs with a +/- 20V absolute max Vgs.

We are going to play with the series resistor and potentially go to a lower voltage zener to try to start absorbing the spikes a little sooner. I'm welcome to any other thoughts, but at least in our design, this seems to confirm the issue and resolution. It definitely appears to be a silicon issue of a circuit that activates around 2.5V internally.

Confirming that after removing the NTC inrush limiter that we did not experience any failures on the BATFET. We are planning to replace the zener with a TVS to better absorb the transients. I would like some input on TI for what they think the cause of this might be just to make sure it isn't a layout issue.

Thanks

Hello Chris,

Thanks for the information.

I'm curious about the BATDRV voltage spike. I've never seen anything like it before. How are you measuring the BATDRV voltage? I normally measure BATDRV to BATSRC with a TMD0200 diff probe.

Also in your board, the BATFETs connect directly from VBAT and VSYS right? To help us debug this, can you send me an updated schematic and layout?

If possible, could you send me a wider time scale with BATDRV-SRC, VSYS, VBAT, and IBAT?

I've attached an image of what I normally see in these measurements on the EVM. In this image, R9=10ohm and the BATFET capacitor is 10nF. VOUT=VBAT. I_RBAT is the current across the sense resistor:

The massive spike in current is the battery being plugged in and charging all the VBAT capacitors rapidly. The massive spike in current is not a problem for the BQ25750. SYS slowly comes up from DRV-SRC turning ON and OFF.

Best Regards,
Ethan Galloway

Ethan, 

Sure, I will send the schematic and layout over for review sometime this weekend. 

I do not have a differential probe so the scope captures are using an Agilent N2862B with the ground clip on BATSRC and the probe on the gate. Those probes use common ground which is why I haven't simultaneously added any other signals in. I could do the capture showing BATDRV to GND and include the additional signals, but I realize this isn't as good. 

These boards do have the audible click after turning the charger off. I wouldn't be surprised if that click was associated with the voltage spike we're seeing on the gate. I do not think it's just coupled onto the probe since the zener seems to be protecting the fet.

I do have some layout ideas for improving the routing. This gate signal is changing layers and running in the vicinity of the buck boost, but that spike is pretty substantial to just be that. I can try an external wire potentially.

Hello Kris,

Thanks for the details about the measurement.

I think grounding BATSRC may have unintended effects. I would recommend measuring BATDRV with respect to GND. Does the measurement change if you do this?

By the way, an alternative to using a differential probe is use the oscilloscope math function to subtract BATSRC from BATDRV.

Best Regards,
Ethan Galloway

Sure, I will give that a try. It will be a few days because we need to build out another board for capture.

Ethan,

A few updates here. We built out another board, and scoping BATDRIV to ground as suggested (instead of referenced to BATSRC with the single ended probe) did show a spike over at least 85V on BATDRV. I attempted to get a better capture of this but the IC was damaged afterwards so I do not have a capture. This was using a bidirectional TVS across BATSRC to BATDRV instead of a zener which previously protected the system.

After this, we repaired one of the EVMs previously mentioned. All of the MOSFETs and 10 ohm resistors tested fine- it was just the IC which needed replacing. We set the charge current to just over 1A and set the feedback resistors appropriately. We wired a 5 Ohm NTC thermistor in series with the battery externally (https://www.digikey.com/en/products/detail/ametherm/MS32-5R020/749861?s=N4IgTCBcDaILIGUDMYCsAlADGTIC6AvkA). I connected the battery first and inspected the board with a thermal camera with no noticeable heat signature. VSYS = VBAT as expected. I turned the charger on and the power supply showed a little over 1 A at 48V input. Upon turning the charger off, the EVM was damaged and did not operate. Interestingly, it only seems to be the IC which needs to be replacing again. I attempted to get a BATDRV scope capture, but it was unsuccessful and the EVM only worked for one attempt.

Do you believe that a 5 Ohm inrush current limiter is large enough to conclude that the EVM is not being damaged by inrush current?

I suspect that the BATDRV signal is exceeding the absolute max rating of 85V and the IC is damaging itself. 

If I send you one of our batteries, would you be able to test this with a EVM? I am getting concerned about if this charger is feasible for a 48V design.

Thanks for all of the help.

Kris

Hello Kris,

Thanks for working with this. That's a really good question on how BATDRV spiked to 85V. TVS diodes are normally faster than zener diodes as well. Just to make sure, you used the SMAJ11CA/TR7 and the AONS66917 for the TVS diode and BATFETs right?

For the EVM, I have a few questions. What FETs were used for the BATFETs? Was the BATFET RC changed? Afterwards, were R22 and R25 (the 10Ω resistors) damaged again?

Kris Parrent said:

Do you believe that a 5 Ohm inrush current limiter is large enough to conclude that the EVM is not being damaged by inrush current?

The EVM is still being damaged by the inrush current here. The inrush is not from the battery plug-in, but the inrush comes from the BATFET turn-on. Let me know if this clarifies the situation for you.

Kris Parrent said:

If I send you one of our batteries, would you be able to test this with a EVM? I am getting concerned about if this charger is feasible for a 48V design.

I don't know if this will help. My current test setup is a KEPCO BOP100-10M in parallel with a 30,000µF capacitor on VBAT. I use a physical switch in series to connect and disconnect VBAT. I tried to setup the worst possible case for a battery hot plug to test the BATFET turn-on.

Best Regards,
Ethan Galloway

Hi Ethan,

Thanks for the reply.

For our board test, I am confirming that we did use the  SMAJ11CA/TR7 and the AONS66917 for the TVS diode and BATFETs. Only the IC was consistently damaged. One time we had to replace the lower BATFET, but the other tested fine. The 10 ohm resistors were never damaged.

For the EVM, it was entirely unmodified other than the external resistors to convert to a 13 cell battery and replacement parts with the exact same parts. Rough numbers from memory, we used approximately 7K on J2 and 40K on J3 and removed other associated jumpers for the feedback and charge limiting. I can get more specific numbers if needed.

Can you explain more about the source of the inrush current? If we have a series NTC inrush limiter in series with the battery, where is the source of the damaging inrush current coming from when the BATFETs turn on? The bulk caps on the battery input line is the only thing which comes to mind, but the major source of current (the battery) still has to pass through the NTC. That is 5 ohms until it heats, and we aren't pulling enough current for it to heat enough to drop much below that. What would be a good method to measure this current if it is not from the battery?

I am considering replacing the BQ25750 with the BQ25756 and making board modifications for testing. We would really like the Power Path control that comes with the BQ25750, but it seems like the complexities added by the ACFETs and BATFETs are going to be a roadblock. We have also damaged our board each time we have tried reverse mode with the BQ25750. It feels like simplifying the scope of the charger may be the cleanest path forward to get a working solution. Do you have any thoughts on making this change?

Thanks,

Kris

Hello Kris,

Thanks for the confirmation and thanks for being patient with this reply.

Kris Parrent said:

Can you explain more about the source of the inrush current?

Here's what I think is happening in your circuit on the EVM: The battery charges the bulk capacitors on VBAT through the NTC. Then the BATFETs turn ON, and the inrush current from the BATFETs turning ON damages either the BATFETs or the IC. If the BATFETs are damaged, it's because their SOA was exceeded. If the IC is damaged, it's because the difference between the SRN and SRP pins exceeds the absolute maximum rating of 0.3V. From my own experiments, I know the SRN/SRP pins can sustain a difference of 0.7V though. The IC has an 8A current limit for the power path switchover, but it is not fast enough when the difference between the battery and the system voltage is large.

Let me know if this makes sense.

Kris Parrent said:

Do you have any thoughts on making this change?

I think may be a good idea especially since we've been debugging this for months by now. I will look into this and see if I can find any part recommendations.

Best Regards,
Ethan Galloway

Ethan,

We received the BQ25756EVM and could not blow it up with the charger switch on/off. We did some surgery on our custom board and placed the BQ25756 and have it seemingly working as well. We haven't done load testing yet which is where our question comes in (let me know if you prefer a new thread for those questions, but hopefully the detail in this thread can be helpful for someone down the line).

The battery sense resistor is measuring system + battery current. I saw some other threads where you discussed that the IC does not know true battery charge current and that sense resistor needs to be between the system and the DC/DC for monitoring inductor current. Understood on that. My question is then in terms of setting the charge limiting resistor and how that interacts with the input current limting.

1) Does the BQ25756 also have an inrush current detection if we are using the input sense resistor? I'm assuming it does not since that can be controlled through the buck/boost instead of just swtiching the ACFETs on.

2) How should the charge current resistor be calculated? Is that now max system current + battery charge current? 

3) What is the relationship between the input current limiting and the battery charge limiting? For simplicity, let's assume Vin = Vout so input and output current are relatively the same power. Let's say our input current limit is 10 A, our system could use 10 A, but we also want to limit our battery charging to up to 8A. Fundamentally, I understand this will likely involve some I2C commands and firmware to manage well, but from a hardware perspective: if our input supply is not limited, then we could potentially damage the input supply. If we hardware limit the input current to 10A and our system draws 11A, then I'm assuming the battery kicks in and load shares the remaining power draw. If our system is only pulling 8A, then I'm assuming the battery should just automatically take the excess up to the input supply limit. Is that accurate? The guidance I'm really looking for here is how to set the appropriate values of the sense resistors for this kind of dynamic scenario without the power path management. It's a little unclear sense the resistor isn't dedicated to the battery current.

Ethan Galloway said:

Here's what I think is happening in your circuit on the EVM: The battery charges the bulk capacitors on VBAT through the NTC. Then the BATFETs turn ON, and the inrush current from the BATFETs turning ON damages either the BATFETs or the IC. If the BATFETs are damaged, it's because their SOA was exceeded. If the IC is damaged, it's because the difference between the SRN and SRP pins exceeds the absolute maximum rating of 0.3V

I guess the true test would be to try what we saw on our board. The zener diode across the BATSRC and BATDRV protected the BATFETs. We never saw a failure using the same zener as the ACFETs. At least on our custom board, that points to that being a gate issue and not an inrush current issue (I think). I can't explain why the TVS didn't do better though. The only difference I can think of is that it was a bidirectional TVS (to absorb the negative Vgs spikes also was the thought).

Hello Kris,

Kris Parrent said:

1) Does the BQ25756 also have an inrush current detection if we are using the input sense resistor? I'm assuming it does not since that can be controlled through the buck/boost instead of just swtiching the ACFETs on.

The BQ25756 does not have the inrush current detection.

Kris Parrent said:

2) How should the charge current resistor be calculated? Is that now max system current + battery charge current? 

That is correct. The current through the resistor will now be the system current + battery charge current.

Kris Parrent said:

3) What is the relationship between the input current limiting and the battery charge limiting?

Your example is correct. The input current limit takes priority over the battery charge current setting. So, if the battery charge current is 10A, but the input current limit is set to 2A and Vin=Vout. The battery will only charge at 2A.

Kris Parrent said:

If we hardware limit the input current to 10A and our system draws 11A, then I'm assuming the battery kicks in and load shares the remaining power draw. If our system is only pulling 8A, then I'm assuming the battery should just automatically take the excess up to the input supply limit. Is that accurate?

Yes, this is accurate.

For your ICHG and ILIM_HIZ settings, I would recommend setting the battery charge current as high as the battery will allow and set the ILIM_HIZ to as much as the input system will allow. This way, the system load will have as much power available as possible when the system load does kick-in.

Kris Parrent said:

I guess the true test would be to try what we saw on our board. The zener diode across the BATSRC and BATDRV protected the BATFETs. We never saw a failure using the same zener as the ACFETs. At least on our custom board, that points to that being a gate issue and not an inrush current issue (I think). I can't explain why the TVS didn't do better though. The only difference I can think of is that it was a bidirectional TVS (to absorb the negative Vgs spikes also was the thought).

I'm not quite sure why the TVS diode didn't work either. What was the clamping voltage set too?

Also, for your custom PCB, the IC shouldn't be damaged from the BATFET turn-on. This is because SRN/SRP shouldn't see the same surge current across them that the EVMs sees.

Best Regards,
Ethan Galloway