SMBus Made Simple

SMBus Made Simple

Trademarks

All trademarks are the property of their respective owners.

1 Getting to Know SMBus

Figure 1 shows some simple examples of generic SMBus transactions. These transactions are read/write words with and without packet error checking (PEC). Although a user's scope traces may not look exactly like these examples, it is easier to look at these theoretical examples and understand their content rather than considering actual scope traces. Examples of actual scope trace are given later in this document. Note that more detailed information can be gathered from these pictures than is discussed in this document. Simplified information is given in order to present only the basics of SMBus information. For most troubleshooting issues, the basics are all that users need to solve SMBus problems.

First, entire packets for read and write are examined. Only word communications are considered because they are common and relevant for most troubleshooting.

Figure 1. SMBus Transaction Examples

The following components make up the packet along with some of the relevant issues to consider.

• Start bit: Each packet of data must start with a start bit denoted with an S. The clock must wait at least 4 µs after the data line goes low before it goes low.
• Device address 1: The device address is sent by the host telling all slaves on the bus which slave acknowledges this particular communication packet.
  • SMBus can have multiple slaves, so all other slaves that do not have this address ignore the packet. Smart batteries have device address 0x16. Thus, this packet is acknowledged by any fuel gauge.
  • Only one device on the bus can have the same device address.
  • The last bit of the device address is the read/write bit. A 0 for this bit denotes a write, and a 1 denotes a read. The read/write bit in the first device address for a read is a 0 because a command code is being written to the slave first. A write packet has only one device address because the direction (read/write) does not change.
• Acknowledge: Denoted by an A. The slave must acknowledge that the device address was received.
• Command code: This is the command or slave data address that is written to in a write packet or read from in a read packet.
• Repeated start (read): Denoted by an S. A second start bit embedded within the packet is used to shift the bus to a read.
• Device address 2 (read): The second device address in a read packet is a legacy component. Because a read operation is two packets combined with a repeated start, it is not required because the slave responsible for this packet has already been established. The SMBus specification still requires this as part of the specification, so it is mandatory for communicating to all devices including TI fuel gauges. However, important information is in this byte such as the read/write bit, which is set to a 1. This setting tells the slave that this packet is a read, so it is prepared to clock out data.
• Data LSB: The first byte of data is the least-significant byte of the data word. The reason why SMBus sends the LSB first is because SMBus sends data in little-endian format. This means that data is sent in increasing numeric significance. Most modern computers store data in memory in this order.
• Data MSB: This is the second byte of data for the word sent and is the most-significant byte. Again, it is sent this way to conform to the little-endian format.
• PEC: The PEC byte is a checksum of the entire packet used to protect against data corruption.
• Stop bit: This is the end of the packet. It tells the slave device that the bus is done, so the slave can get ready for more communications. It is an important part of the packet. Users can experience trouble by leaving this stop bit off if they get all the data. Although TI fuel gauges will time out and reset eventually without this, it is important to keep all devices on the bus in a known state at the end of each packet sent. Even if the host has to stop the communication in the middle of the packet for some reason, the host always sends the stop bit to reset everything on the bus.

1.1 Closer Inspection

To consider SMBus communication in more detail, Figure 2 shows an SMBus read word and zooms into one byte of a data packet and the NACK/Stop bit. This diagram gives examples of most of the important bits of a total packet.

Figure 2. SMBus Read Word – Without PEC

Each byte is 8 bits long. Several things of interest can be derived by looking closely at this diagram:

1. Data processing: Each bit of data is processed by the SMBus engine on the rising clock edge. This is where the data is shifted into the engine. Note that the data must never change levels while the clock is high during an SMBus transaction except to create a start, restart, or stop bit.
2. Clock timing: The most common cause of difficulty with the SMBus is when host systems fail to follow the SMBus High clock timeout specification. If the clock is high at any time during a transaction for more than 50 µs, the SMBus engine interprets this as a bus idle condition and resets. This SMBus specification requirement can be more problematic than any other.
3. Repeated start: The repeated start bit is unique in that it shifts the focus of the current transaction from a write to a read. Prior to the repeated start is a write to a command code with the read/write cleared in the device address, and after the repeated start, the bus shifts to a read of data with the read/write bit set.
4. Read/write bit: This bit is appended to the end of the device address. The device address is usually thought of as being 8 bits long, but it is actually 7 bits. So, the device address in an 8-bit format is a 0x16 in a write and a 0x17 after the repeated start in an SMBus read packet.
5. Acknowledge: All bytes are followed by an acknowledge (ACK) except for the last byte of a read packet when the host is responsible for NACK-ing the last byte. The slave expects a NACK of this byte even if it is a PEC byte (PEC is explained later in this document). Whoever receives the byte prior to the ACK is who is responsible for sending the ACK.
6. No acknowledge: A no acknowledge follows any byte that is not understood by the device receiving the previous data byte. The exception to this rule is the NACK required from the host after the last byte of data in a read packet (see number 5), which indicates to the slave that the host has received all bytes that it expected.
7. Start and stop bit: The stop bit is the final bit in the packet. Once this bit is sent by the host, the slave ignores anything on the bus until a start is detected and then only acknowledges its own device. By the SMBus specification, the fuel gauge must always acknowledge its device address.
8. Bit order versus byte order: This is important because the orders are opposite, which can be confusing. Each byte starts with the most-significant bit first and ends with the least-significant bit. However, the word of data is sent with the least-significant byte first and the most-significant byte last, which the SMBus specification requires. The bitwise order is normal; however, the bytewise order is in little-endian format as previously explained.

1.2 Final Considerations

The following are final considerations when examining all the points of a total packet.

1.2.1 Clock Stretching

Figure 3. SMBus Clock Stretch

Clock stretching is a simple way for the slave to indicate to the host that it is busy (see Figure 3). Any time the clock is low in the packet, the slave has the right to grab the clock and hold it low as long as required; however, the bit must not cause a packet timeout (25 ms).

The entire packet must not be longer than 25 ms, which includes the clock stretch. TI fuel gauges usually only clock stretch before or after the ACK or NACK bits.

1.2.2 Broadcasting (Master Mode Messages)

Sometimes, a slave can become the master of the bus. The SMBus specification allows for this possibility. All of TI's advanced fuel gauges have this ability. Depending on the fuel gauge (FG), this feature can be enabled or disabled in different ways. If enabled, the FG as master causes the bus to send alarms and charging voltage and charging current every 10 to 20 seconds to the host (0x10) and charger (0x12) device addresses

An SMBus master can only start a packet if the SMBus has been idle for more than 50 µs. Once this requirement has been met, the master immediately takes control of the bus by sending a start bit. All TI FGs function exactly like this, and because they are hardware-controlled SMBus engines, the FGs easily detect idle.

This type of behavior is difficult to create for an SMBus engine implemented in firmware. It is easy to detect 50 µs of idle time, but the port pins used to create the bus must be switched to outputs, and the start bit must be sent. During this time frame, another master can actually take control of the bus. If another master controls the bus, the firmware-controlled bus does not detect that the bus is no longer busy, which causes arbitration to be lost.

Because of this difficulty, most host systems do not recognize this part of the SMBus specification and, instead, act as the only master on the bus. Therefore, TI recommends that broadcasting messages be disabled for every application unless absolutely necessary.

1.2.3 PEC

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.