BQ25887: Sometimes the A/D readings no longer update what is the reason

I forgot to mention -

- If we power cycle the BQ25887 with the device to charge removed, the problem goes away.

- If we power cycle the BQ25887 with the device to charge still in place, the problem persists.

Maybe that will help figure out what is going on.

Ideally, we will be able to fix this problem without having to power cycle the BQ25887.  

Thank you.

More information.  Here is the schematic on the BQ25887 circuit on our PCB.  The control lines (SDA ... STAT) on the lower left go to a micro.  The BAT and MID lines on the right go to a connector that our device to be charged can slide in and out of.

ALSO.  . .  I had a system in the "bad A/D reading" state and I shorted "CD" to ground while the system was running.  The A/D values immediately started working again.  Maybe the answer is to just keep CD low.  However, that seems to not conform to the datasheet then:

Hi David,

This is an odd issue.  If you toggle the ADC enable on and off or if you can change from one shot to continuous, does that fix the issue?   Also, how fast is your I2C bus trying to read the ADC?  Are you waiting for the ADC done bit (assuming continuous read)?  If you toggle EN_HiZ bit instead of using CD pin, does that fix the issue as well?

I will try to recreate in the lab but with such a low failure rate, it may be difficult.  Can you summarize the steps, in the exact order (disable charge, remove battery, reattach battery, read ADC, etc.) including battery voltage(s), when this occurs? 

Regards,

Jeff

Paul - 

Thanks for your response.  Answers below.

If you toggle the ADC enable on and off  . . . . <SNIP> . . . . If you toggle EN_HiZ bit instead of using CD pin, does that fix the issue as well?

Unfortunately, I have not been able to recreate the issue when I had an emulator running with the micro controlling the BQ25887.  If I am able to recreate it with an emulator running I will try both of these.

or if you can change from one shot to continuous, does that fix the issue?   

I have not tried this, but it seems unlikely - I am running in continuous mode.  As the previously attached spreadsheet shows, the ADC control register is set to 0xB0 which has bit 6 low which is a continuous conversion.

Also, how fast is your I2C bus trying to read the ADC? 

Once every 50ms with a 200kHz clock rate

Are you waiting for the ADC done bit (assuming continuous read)?  

No.  However, I would assume a 50ms sample rate would give enough time for the ADC conversions.  I can't find a conversion rate time in the datasheet - maybe I am missing it.

In addition, the datasheet mentions an ADC_DONE_FLAG bit, but states it does not work in Continuous mode, and for the bq25887 that bit does not appear to be defined in the register set

I will try to recreate in the lab but with such a low failure rate, it may be difficult. 

Exactly.  It is pretty frustrating.

Can you summarize the steps, in the exact order (disable charge, remove battery, reattach battery, read ADC, etc.) including battery voltage(s), when this occurs? 

The steps are:

- Charge Enabled

- Pull a devices from a running/charging bq25887

- Micro sees a device is gone and disables the bq25887 by setting Control_Register2.EN_CHG low AND setting the hardware I/O CD high.

- Some very small percentage of the time the bq25887 "locks up" and the A/Ds no longer reads/updates the ADC of the battery inputs.

I understand that I don't have a full detailed list there - however, I have only been able to recreate it twice in the lab - so I don't have a good, methodical way to do this.  I had hoped it was an obvious, "oh we have seen this before, you are doing XYZ."  Unfortunately, that does not appear to be the case.

It SEEMS like the answer is in this part of the datasheet, but I can't figure out why it is applying to our systems . . . 

FURTHER INFO

Here is one more piece of information that may help.  When a device is seen as absent, as a test I shorted CD to ground and the A/D started to work.  So I modified the FW so that when disabling the charger, instead of setting CD high, I left it low (thereby only turning the charger off with the EN_CHG bit).  Since then, I have not been able to recreate the problem and have done 1000s of the process I detailed above.  Unfortunately, I am running into the "absence of evidence is not evidence of absence" problem - I don't have a definitive cause so I don't have a definitive solution.  

Thanks for your help.