BQ35100: Problems with EOS Mode

Part Number: BQ35100
Other Parts Discussed in Thread: BQSTUDIO

Tool/software:

We are using the BQ35100 in EOS mode, and according to the document https://www.ti.com/lit/an/sluaal7/sluaal7.pdf, we are following the procedure:

  1. Wake up the gauge before any major discharge using the GE pin.
  2. Send the GAUGE_START command.
  3. Send the GAUGE_STOP command after the major discharge.
  4. Wait for the G_DONE bit to be set to one.
  5. Read the scaled resistance and measured impedance from the gauge.
  6. Save the scaled resistance and measured impedance to a data memory device.
  7. Put the gauge back to sleep using the GE pin.

However, when checking the resistance and impedance registers, both are zeroed, and we noticed that the AccumulatedCapacity register is changing. Is this correct?

We also observed a delay in the response for the I2C write commands. Is this normal?

  • Hello Gustavo,

    Are you using BQStudio to read data from the gauge?

    Regards,

    Adrian

  • Hello Adrian,

    No I'm using a microcontroller to read the registers.

  • Hello Gustavo,

    Please ensure that the communication is correct. I would recommend using BQStudio to verify that registers are being read correctly.

    Regards,

    Adrian

  • Unfortunately, we do not have the mentioned tool. This is a product of which we have already assembled over 1000 units, all of which have been tested. We are currently working with Texas Instruments to clarify this issue and move forward with the BQ35100 solution for the upcoming batch of 150k units. If we are unable to resolve this, we will consider other alternatives.

    It’s important to note that we have other devices on the same communication bus that are working perfectly, so we believe the issue is not with the BQ35100 reading.

    Attached is the schematic of the GAUGE circuit.




  • Hello Gustavo,

    Can you send me the srec file that was used to program the devices. Are you seeing this behavior on all the units tested or only a few?

    Regards,

    Adrian

  • How can I extract this SREC file?

  • Hello Gustavo,

    How were the units programmed in production? Was the srec file used or was it another file like the bq.fs?

    Regards,

    Adrian

  • Hello,

    The registers of the BQ35100 chip were configured directly via I2C using a microcontroller. We did not use any of the SREC or BQ.FS files for this task.

    If you need more information or details, please let me know.

  • Hello Gustavo,

    Can you share with me the code the microcontroller used to configure the device. I want to ensure that the gauge was configured properly.

    Regards,

    Adrian

  • We are using ZephyrRTOS in this project.

    Would it be possible for you to check if all the k_sleep times are being respected? These are the times between the write command and a response command.

    The code is attached. If you have any questions, feel free to ask!

    bq35100.zip

  • Hello Gustavo,

    Thank you for sending over the files. Please allow me some time to review them.

    Regards,

    Adrian

  • Hello Gustavo,

    Thank you for your patience, it is hard to do a code review when I can't run the code on the same microcontroller you are using in the application. There does not seem to be any functional issue with the functions as long as it has been proved before to work with writes and reads to the gauge. The only issue I can see just from reviewing the code is in the bq35100_init() function (I assume this is the first function that is called when first using the gauge), the NEW_BATTERY command should be sent when first initializing the gauge (I see a function call that does this was commented out). Also, I see that you call the function bq35100_gauge_start() at the end of the init function to send the GAUGE_START command. The GAUGE_START command should not be sent during initialization, it should be sent before a major discharge.

    Regards,

    Adrian