SLUUCW9 User guide

SLUUCW9 December 2023 BQ76972

9.3 SPI Communications Interface

The SPI interface in the BQ76972 device operates as a responder-only interface and supports rates up to 2 MHz 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 initially power up in other modes, depending on the device version. The OTP setting to select SPI mode in the BQ76972 (set by Settings:Configuration:Comm Type) can be programmed on the manufacturing line to select SPI mode, then when the device powers up, it automatically enters SPI mode. The host can also change the serial communication setting while in CONFIG_UPDATE mode, although the device does not immediately change communication mode upon exit of CONFIG_UPDATE mode, to avoid losing communications during evaluation or production. The host can write the 0x7C35 SWAP_TO_SPI() subcommand to change the communications interface to SPI with CRC (Settings:Configuration:Comm Type = 16) immediately, without needing to change the setting in CONFIG_UPDATE mode. Alternatively, 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 SPI interface logic operates with clock polarity (CPOL) = 0 and clock phase (CPHA) = 0, as shown in the figure below.

Figure 9-4 SPI with CPOL = 0 and CPHA = 0

The device also includes an optional 8-bit CRC using polynomial x⁸ + x² + x + 1. The interface must use 16-bit transactions if CRC is not enabled, and must use 24-bit transactions when CRC is enabled. CRC mode is enabled or disabled based on the setting of Settings:Configuration:Comm Type. Based on control settings, the logic:

(a) only works with CRC and does not accept data without valid CRC, or

(b) only accepts transactions without CRC (so the host must only clock 16 bits per transaction, because the device detects an error if more or fewer clocks are sent).

If the host performs a write with CRC and the CRC is not correct, then the incoming data is not transferred to the incoming buffer, and the outgoing buffer (used for the next transaction) is also reset to 0xFFFF. This transaction is considered invalid. On the next transaction, the CRC (if clocked out) is 0xAA, so the 0xFFFFAA indicates to the controller that a CRC error was detected.

The internal oscillator in the BQ76972 device may not be running when the host initiates a transaction (for example, this can occur if the device is in SLEEP mode). If this occurs, the interface drives out 0xFFFF on SPI_MISO for the first 16 bits clocked out. It also drives out 0xFF for the third (CRC) byte as well, if CRC is enabled. So the 0xFFFFFF indicates to the controller that the internal oscillator is not ready yet. The address 0x7F used in the device is defined in such a manner that there should be no valid transaction to write 0xFF into this address. Thus the two-byte pattern 0xFFFF should never occur as a valid sequence in the first two bytes of a transaction (that is, it is only used as a flag that something is wrong, similar to an I²C NACK).

If the internal HFO oscillator is not running in the device, it is automatically wakened at the falling edge of SPI_CS (this is true while in NORMAL, SLEEP, or DEEPSLEEP modes, but not in SHUTDOWN mode). In NORMAL mode or SLEEP mode the HFO may take approximately 135 µs to stabilize and be available for use by the SPI interface logic. In DEEPSLEEP mode, the HFO takes approximately 4.5 ms to stabilize and be available. This delay means that requested data generally cannot be provided back to the host during the first SPI transaction when the HFO was initially off. Thus, in cases when the HFO is likely initially off, it is recommended that the host first write a "dummy" SPI transaction to waken the HFO, then wait at least 135 µs while in NORMAL or SLEEP modes, or 4.5 ms while in DEEPSLEEP mode, before sending the intended SPI transaction. If a SPI transaction returns 0xFFFF (in 16-bit mode) or 0xFFFFFF (in 24-bit mode) while in NORMAL or SLEEP modes, the host should retry the transaction again after a delay of at least 135 µs, or 4.5 ms after initial powerup or while in DEEPSLEEP mode. This allows time for the HFO to waken, if it was initially off, and for the device to prepare the data requested and have it ready for readout.

It is recommended to set the Settings:Configuration:Comm Idle Time to a level of 1 second or higher when using SPI mode, which causes the HFO to stay powered for a programmable number of seconds after it is wakened by a falling edge on SPI_CS. The host can set this to a longer time (up to 255 seconds) and maintain regular communications within this window, causing the HFO to stay powered, so the device can respond quickly to SPI transactions. However, keeping the HFO running continuously causes the device to consume additional supply current (approximately 30 µA) beyond what it would consume if there were minimal communications. To avoid this extra supply current, the host can send initially send a "dummy" SPI transaction (such as reading command CONTROL_STATUS()) to cause the HFO to waken, and continue this until a valid response is returned on SPI_MISO. At this point, the host can begin sending the intended SPI transactions. Afterward, the host can write 0xAA to the 0x7F address, which causes the HFO to turn off. Note that 0x7F FET Status() is a read-only command, this special case of sending 0xAA to that command address is unrelated to the 0x7F FET Status() command.

The device includes ability to detect a frozen or disconnected SPI bus condition, and it then resets the bus logic. This condition is recognized when the SPI_CS is low and the SPI_SCLK is static and not changing for a 2-second timeout.