SLUA475 November 2016 BQ2060A , BQ20Z80 , BQ40Z50-R1 , BQ40Z50-R2 , BQ40Z60 , BQ78350-R1 , BQ78350-R1A
PEC is a simple form of a checksum used for error checking. It is important to use PEC in all communications to ensure what was sent or received was actually intended. PEC is really just an extra byte of data added to the end of the communication packet that is derived from a simple CRC-8 checksum. All TI fuel gauges that support PEC also have the option to add PEC to the broadcast data if desired. However, most customers never use the broadcasts. Broadcasts must be completely disabled if not used.
A common question is Who sends (is responsible for) the PEC byte? For this discussion, assume the master is the host system (notebook, PC, or another host), and the slave is the fuel gauge. In read operations, the slave (fuel gauge) is responsible for sending the PEC packet to the host. Then the host determines if the PEC is valid. In a write operation, the host is responsible for sending the PEC to the slave. Though some slave devices may not be fast enough, a TI fuel gauge always NACKs the PEC byte if an error is in the packet, which can sometimes be confusing. Therefore, a simple and easy way to remember this is that the SMBus device, which is responsible for sending the data of the last byte of the packet, is the one responsible for the PEC.
The SMBus specification has much more information about PEC relating to protection against devices that do not perform the PEC function reliably; however, they do not apply to TI fuel gauges. TI parts use a hardware PEC lookup; therefore, software does not interfere with the process. With TI fuel gauges, an ACK to a bad data packet's PEC byte will never be occur, instead, a NACK to a bad data packet occurs.