The I²C serial communications interface in the BQ76922 device acts as a responder device and supports rates up to 400kHz with an optional CRC check. If the OTP was not programmed, the BQ76922 initially powers up by default in 400kHz I²C mode. The OTP setting can be programmed on the manufacturing line, then when the device powers up, it automatically enters the selected mode per OTP setting. The host can also change the I²C speed setting while in CONFIG_UPDATE mode, then the new speed setting takes effect upon exiting CONFIG_UPDATE mode. Alternatively, the host can write the 0x29E7 SWAP_TO_I2C() subcommand to change the communications interface to I²C fast mode (Settings:Configuration:Comm Type = 8) immediately, without needing to enter CONFIG_UPDATE mode. The 0x29BC SWAP_COMM_MODE() subcommand can be sent to transition the device to the communications mode selected by the setting in Settings:Configuration:Comm Type.

The I²C device address is set by default as 0x10 (write), 0x11 (read), which can be changed by programming Settings:Configuration:I2C Address with the desired write address.

The communications interface includes optional timeout capability, which can be enabled based on the Comm Type setting. The Comm Type settings with timeouts should only be used if the bus will be operating at 100kHz or 400kHz. If Comm Type= 0x1E (100kHz mode with timeouts enabled), then the device resets the communications interface logic if a clock is detected low longer than a t_TIMEOUT of 25ms to 35ms, or if the cumulative clock low responder extend time exceeds ≈25ms, or if the cumulative clock low controller extend time exceeds 10ms. If Comm Type= 0x09 (400kHz mode with timeouts enabled), then the device resets the communications interface logic if a clock is detected low longer than t_TIMEOUT of 5ms to 20ms. The bus also includes a long-term timeout if the SCL pin is detected low for more than 2 seconds, which applies whether the Comm Type setting includes timeouts or not.

Figure 9-1 shows an I²C write transaction. Block writes are allowed by sending additional data bytes before the stop. The I²C logic auto-increments the register address after each data byte.

When enabled, the CRC is calculated as follows:

• In a single-byte write transaction, the CRC is calculated over the responder address, register address, and data.
• In a block write transaction, the CRC for the first data byte is calculated over the responder address, register address, and data. The CRC for subsequent data bytes is calculated over the data byte only.

The CRC polynomial is x⁸ + x² + x + 1, and the initial value is 0.

When the responder detects a bad CRC, the I²C responder will NACK the CRC, which causes the I²C responder to go to an idle state.

Figure 9-1 I²C Write

Figure 9-2 shows a read transaction using a repeated start.

Figure 9-2 I²C Read with Repeated Start

Figure 9-3 shows a read transaction where a repeated start is not used; for example, if not available in hardware. For a block read, the controller ACKs each data byte except the last and continues to clock the interface. The I²C block auto-increments the register address after each data byte.

When enabled, the CRC for a read transaction is calculated as follows:

• In a single-byte read transaction, the CRC is calculated beginning at the first start, so includes the responder address, the register address, then the responder address with a read bit set, then the data byte.
• In a block read transaction, the CRC for the first data byte is calculated beginning at the first start and includes the responder address, the register address, then the responder address with a read bit set, then the data byte. The CRC resets after each data byte and after each stop. The CRC for subsequent data bytes is calculated over the data byte only.

The CRC polynomial is x⁸ + x² + x + 1, and the initial value is 0.

When the controller detects a bad CRC, the I²C controller NACKs the CRC, which causes the I²C responder to go to an idle state.

Figure 9-3 I²C Read Without Repeated Start

When the host sends a read transaction, the device may clock stretch while it fetches the data and prepares to send it. However, when subcommands that require the device to fetch data and load it into the 0x40–0x5F transfer buffer are sent, the device does not clock stretch during this time. The timing required for the device to fetch the data depends on the specific subcommand and any other processing underway within the device, so it varies during operation. When sending a subcommand, wait long enough for the device to fetch the data, then read 0x3E/0x3F again. If the initial subcommand is echoed back from this read, then the fetched data is available and can be read from the transfer buffer.

The approximate time required to complete an operation based on the particular command or subcommand is shown below.