The I²C serial communications interface in the BQ769142 device acts as a responder device and supports rates up to 400 kHz with an optional CRC check. If the OTP has not been programmed, the BQ769142 will initially power up by default in 400 kHz I²C mode with CRC enabled. The OTP setting can be programmed on the manufacturing line, then when the device powers up, it will automatically enter 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 will take effect upon exit of 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 100 kHz or 400 kHz. If Comm Type= 0x1E (100 kHz mode with timeouts enabled), then the device will reset the communications interface logic if a clock is detected low longer than a t_TIMEOUT of 25 ms to 35 ms, or if the cumulative clock low responder extend time exceeds ≈25 ms, or if the cumulative clock low controller extend time exceeds 10 ms. If Comm Type= 0x09 (400 kHz mode with timeouts enabled), then the device will reset the communications interface logic if a clock is detected low longer than t_TIMEOUT of 5 ms to 20 ms. 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.

An I²C write transaction is shown in Figure 10-1. Block writes are allowed by sending additional data bytes before the Stop. The I²C logic will auto-increment 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 10-2 shows a read transaction using a Repeated Start.

Figure 9-2 I²C Read with Repeated Start

Figure 10-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 will auto-increment 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 will include the responder address, the register address, then the responder address with 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 will include the responder address, the register address, then the responder address with 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 will NACK 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 will vary during operation. The approximate times required for the device to fetch the data for subcommands are described in Table 10-2. When sending a subcommand, it is recommended to 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.