SLUUCW9 User guide

SLUUCW9 December 2023 BQ76972

9.2 I²C Communications Subsystem

The I²C serial communications interface in the BQ76972 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 BQ76972 initially powers up by default in 400 kHz I²C mode, while other versions of the device can have a different default setting (for example, the BQ7697201 initially powers up by default in SPI with CRC 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 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. Use the Comm Type settings with timeouts only if the bus is operating at 100 kHz or 400 kHz. If Comm Type= 0x1E (100 kHz mode with timeouts enabled), then the device resets 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 approximately 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 resets 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 9-1. 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 NACKs 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 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 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 a read transaction is sent by the host, the device may clock stretch while it fetches the data and prepares to send it. However, when subcommands are sent that require the device to fetch data and load it into the 0x40-0x5F transfer buffer, 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. The approximate times required for the device to fetch the data for subcommands are described in Table 9-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.

9.2 I2C Communications Subsystem

9.2 I²C Communications Subsystem