BQ40Z50: BQ40Z50-R3 issues waking up from Autoship mode

December 3rd 2020.

Update by the customer. Battery behaviour tests performed December 3rd 2020.

Of the 9 batteries that have been configured with AutoShip disabled to prevent the BQ40Z50-R3 gauge chips from transitioning to SHUTDOWN mode, all of these batteries work. These 9 include the 5 batteries that would not wake up and were power-cycle reset (by de-soldering the cell pack positive wire and then re-soldering) to get them working again.

Of the remaining 17 batteries that still have Autoship enabled, six have now failed to wake. They were last checked November 27th.

In total, out of 22 batteries that have Autoship enabled, 11 different batteries have now failed to wake out of SHUTDOWN mode.

Hello Wyatt, 

They want to be able to use Autoship mode. But it doesn't work on all packs for some reason as you can see in the thread. And as you also can see form the discussion, some of these fails to wake up, which is what we try to resolve.

Best regards

Jorgen

Hi Wyatt, 

Comments from the customer:

If the gauge has never entered shutdown mode then the external circuitry used will not be needed to wake the gauges from shutdown.

This completely misses the point. I wanted to be able to take advantage of the SHUTDOWN mode to increase storage time but also to allow the user to just plug the battery in and go. My additional circuitry is a way to wake up a gauge from SHUTDOWN mode without having to press a button (not possible in our application) or plugging into a charger. If I had wanted a battery that either stayed out of SHUTDOWN mode or required the user to plug the battery into a charger before using it, assuming that is the user remembered to do that, THEN I WOULD HAVE DESIGNED THE BOARD TO DO THAT! Instead, I have designed circuitry which results in a much more user friendly battery that behaves like a battery should, ie. plug it in and it works!

The reason why I am performing tests that keep the gauge from entering SHUTDOWN mode is to try and prove that the problem is when the gauge is in SHUTDOWN mode. Not allowing the gauge to go into SHUTDOWN is a possible work round to the gauge not behaving as documented by TI. Believe it or not, part of this is to try and help TI work out why their gauge is behaving like this. It is not yet proven that preventing the gauge from going into SHUTDOWN will keep the gauge from going unresponsive. At the moment, I have had no unresponsive batteries when configured this way but the tests haven’t run for long enough to be conclusive.

If they need a quick fix to the issue they can disable shutdown mode and remain in sleep, the current consumption may be higher in this mode.

I know that. If indeed keeping a gauge from going into SHUTDOWN does prevent batteries from going unresponsive then this may have to be a work around until TI explain why their gauge is behaving this way and provide a fix. Yes I know that the current is at least 32 times greater when not in SHUTDOWN mode.

I believe there was also a test performed with the EVM, was it able to wake from shutdown mode? We need a baseline of testing to confirm the origin.

Read the emails! Also what do you mean by “We need a baseline of testing to confirm the origin.”   It sounds like a meaningless statement. I have 25 batteries with my battery management PCB and ONE battery with the EVM connected. The EVM has only been connected for less than two weeks whereas my batteries have been connected up for between 1 and 3 months. The EVM is configured to allow it to go into SHUTDOWN and to date it has come out of SHUTDOWN when the WAKE button is pressed. Most of the time, my batteries will come out of SHUTDOWN but sometimes they don’t. When they don’t, I then perform a power cycle recovery and configure them to disable going into SHUTDOWN (see the first point above). To summarise, I have a sample size of ONE battery with the EVM and a sample size of 25 batteries with my PCB.

The bq40z50 EVM has always been able to wake up from shutdown when the Vstartup is applied to PACK from me testing.

The timeframe for testing with a sample of one could be many months, especially if the problem is of a statistical nature. The length of time the gauge remains in SHUTDOWN might be a factor also so performing repeated shutdown and wake up tests in quick succession might also not show the problem. All that I can say is that when a gauge on my PCB refuses to wake up, no amount of applying Vstartup or greater to the PACK+ pin will wake it up. The gauge has to be power cycled to wake it up.

Circuit schematics of my PCB and PCB layout information has been provided to TI to review and as I understand it, these have been reviewed.

Best regards

Jorgen

I note that TI thinks this case is resolved. It most definitely IS NOT resolved!

Hi Ian,

Can you attach the schematics.

Best regards,

Hi Nick, 

I have attached the schematics.

Br

JorgenCircuitDiagram.PDF

Hi Ian,

The finding that this cannot be replicated on the evm is concerning. 

it’s best to follow the EVM schematic closely. 

best regards,

Hi Nick,

If you look at my schematic compared to the EVM, you will find it does follow the EVM schematic very closely. The only difference is that I have replaced the EVM's manual push-button "Wake" switch with a FET which is activated when the pack is plugged-in so pulling SYS Pres to ground. This means that the pack will wake-up from shut down mode when it is plugged-into the load device and become live just like a battery is expected to.

I also don't use the display LEDs on my design so there is nothing connected to the 3 LEDCNTL pins on my design.

Other TI engineers have reviewed my schematic and PCB layout and have not raised any concerns.

Having recently (yesterday) got a pack that won't come out of shut down mode and thus refuses to deliver current, communicate, or be charged, I have been able to provide the asked-for voltages at the PBI; VCC and BAT pins when the gauge fails to come out of shut down mode. As of yet, I have had no response to the information provided, other than your post yesterday which makes no reference to this information.

So, since I raised this case, TI are no further to providing an answer as to the cause. I do know that out of my batch of 25 packs, about half of the packs have exhibited the fault at least once while the other half have never exihbited the fault.

I suspect TI are in denial that the problem might down to the gauge. TI engineers have not stated what they have done themselves to further investigate the cause. For example, have TI tried to repeat the tests on a decent sample size of EVM boards? Have they tried to replace the wake button with a FET driven off the Sys Pres input?

I am currently having to configure packs not to go into shut down mode by disabling auto ship. This results in increased battery drain and results in shorter storage life between charges and/or batteries that discharge so much as to become unusable, and reduced capacity if not topped-up before use. Not ideal and not what the documentation says the gauge is capable of doing.

Hello Ian,

As mentioned in previous communication, we haven't seen this error before with any of the EVMs or any other applications using the bq40z50. The issue is most likely stemming from the custom hardware you have to wake the gauge up.

I would like to continue to support as much as possible as I am curious what is causing the gauge not to wake up with your circuitry, but it is hard to pinpoint issues without the specific pack to test on and without lab access to debug all issues.

Sincerely,

Wyatt Keller

Hello Wyatt,

I could arrange to let you have one of the PCBs that has exhibited this fault but your recent post hints that you won't have lab access to debug all issues. If that is the case, there isn't much point providing a PCB.

If you are able to do a proper test run on this PCB, in addition to having to connect it to a 4S battery pack and thermistors, you will probably have to have lab access for at least a month and periodically check the battery during that time for fault occurrence.

As no-one has commented on the measured voltages I recently provided, I can only assume it has neither confirmed or disproved any hypothesis you or others at TI might have formulated. It is quite disappointing that TI would not provide any explanation for the reason for that particular test.

I'm still willing to perform additional tests on the most recent PCB to have experienced this fault so long as they are reasonably easy to set-up and do.

Sincerely,

Ian

Hi Nick  and Wyatt,

Further update on your EVM schematic comment and my response to that.

After getting a battery that entered the "fail to come out of shutdown mode" and taking the voltage measurements you asked for, I decided to make the PCB be as close to the EVM design as possible by removing two diodes, namely D2 and D3 and let the battery enter shutdown via the autoship time out. Prior to that I tested that the battery could be commanded, via BQStudio, to enter shutdown mode and could be brought out of shutdown by momentarily shorting the J2 pads which is the same as pressing the wake button on the EVM. I repeated this a few times and then left the battery to autoship shutdown. To all intents and purposes, the PCB is now the same as the EVM.

This morning, before removing the PCB from the battery in order to send to yourselves to allow TI to further investigate, I checked to see if the battery would come out of shutdown. IT WOULD NOT! That fact is a key piece of evidence that strongly suggests that my small amount of additional circuitry is not the cause of the gauge not coming out of shutdown mode.

I shall now remove this PCB and get it shipped to your Dallas facility as requested and agreed. I was going to refit the two diodes but I in light of the above evidence I now won't.

My reply to the above has ended up in the other forum related question with the same title.

Hello Ian,

Thanks for sending in the PCB, either Nick or I will take a look and hopefully find the root cause.

Sincerely,

Wyatt Keller