About This Manual

This technical reference manual (TRM) discusses the modules and peripherals of the BQ76972 device, and how each is used to build a complete battery pack monitor and protection solution. For details on the hardware device features and electrical specifications, see the BQ76972 3-Series to 16-Series High Accuracy Battery Monitor and Protector for Li-Ion, Li-Polymer, and LiFePO4 Battery Packs Data Sheet (SLUSFC9).

The following notation is used if commands, subcommands, and data memory values are mentioned within a text block:

• Commands and subcommands: italics with parentheses and no breaking spaces; for example, Battery Status()
• Data memory: italics, bold, and breaking spaces; for example, Power Config
• Register bits and flags: italics and brackets; for example, [TDA]
• Data memory bits: italics and bold; for example, [LED1]
• Modes and states: ALL CAPITALS; for example, DEEPSLEEP

The Texas Instruments BQ76972 is a highly integrated, high accuracy battery monitor and protector for 3-series to 16-series li-ion, li-polymer, and LiFePO₄ battery packs. The device includes a high accuracy monitoring system, a highly configurable protection subsystem, and support for autonomous or host controlled cell balancing. Integration includes high-side charge-pump NFET drivers, dual programmable LDOs for external system use, and a host communication peripheral supporting 400-kHz I²C, SPI, and HDQ one-wire standards. Device features include:

• Battery monitoring capability for 3-series to 16-series cells
• Integrated charge pump for high-side NFET protection with optional autonomous recovery
• Extensive protection suite including voltage, temperature, current, and internal diagnostics
• Two independent ADCs
  • Support for simultaneous current and voltage sampling
  • High-accuracy coulomb counter with input offset error < 1 µV (typical)
  • High accuracy cell voltage measurement < 4 mV (typical)
• Wide-range current applications (±200-mV measurement range across sense resistor)
• Integrated secondary chemical fuse drive protection
• Autonomous or host-controlled cell balancing
• Multiple power modes (typical battery pack operating range conditions)
  • NORMAL mode: 286 µA
  • Multiple SLEEP mode options: 24 µA to 41 µA
  • Multiple DEEPSLEEP mode options: 9.2 µA to 10.7 µA
  • SHUTDOWN Mode: 1 µA
• High voltage tolerance of 85 V on cell connect and select additional pins
• Support for temperature sensing using internal sensor and up to 9 external thermistors
• Integrated one-time-programmable (OTP) memory programmable by customers on production line
• Communication options include 400-kHz I²C, SPI, and HDQ one-wire interface
• Dual programmable LDOs for external system usage

The BQ76972 product is a highly integrated, accurate battery monitor and protector for 3-series to 16-series li-ion, li-polymer, and LiFePO₄ battery packs. A high accuracy voltage, current, and temperature measurement accuracy provides data for host-based algorithms and control. A feature-rich and highly configurable protection subsystem provides a wide set of protections which can be triggered and recovered completely autonomously by the device or under full control of a host processor. The integrated charge pump with high-side protection NFET drivers allows host communication with the device even when FETs are off by preserving the ground connection to the pack. Dual programmable LDOs are included for external system use, with each independently programmable to voltages of 1.8 V, 2.5 V, 3.0 V, 3.3 V, and 5.0 V, capable of providing up to 45 mA each.

The BQ76972 device includes one-time-programmable (OTP) memory for customers to setup device operation on their own production line. Multiple communications interfaces are supported, including 400-kHz I²C, SPI, and HDQ one-wire standards. Multiple digital control and status data are available through several multifunction pins on the device, including an interrupt to the host processor, and independent controls for host override of each high-side protection NFET. Three dedicated pins are provided for temperature measurement using external thermistors, and multifunction pins can be programmed to use for additional thermistors, supporting a total of up to 9 thermistors, in addition to an internal die temperature measurement. Figure 2-1 shows the BQ76972 block diagram.

The BQ76972 device includes support for direct commands and subcommands. The direct commands are accessed using a 7-bit command address that is sent from a host through the device serial communications interface and either triggers an action, or provides a data value to be written to the device, or instructs the device to report data back to the host. Subcommands are additional commands that are accessed indirectly using the 7-bit command address space and provide the capability for block data transfers. When a subcommand is initiated, a 16-bit subcommand address is first written to the 7-bit command addresses 0x3E (lower byte) and 0x3F (upper byte). The device initially assumes a read-back of data may be needed, and auto-populates existing data into the 32-byte transfer buffer (which uses 7-bit command addresses 0x40–0x5F), and writes the checksum for this data into address 0x60. If the host instead intends to write data into the device, the host overwrites the new data into the transfer buffer, a checksum for the data into address 0x60, and the data length into address 0x61. As soon as address 0x61 is written, the device checks the checksum written into 0x60 with the data written into 0x40-0x5F, and if this is correct, it proceeds to transfer the data from the transfer buffer into the device's memory. The checksum is the 8-bit sum of the subcommand bytes (0x3E and 0x3F) plus the number of bytes used in the transfer buffer, then the result is bitwise inverted. The verification cannot take place until the data length is written, so the device realizes how many bytes in the transfer buffer are included. The checksum and data length must be written together as a word in order to be valid. The data length includes the two bytes in 0x3E and 0x3F, the two bytes in 0x60 and 0x61, and the length of the transfer buffer. Therefore, if the entire 32-byte transfer buffer is used, the data length is 0x24.

Some subcommands are only used to initiate an action and do not involve sending or receiving data. In these cases, the host can simply write the subcommand into 0x3E and 0x3F, it is not necessary to write the length and checksum or any further data.

The commands supported in the device are described in Commands and Subcommands. Single-byte commands are direct commands, while two-byte commands are subcommands. Data formats are described in Data Formats.

The most efficient approach to read the data from a subcommand (to minimize bus traffic) is shown below:

1. Write lower byte of subcommand to 0x3E.
2. Write upper byte of subcommand to 0x3F.
3. Read 0x3E and 0x3F. If this returns 0xFF, this indicates the subcommand has not completed operation yet. When the subcommand has completed, the readback returns what was originally written. Continue reading 0x3E and 0x3F until it returns what was written originally. Note: this response only applies to subcommands that return data to be read back.
4. Read the length of response from 0x61.
5. Read buffer starting at 0x40 for the expected length.
6. Read the checksum at 0x60 and verify it matches the data read.

An easier approach that is less efficient on bus traffic is:

1. Write the lower byte of the subcommand to 0x3E.
2. Write the upper byte of the subcommand to 0x3F.
3. Read 0x3E and 0x3F. If this returns 0xFF, this indicates that the subcommand has not completed the operation yet. When the subcommand has completed, the readback returns what was originally written. Continue reading 0x3E and 0x3F until it returns what was written originally. Note: this response only applies to subcommands that return data to be read back.
4. Read 0x40 to 0x61 in a block. Ensure that the checksum at 0x60 is correct over the length designated by 0x61. This means sometimes more bytes are read than necessary, but it also makes it possible to use a standard function that can be called for all subcommands.

Note: 0x61 provides the length of the buffer data plus 4 (that is, length of the buffer data plus the length of 0x3E and 0x3F plus the length of 0x60 and 0x61).

The checksum is calculated over 0x3E, 0x3F, and the buffer data, it does not include the checksum or length in 0x60 and 0x61.

If the checksum and length are read together, this can trigger an auto increment in some cases, in which case the buffer is populated with another block's data. So, generally the checksum and length should not be read together unless the buffer has already been read, or if auto-incrementing is intended.

Command or subcommand bits denoted RSVD_0 should only be written as a "0", while bits denoted RSVD_1 should only be written as a "1".

The BQ76972 device includes registers, which are stored in the RAM, and are integrated in one-time programmable (OTP) memory. At initial power-up, the device loads OTP settings into registers, which are used by the device firmware during operation. The device can also perform a reset on demand if the 0x0012 RESET() subcommand is sent. The recommended procedure is for the customer to write settings into OTP on the manufacturing line, in which case the device uses these settings whenever it is powered up. Alternatively, the host processor can initialize registers after power-up, without using the OTP memory, but the registers must be re-initialized after each power cycle of the device. Register values are preserved while the device is in NORMAL, SLEEP, or DEEPSLEEP modes. If the device enters SHUTDOWN mode, all register memory is cleared, and the device returns to the default parameters when powered again.

The OTP memory in the BQ76972 device is initially all-zeros. Each bit can be left as a "0" or written to a "1," but it cannot be written from a "1" back to a "0." The OTP memory includes two full images of the Data Memory configuration settings. At power-up, the device XORs each setting in the first OTP image with the corresponding setting in the second OTP image and with the default value for the corresponding setting, with the resulting value stored into the RAM register for use during operation. This allows any setting to be changed from the default value using the first image, then changed back to the default once using the second image. The OTP memory also includes a 16-bit signature, which is calculated over most of the settings and stored in OTP. When the device is powered up, it reads the OTP settings and checks that the signature matches that stored, to provide robustness against bit errors in reading or corruption of the memory. If a signature error is detected, the device boots into the default configuration (as if the OTP is cleared).

The device supports up to eight different signature values, so up to eight partial changes in OTP can be made, with the signature updated accordingly. The OTP signature does not include the Manufacturing Data (available using the 0x0070 MANU_DATA() subcommand) nor any PF status data that was written to OTP (which is read using the 0x0053 SAVED_PF_STATUS() subcommand).

The OTP memory settings are typically written after the device is assembled onto the PCB, but before cells are attached to the board. Programming the OTP memory settings requires the voltage applied on the BAT pin and the temperature to be within allowed limits, per specifications. All configuration settings are first loaded into registers using the serial communication interface (see Chapter 9). The 0x00A0 OTP_WR_CHECK() subcommand can be sent to initiate a self-check whether OTP writing can be accomplished. The device must be in FULLACCESS and CONFIG_UPDATE modes when this subcommand is sent. Table 3-1 shows the 0x00A0 OTP_WR_CHECK() information the device returns.

If the self-check is successful, then the actual OTP write can be initiated by sending the 0x00A1 OTP_WRITE() subcommand. This subcommand provides the same feedback as the 0x00A0 OTP_WR_CHECK() subcommand above, with byte-0, bit-7 being set if programming completed successfully. The time for OTP programming depends on the number of bytes that must be programmed, with the device taking approximately 200 μs per byte programmed.

Special exceptions are provided that allow programming the Manufacturing Data and PF status data to OTP during normal operation if Settings:Manufacturing:Mfg Status Init[OTPW_EN] is set.

Unsigned integers are stored without changes as 1-byte, 2-byte, or 4-byte values in little endian byte order.