This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

BQ34Z100 strange behavior when reading registers

Other Parts Discussed in Thread: BQ34Z100


I'm trying to read some data from a battery pack we get already assembled and configured from a supplier.
I know it's a BQ34Z100 inside and amongst others I read the SOC/SOH-Registers from adr 0x02/0x03 and 0x2e/0x2f. Correspondig to the datasheet I could read values from 0 to 100 % like expected. But sometimes the return value equals to 0xFFAB, reading as 65451 unsigned or -85 signed. To exclude a bug in the software, I measured directly on the I²C-lines with a scope and found the same response. Other registers like voltage (0x08/0x09) and current (0x0a/0x0b) are not affected by this behavior.

As this is reproduceable and not described in the datasheet, I'd like to know if this could be an error code from the gas gauge and if so, what does it mean?

Regards Kai




  • Kal,

    I have not heard about an issue with reading a specific command, but I will try it. Can you clarify how you are reading the SOC and SOH and at what rate? Maybe I can reproduce it and find a solution.

    Thanks

    Tom

  • Tom,
    the following part of code is called periodically in a 10ms cycle (at a bus speed of 100khz).


    void Batt_vReadAccuParameter (void) { uint u8TrialCounter; static const sBattReadStruct_t aReadAccuTabS[] = { {0x02, &sBattery_IOsS.u16StateOfCharge}, {0x04, &sBattery_IOsS.u16RemainingCapacity}, {0x06, &sBattery_IOsS.u16FullChargeCapacitiy}, {0x08, &sBattery_IOsS.u16Voltage}, {0x0a, &sBattery_IOsS.u16Current}, {0x0c, &sBattery_IOsS.u16Temperature}, {0x0e, &sBattery_IOsS.u16Flags}, {0x18, &sBattery_IOsS.u16TimeToEmpty}, {0x1a, &sBattery_IOsS.u16TimeToFull}, {0x2e, &sBattery_IOsS.u16StateOfHealth}, }; if (sBattery_IOsS.u16ActualState < numberof (aReadAccuTabS)) { for(u8TrialCounter=5; u8TrialCounter>0; --u8TrialCounter) { if (Batt_pReadI2CWord (BATT_ADDRESS, aReadAccuTabS[sBattery_IOsS.u16ActualState].RegisterAddress, aReadAccuTabS[sBattery_IOsS.u16ActualState].BufferAddress)) { sBattery_IOsS.u16ActualState++; sBattery_IOsS.bError = FALSE; break; } else { memset (&sBattery_IOsS, 0, sizeof (sBattery_IOsS)); // in case of error discard all entries sBattery_IOsS.bError = TRUE; // and signal it sBattery_IOsS.bDataValid = FALSE; } } } else { sBattery_IOsS.u16ActualState = 0; sBattery_IOsS.bDataValid = TRUE; // used for syncronizing } }


    So every variable is handled about ten times a second.


    Regards Kai

  • Hello, Tom,

    anything new about this?

    Could these values perhaps show an error code or an internal state or something like this? And what would it mean?

    Kai

  • Kai,

    The guidance that I was able to find is to only read a parameter no more than one or two times per second. The parameters are only updated one time per second, so faster will not help. Also, allow at least 66 us dead time between the STOP bit and START bit. I have not been able to reproduce the problem that you reported.

    Tom

  • Good Morning Tom,

    thanks for the reply. We'll try this later this day and report, if this helped.

    Kai