The SPI interface in the BQ76942 device operates as a responder-only interface and supports rates up to 1.8 MHz with an optional CRC check. If the OTP was not programmed, the BQ76942 will initially power up by default in 400 kHz I²C mode, while other versions of the device may initially power up in other modes, depending on the device version. The OTP setting to select SPI mode in the BQ76942 (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 will not immediately change communication mode upon exiting 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.

The device also includes an optional 8-bit CRC using the 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 does the following:

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

(b) only accepts transactions without CRC (so the host must only clock 16-bits per transaction, the device will detect an error if more or less 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) will be 0xAA, so the 0xFFFFAA will indicate to the controller that a CRC error was detected.

The internal oscillator in the BQ76942 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 will also drive out 0xFF for the third (CRC) byte as well, if CRC is enabled. So the 0xFFFFFF will indicate 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 will be 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 ≈ 135 µs to stabilize and be available for use by the SPI interface logic. In DEEPSLEEP mode, the HFO will take ≈ 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 will cause the device to consume additional supply current (≈ 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 send 0xAA to the 0x7F address, which will cause the HFO to turn off.

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