• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 63 subscribers
  • Views 270 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:

BQ27426: Condition of I2C command

BQ27441-G1: I2C command waiting time

David McRell
Intellectual 445 points
Part Number: BQ27441-G1

Hello!

In the BQ27441 ds, page 14, Section 9.5.4.3, there is statement that "the gauge could result in a reset issue due to the expiration of the watchdog timer."

In QSG sluuap7, page 4, Figure 1, are there any unstated/implied waits in this flowchart?

3) Does the following apply to BQ27441?

This link: http://e2e.ti.com/support/power-management/f/196/p/885960/3282456 has this link: http://www.ti.com/lit/ug/sluub65a/sluub65a.pdf - see pages 62 and 63.  See “A 100-ms waiting time is required between the checksum command and reading result”. 

References:

https://e2e.ti.com/support/power-management/f/196/t/739335

https://e2e.ti.com/support/power-management/f/196/t/838088

https://e2e.ti.com/support/power-management/f/196/t/574055

e2e.ti.com/.../538858

Many thanks in advance for your help!

Kind Regards,

David McRell

  • 0
    TI__Mastermind 24870 points

    Hello David,

    First of all, thank you for trying to find the related answers on e2e.

    The watchdog and the wait times are separate.

    The wait times are during flash write operations where the gauge is clock stretching any commands. During that time, you will not be able to get ack from the gauge from its address. That's just one type of item.

    The watchdog reset is when the gauge OS runs long and times out. This normally should not happen, but we have seen cases of long running simulation times in some instances where we had to adjust some parameters.

    The waiting times are different. There's unfortunately no good way to characterize this. The only way I can think of and I'm no expert is to do a try until success loop and add 1 ms to a host processor to see what these delays are in system.