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.

TI BQ27421 gauge: I2C command waiting time

Other Parts Discussed in Thread: EV2400, BQSTUDIO

In the datasheet of BQ27421 (SLUSB85E – MAY 2013 – REVISED JANUARY 2016), in the page-13, Chapter 8.5.4.3 I2C Command Waiting Time,

it said:

1)  In addition, if the SCL clock frequency (fSCL) is > 100 kHz, use individual 1-byte write commands for proper data flow control.

1-1) Does it mean that it should use 2 1-byte write packets for a subcommand if SCL clock frequency is > 100 KHz?

[Start] [Address(6:0) | 0] [A] [CMD(7:0)] [A] [Data(7:0)] [A] [P]

[Start] [Address(6:0) | 0] [A] [CMD(7:0)] [A] [Data(7:0)] [A] [P]

2) The following diagram shows the standard waiting time required between issuing the control subcommand

the reading the status result.

 For read-write standard command, a minimum of 2 seconds is required to get the result updated.

2-1) Does it mean that the following procedures are necessary for the read-write command?

2-1-1) the issuing the control subcommand,

2-1-2) minimum 2 seconds delay,

2-1-3) reading the status result

3) For read-only standard commands,there is no waiting time required, but the host must not issue

any standard command more than two times per second.

Otherwise, the gauge could result in a reset issue due to the expiration of the watchdog timer.

3-1) Does it mean that only 1 standard command per second is allowed?

Thank you.

  • 1-1: Yes, you must use individual write commands (not incremental) if SCL > 100kHz
    2-2: If you write to the gauge, it can take up to 2 seconds for the gauge to update
    3-1: This is fairly conservative. Technically it is correct but the gauge will accept more than 1 standard command per second in most cases. If you keep issuing standard commands in fast succession (e.g. no delay in between) for several seconds then the gauge will be reset by its watchdog.
  • Thank you for your kind support.

    Have a nice day.

  • Dominik-san,

    I have some questions about "I2C command waiting time" too.
    Does "standard command" include "Extended commands"? Or is it only "standard command" on datasheet P.10 Table 1?
    And it is only RW command of Control() and Temperature()? Or are DataClass(), DataBlock(), BlockData(), BlockDataCheckSum() and BlockDataControl() included?

    For example, we confirm CFGUPDATE mode by reading Flags() when Data memory parameter update.
    At this time, should we wait 2s from sending SET_CFGUPDATE subcommand?
    And we write data to Block data(). Then should we wait 2s if we would like to confirm set data?


    Best Regards,
    Kohei Sasaki
  • Sasaki-san,

    This recommendation includes Extended Commands (also DataClass() etc.).

    It is not necessary to wait 2s after SET_CFGUPDATE before checking flags. It may take 2s before the flags are set.

    Regards,
    Dominik.

  • Dominik-san,

    Additionally I would like to know the following datasheet comment,
    "For read-only standard commands, there is no waiting time required, but the host must not issue any standard command more than two times per second"

    I think this means the number of read or write commands per second is two.
    And if it is so, I think 66us waiting time does not make sense. It should be more longer, for example it is about 500ms etc...

    If we must follow this, I think it takes over 10 seconds to read all standard command.
    Furthermore I think it takes too long time (about over 10 seconds) to update data memory. And I think required time increase commensurately.
    Is my understand correct?

    Our customer said this is too long to initial setting of gauge when battery is connected.
    Do we must follow this? How far is acceptable?

    Best Regards,
    Kohei Sasaki
  • Hi Sasaki,

    I have made the same considerations, since I'm trying to deal with the BQ27421 too.

    But I went far in this tryouts, because I had another issue. Sometimes (let say half the times to simplify) when I launch the config update params procedure explained in pag 4 and 5 of Quick start guide, it apparently blocks after sending the I2C read command related to design energy data register. I send the commands using an Atmel SAMB11 Xplained pro board, and I know it works because it works sending I2C commands to an ST accelerometer through the same I2C port. Moreover, it's a blocking routine in the first part of main so it could not depend on microcontroller but it's related to the fuel gauge.

    So I was thinking the problem is related to I2C timing, so I added a delay after every command sent, everyone. I started with the 66us up to 2s delay but. don't know why, the problem is still present.

    So my dubt is: it is related to timing (did I misunderstood the I2C timing part on datasheet?), or is it something more I miss in fuel gauge programming? I would like to avoid buying the EV2300 or EV2400, just because I will handle the gauge using the same Atmel module...


    Can you help me too Dominik?
  • Hello,

    I understand that this is not ideal and the 2 commands per second is on the very conservative side. I don't have a data sheet override for this specification but if you check the flash stream files that are generated by bqStudio, you'll see X: commands, which insert the delays that are required to make it work reliably.

    So the fastest way that you can reliably program the gauge is to follow the examples from the flash stream file and make sure that you insert 66us between stop and start conditions. It will take a lot less than 10 seconds to fully write the data classes for the bq27421.

    Regards,
    Dominik.
  • Dominik-san,

    I confirmed GMFS file.
    According to it, 32 byte of BlockData() is written without delay time. Are these updated correctly although BlockData() is RW command?
    Isn't it needed 2s wait time?


    Best Regards,
    Kohei Sasaki
  • Sasaki-san,

    The .gm.fs file should have a X: 10 command between writing the check sum (which triggers the write to memory) and verifying the check sum.

    There is no need to wait 2 seconds.

    Regards,
    Dominik.

  • Dominik-san,

    Thank you for your reply.
    I understood that 10ms wait time is enough to update, there is no need 2s.

    Best Regards,
    Kohei Sasaki
  • Dominik-san,

    Our customer is going to read AverageCurrent(), StateOfCharge(), Voltage(), AveragePower() back-to-back every 1s.
    Should they limit sending 2 commands per 1s? Or is it no problem that above 4 commands are issued back-to-back?
    Or is it no problem for this limitation if they use incremental read?

    Best Regards,
    Kohei Sasaki
  • This should be ok.
  • Dominik-san,

    Thank you for your reply.
    I understood 4 commands read is no problem.

    How is the incremental read?
    Is there possibility of reset if the host keep incremental read for a long time?

    Best Regards,
    Kohei Sasaki

  • Sasaki-san,

    Incremental read is ok. A reset will happen if you continuously read standard commands. Once a second incremental read of 4 standard commands will work.

    Regards,
    Dominik.

  • Dominik-san,

    How is the incremental read of 32 byte data? Do you think reset will happen?

    Best Regards,
    Kohei Sasaki
  • Sasaki-san,

    You can read 32-bytes incrementally from the gauge, for example from extended command 0x40 when you read a sub-class from data memory.

    Regards,
    Dominik.