BQ78350-R1: Reading information form the Manufacturer Data register (command 0x23)

Hi Maciek,

Are you getting invalid values in BQ Studio or with a microcontroller?

BQ Studio periodically polls the BQ78350 to get information from the gauge. When you use the GUI, the timing of the commands can interfere with the results obtained (which might explain the odd results). If you have the Scan option enabled (on the Registers tab), the problem will be even worse.

If it happens with a microcontroller, a logic analyzer trace would help us decipher what is going on.

Regards,
Michel

Hi Michel,

Thank you for the quick response. The problem was discovered by the customer using the microcontroller in their device. We only use bqStudio to program and talk to the battery during our testing, so we didn't realize there was an issue reading the register. We were able to get it to work after sending the 23 command and not reading the Data Memory after opening bqStudio. As soon as data memory is read, the fuel gauge will not report the correct info.

I think we can work around this by verifying the manufacturer data at the very end of our test process, but I want to make sure that the default function of reading command 23 is to return the data programmed into the manufacturer info register, and that normal operation (outside of bqStudio) does not change this mode.

Thank you,

Maciek

 

Below is a series of steps (from our customer) that reproduce and then "fix" the problem.

- Take the battery with correct MNF Data, insert into test cradle, and open bqS software.
- From the tab Advanced Comm SMB read block from address 0x23 – it will be 16-byte string.
- Unplug the battery.
- Insert battery into customer device and initialize comms.
- Incorrect MNF Data returned.

- Unplug the battery and insert back into test cradle with bqS software is still running.
- Read from address 0x23.
- it will read correct data.
- unplug the battery and read from device, MNF data will be correct.

- Plug the battery back into bqS test cradle and open Data Memory tab (or do Read All if tab is already opened).
- Read data from address 0x23.
- it will return 32 bytes all FF.
- Unplug the battery and read with device, data will be incorrect.

- Plug the battery back to bqS test cradle and read address 0x23
- it will return correct data.
- customer device will now also read correct MNF Data.
- Batteries will stay in correct “mode” and will return correct MNF Data if not accessed by bqS.

We verified the behavior above (bqStudio only), and it is very consistent in the data strings that are being reported when reading the Manufacturer Data register. So it still looks to me as if bqStudio is changing the "mode" of the fuel gauge to report one of the other data sets in that register.

Sample of incorrect string form 0x23: 0B 10 00 00 89 0B 00 00 00 00 89 0B 00 00 82 0B
Sample of incorrect string form 0x23: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
Sample of correct string from 0x23: 6E 5D C8 20 FF 43 58 27 2C 01 00 00 01 1E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Michel,

So it seems to me like the fuel gauge is defaulting to outputting calibration information every time it is scanned by bqStudio. However the CAL flag in Manufacturing Status does not turn ON at any point. If I understand the Tech Ref correctly, the FG should only return cal data while that flag is ON.
I also just found that sending command 0xF080 (exit cal output mode) to Manufacturer Access results in 0x23 returning the correct data, but again the CAL flag is supposed to be on before this command.

Maciek,
Have you looked at the Manfucture Access (0x44) with register 0x0057 ManufacturingStatus?
It seems to show the Calibration mode.

Yes, that is what I meant in the last comment, the Manufacturing status does not indicate calibration mode, but 0x23 still returns the cal info if I read data with bqStudio beforehand.