BQ27421-G1: I2C command waiting time

Thanks for replying, let me confirm a bit for further understanding,

If the different command need to issue in order, for example, issuing Contol() for reading CONTROL_STATUS (let me name Command-A), issuing Control() for reading DEVICE_TYPE (let me name Command-B) and issuing Flags() for reading Flags bits (let's name Command-C), do I have to issue each command Command-A, Command-B, Command-C with interval of 1 second?

Or I can issue Command-A, Command-B, Command-C one after another with only providing 66 micro second bus-free interval?

I observed I2C communication of bq27421 EVM communication with bqStudio tool.

The minimum interval between two different commands was 13.2ms, and a set of command packets repeated every 4 seconds.

The observation result seems to match latter case, am I correct?

Kang Kang,

Thanks for replying,

I've read other posts such like below link which questioning about the same kind of issue and every time of these questions, TI support suggested "need to issue commands as not to post more than 2 commands in a second".

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

https://e2e.ti.com/support/power-management/f/196/p/936838/3460492

Today I'd met the same issue.
I'd tested as reading CONTROL_STATUS and Flags with 5ms interval from gauge, and post this command set every several seconds, almost usually result was normal, but when charging mode changed from charging to discharging (or vise-versa) sometimes fell back to initial state because of the WDRESET bit set and the ITPOR bit set.

At first when this situation of return to default occurs, I suspected some noise from power line caused ITPOR, but after changed charging mode, I read from gauge and got normal state (no ITPOR nor WDRESET, design capacity was the one I defined), and after a while (after several seconds) re-tried to read and then it got ITPOR with WDRESET.
I guess with changes of charging status caused something busy calculation which runs in a gauge IC and no afford for handling watchdog properly, am I correct?

Then here is my quesiton what previously I asked,
If the different commands need to issue in order, for example, issuing Contol() for reading CONTROL_STATUS (let me name Command-A), issuing Control() for reading DEVICE_TYPE (let me name Command-B) and issuing Flags() for reading Flags bits (let's name Command-C), do I have to issue each command Command-A, Command-B, Command-C with interval of more than 500 ms?

And what is the exact requirement for the watchdog reset triggered (or what does cause watchdog reset)?
There's no detailed explanation about watchdog in application note, data sheet, and TRM neither.
Since I want to avoid watchdog reset while writing GoldenImage data to the gauge, and polling voltage, SOC, current value from the gauge, if possible want to pause or postpone watchdog or want to issue command with checking if gauge can receive command properly.
Otherwise, system has to send GoldenImage data with 500 ms interval between each command and will take a very long time, or in a normal operation requires implement timer driven sequence to wait 500ms for I2C commnication not to bother other tasks including I2C communication with the other I2C based devices.

So, what you suggested is for me to make 'cut and try' experimentation, evaluation and find appropriate wait time parameter for the application, right?
And does it mean TI does not have exact specification of watchdog in the gauge IC? (Unbelievable!)

Just I'm asking this time period and what will be the trigger to suspend or snooze watchdog, if the watchdog internally runs every certain defined time period.
Or does the watchdog run depends on condition of event of battery and parameters (watchdog duration, trigger cause) vary at each case?

Of course it's ok to try out to find proper wait time parameters, but I'd like to know why WDRESET occurs and its mechanism.

Regards,

Then I guess there's only guide line for avoiding watchdog reset is, "not to issue more than twice per second" written in datasheet section 8.5.4.3, am I correct ?