• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 63 subscribers
  • Views 792 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

CCS/BQ34Z100-G1: CCS/BQ34Z100-G1:

CCS/BQ34Z100-G1: i2c lines low for seconds? (minutes?)

Thaddaeus Kroenert
Prodigy 70 points
Part Number: BQ34Z100-G1
Other Parts Discussed in Thread: EV2400, BQSTUDIO, BQ34Z100

Tool/software: Code Composer Studio

Hi TexasInstruments- Power-Team,

Our system receives no valid data from the bq34z100-g1 for up to 7 minutes.

For us, 'non valid data' means NAK, I2C bus busy or wrong data (e.g. SOC >100).
Our system is single master. Polling 8 registers every second. Delay between the read operations is >25msec.
At the moment 6 out of 8 new batteries show these anomalies after 4 - 20 days of continuous use (99% of the time only i2c communication. 2 ampere load for 5s per day).
 

In my lab I managed to capture a bus stall of 0.8 seconds (see picture below). At (1) DATA goes low (2) Our software tries to send STOP to reset the i2c-bus (3) the battery releases the DATA line (4) communication reestablished.

  1. Is there a state in which the bq34z100-g1 keeps the i2c data/clock low for longer than 20ms? If so, what is the maximum time for this?
  2. I read in the datasheet that an autocalibration is performed when going into SLEEP mode. [ DATASHEET: http://www.ti.com/lit/ds/symlink/bq34z100-g1.pdf
    1. How long does it take?
    2. What is the value of BUS LOW TIME (Datasheet p.36)

I am fully aware that our software also plays a part in this. But in our software, there's no reason for a 7 minute break - I hope there's something for that in the bq34z100-g1.

  • 0
    Prodigy 70 points

    This has nothing to do with "code Composer studio"!  I have searched the forum and clicked there unknownly on "New Thread".

  • 0 in reply to Thaddaeus Kroenert
    TI__Guru 61006 points

    There are two Bus Low times:

    2 seconds for an I2C timeout (this resets the I2C HW engine directly - if both SCL and SDA are forced low by the master)

    5 seconds for the auto-cal trigger

    There may be a watchdog issue with your fairly high rate of polling. Is there a reason why you need to poll 8 parameters per second? Gauging results won't change that quickly so this seems excessive. Under some circumstances (e.g. long discharge simulation), there's a potential for a WDT reset that could trip up your system.

    You can check this in subclass 56 (Manufacturer Data), offset 13. This tells you how often the WDT reset was triggered. I recommend reducing the number of parameters you poll each second (2 max).

  • 0 in reply to Dominik Hartl11
    Prodigy 70 points

    Hi Dominik,

    Thank you for your advice. We will slow down our bus communication to 2 reads per second.
    more details here:  https://e2e.ti.com/support/power-management/f/196/p/762327/2822655?tisearch=e2e-quicksearch&keymatch=BQ34Z100%20watchdog%232822655


    But there must be something else:
    1. in the past we have done tests with the same 8 systems over 6 weeks without a single error
    2. we restarted the devices 1 week ago and don't have a single error yet !?

    Our thesis is: Only new "fresh" batteries are affected!

     I digged deeper and found a very interesting part in the battery pack manufacturing process.
    Every battery pack is:

    1. UNSEAL (for reworked parts)
    2. write DF / parameters
    3. RESET
    4. UNSEAL2
    5. IT Enable
    6. SEAL

    Then disconnected from an EV2400, the battery packs lay in ESD trays for a week and were installed in our device, where they showed the behavior described in the first post.

    My questions here are:

    1. Is it reasonable to click on "IT Enable" in bqStudio without performing a controlled learning cycle?
    2. Any idea how this could lead to low i2c lines?

  • 0 in reply to Thaddaeus Kroenert
    Prodigy 70 points

    Thaddaeus Kroenert said:

    Hi Dominik,

    Thank you for your advice. We will slow down our bus communication to 2 reads per second.
    more details here:  https://e2e.ti.com/support/power-management/f/196/p/762327/2822655?tisearch=e2e-quicksearch&keymatch=BQ34Z100%20watchdog%232822655


    But there must be something else:
    1. in the past we have done tests with the same 8 systems over 6 weeks without a single error
    2. we restarted the devices 1 week ago and don't have a single error yet !?

    Our thesis is: Only new "fresh" batteries are affected!

     I digged deeper and found a very interesting part in the battery pack manufacturing process.
    Every battery pack is:

    1. UNSEAL (for reworked parts)
    2. write DF / parameters
    3. RESET
    4. UNSEAL2
    5. IT Enable
    6. SEAL

    Then disconnected from an EV2400, the battery packs lay in ESD trays for a week and were installed in our device, where they showed the behavior described in the first post.

    My questions here are:

    1. Is it reasonable to click on "IT Enable" in bqStudio without performing a controlled learning cycle?
    2. Any idea how this could lead to low i2c lines?

    an additional question came to my mind:

    3. It seems like the bq34z100 pulls the bus low in the middle of the communication (1)  even if the bq34z100 is not responsible for the ACK/NAK. Is this behavior explainable?

  • 0 in reply to Thaddaeus Kroenert
    TI__Guru 61006 points

    IT Enable just tells the gauge to start its algorithm.

    If it is note enabled, you'll likely never see a WDT reset (if that is what indeed happens in your system) as the gauge won't run any remcap simulations. Note that this is sticky, so once you issue this command, it will always be enabled (unless you clear the flag in flash).

    About I2C low: The gauge will clock-stretch under various circumstances (e.g. I2C traffic when the gauge is sleeping because it needs to spool up its internal clocks from a low power state to be able to handle the incoming I2C bitstream). I don't have an explanation why you see SDA pulled low while SCL is not. Are you sure it's the gauge that pulls SDA low?