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.

BQ25620: I2C clock stretching, and minimum time between subsequent START commands

Part Number: BQ25620

Tool/software:

Hi all,

Q1: Does this device do I2C clock stretching?
Datasheet section "8.5.1.3 Byte Format" mentions clock stretching in a general way, but it is unclear whether the device actually makes use of it.

Section "8.5.1. Serial Interface" says:
"Due to the ultra low IQ when the device operates in low power mode, it is necessary ensure a minimum of 90μs between a START command and any subsequent START command on the I2C bus."

Q2: What is "low power mode"? I can only find "Shutdown Mode" and "Ship Mode".

Q3: Does the 90µs limitation only apply in "low power mode" (whatever it is)?

Q4: Does it also apply when the device is not addressed at all, i.e. when communicating with other devices on the same bus?
This would be quite a serious limitation.

Kind Regards,
Wolfgang

  • Hi Wolfgang, 

    Please see my comments on your questions below. 

    1)The BQ25620 does not do I2C clock stretching. The IC will not hold the SCL line low. 

    2) To clarify "low power mode" refers to when the IC is in a low quiescent current state, but I2C communication is still active. The two cases of this are HIZ mode and battery only mode with the internal ADC turned off (ADC is off by default register configuration). For your reference in both ship mode and shutdown mode I2C communication is not active.

    3) Yes the 90µs limitation only applies to when the device is in either of the two states described above (HIZ & battery only mode), but typically other customers configure their I2C clock frequency and other timing requirements to be the same for all operation modes of their system rather than changing it depending charger IC functional mode. 

    4) Yes the 90µs START command to START command requirement does still apply when I2C host is addressing other devices on the same shared I2C bus as the BQ25620. 

    Please let me know if you have any further questions. 

    Best Regards,
    Garrett 

  • Hi Garrett,

    our device will be either in ship mode (woken by QON), Boost mode (normal operation), or charging (not operating).

    We plan to keep the ADC running all the time (no need to save a few µA as the active device will discharge the 400 mAh battery in 2 hrs).
    HIZ mode is not possible anyway because we need boosted voltage on PMID.

    So it seems that in none of the modes we use the 90µs requirement applies.

    However, it could still be present during mode transitions, especially when starting on battery via QON out of ship mode. AFAIU the BQ will then start in battery only and HIZ mode and must be initialized via I2C for the desired mode (Enable ADC, Boost etc.).
    QUESTION: During this initialization, the 90µs would still apply, but no more after it - correct?

    We could meet the 90µs limitation until the BQ has been initialized, but it would be difficult during normal operation.

    The problem is that we have no control over the inter-message timing. The different I2C bus members are accessed by independent tasks, and while the I2C driver can manage transactions from concurrent tasks, it has no provisions for a minimum START-to-START duration. It would simply start the next pending transaction directly after the previous has ended.
    90 µs correspond to 36 bits @ 400 kHz, i.e. 4 bytes. So short transactions like a simple status register read or write can violate the limit.

    Kind Regards,
    Wolfgang

  • Hi Wolfgang, 

    Thank you for your response. Please see my additional comments below. 

    QUESTION: During this initialization, the 90µs would still apply, but no more after it - correct?

    Correct, when your device starts up after exit from ship mode via QON the 90µs would apply until either ADC is turned on in continuous mode or boost converter is on.

    In my opinion the easiest implementation would be to use standard mode I2C (i.e. 100kHz clock) for initial BQ initialization when powered by battery. Once either ADC is running or boost converter is on 400kHz I2C communication can be utilized without further modification. 

    Best Regards,

    Garrett  

  • Thanks, Garret, for the in-depth responses.

    As for now, we have decided to just use 100 kHz all the time. This should still provide sufficient bandwidth.

    Regards,
    Wolfgang