Because of the holidays, TI E2E™ design support forum responses will be delayed from Dec. 25 through Jan. 2. Thank you for your patience.

  • State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 2 answers
  • Subscribers 64 subscribers
  • Views 890 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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-G1: I2C communication issue, SCL line driven low for about 4.5[ms] randomly

F. Baumgartner
Prodigy 30 points
Part Number: BQ34Z100-G1
Other Parts Discussed in Thread: BQ34Z100, BQSTUDIO

Support Path: /Product/Development and troubleshooting/

Hello, 

We're using a BQ34Z100-G1, and simply reading the following registers every 100[ms] through I2C

- register 0x02: SOC + ME

- register 0x10: I

- register 0x0C: TEMP

- register 0x08: VOLT

- register 0x06: FCC

Randomely (about every 10s), the device drives the SCL line low during ~4.5[ms] when issuing the first start condition.

I can't see any explanation for that behavior. Is it normal? Can the bq34z100 be "busy" for such duration?

I2C configuration:

- 100kHz

- 10kohm pull-up

- no other node on I2C bus except the STM32 driving the bus as master, and the bq34z100.

Thanks

  • 0
    TI__Mastermind 25955 points

    Hi F. Baumgartner,

    The gauge can take up to 25 ms when writing values to data flash.

    If you believe this clock stretching is in error:


    Could you please send me logic analyzer output of this event occurring? Please also include the commands that precede and succeed the clock stretching event.

    When running the logic analyzer, please also send some example shots on the scope aligned with the logic analyzer data so the analog effects may be explored as well.

    If this event is random and not tied to a specific command sequence, please send several examples.

    Also, to aid in event reproduction and diagnosis, please send your gg.csv file and a log with the highlighted lines that correspond the logic analyzer shots above.

    Sincerely,
    Bryan Kahler

  • 0 in reply to Bryan Kahler
    Prodigy 30 points

    Thank you Bryan. 

    Below a zip file including requested samples.

    Thanks, 

    InfosForTI201801230802.zip

  • 0 in reply to F. Baumgartner
    Prodigy 30 points
    Hello,

    any news about this issue?
  • 0 in reply to F. Baumgartner
    TI__Mastermind 25955 points

    Hi F. Baumgartner,

    Thank you for the detailed scope shots - communication looks good (other than the clock stretching).

    After some testing in the lab, I have a quick procedure for you to run through to aid in ruling out data flash writes:

    As a test, on an EVM (non production board), please set the device into single cell mode (default gg may be used, set jumpers and VOLTSEL).  Verify that the clock stretching is still seen.

    Power the board with 3.8 V.  Next, modify the Flash Update OK Cell Volt to 4000 mV.  In bqStudio, please click 'Read All' to ensure the value was set.  After confirming that the value was set properly, try to modify another value in dataflash and click 'Read All' once more, but instead verify that the value was NOT set.  After confirming that the value was not set, please rerun your tests to determine if the device is still clock stretching.

    If the clock stretching has disappeared or been reduced, this will confirm that the clock stretching was in fact due to the device writing to dataflash.

    After the test, please increase the voltage to the device to 4200 mV and set your Flash Update OK Cell Volt back to your previous value.

    Please let me know how these tests turn out - If the clock stretching continues to exist and DF writes cannot be ruled out, please also send me a log file and I will attempt to replicate in the lab.

    Sincerely,
    Bryan Kahler