SLUA475 November 2016 BQ2060A , BQ20Z80 , BQ40Z50-R1 , BQ40Z50-R2 , BQ40Z60 , BQ78350-R1 , BQ78350-R1A
The System Management Bus (SMBus) is the most common form of communication for Texas Instruments advanced fuel gauges. Many customers want to design SMBus engines to communicate with TI advanced fuel gauges. Though this is possible, these designs sometime lead to confusion and frustration. Investigating SMBus errors or transaction failures can seem to be a difficult or daunting task. The purpose of this application report is to reduce the complexity and make learning SMBus easier. This report assumes some knowledge of I²C.
All trademarks are the property of their respective owners.
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.
The following components make up the packet along with some of the relevant issues to consider.
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.
Each byte is 8 bits long. Several things of interest can be derived by looking closely at this diagram:
The following are final considerations when examining all the points of a total packet.
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.
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.
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.
PEC calculations take some resources by the host system unless it has a hardware PEC engine. Although this document does not detail about how to do these calculations, many resources are available on the Internet, which include explanations and even code examples. Do an Internet search for PEC or CRC-8 computation. For an example of an online calculator that can check your code, refer to http://smbus.org/faq/crc8Applet.htm.
The following are two primary methods to calculate a PEC for a given data packet. Depending on your host CPU and memory, one of these methods should work for your application.
Consider the use of a logic analyzer or bus snooper for PEC calculations. Though a logic analyzer or a bus snooper may appear to be the simplest tools to monitor the SMBus traces, the following are a few of many reasons why an oscilloscope is preferable.
Msg 11 [S]#16 [A] #0E [A][S] #17 [A] #8C [A] #86 [A] #D8 [N][P]
Msg 12 [S]#16 [A] #0E [A][S] #17 [N]
It is apparent that this communication has a problem: the device NACKed its device address after the repeated start.
Example 1 is shown in Figure 5. Notice that one can actually determine which device is pulling down on the bus at any given time. The zero threshold for the fuel gauge is at a lower voltage than the zero threshold for the host. The oscilloscope is an extremely useful tool when debugging to determine which device is in control of the bus. The reason this works is due to the current flowing through series protection resistors on the bus. The zero threshold is slightly different depending on which side of these series resistors the scope probe is connected with reference to ground.
Figure 6 is a modified picture showing different connection points for an oscilloscope probe. Each point has a different zero level voltage in reference to ground. The difference also varies depending on the resistors used in the circuit. This original picture was derived from the SMBus specification.
The problem associated with Example 2 (shown in Figure 7) was a matter of receiving incorrect data. Although almost every bit received was correct, an incorrect bit was occasionally received. As pointed out in Figure 7, a large capacitance on the line sometimes caused a 1 to be read as a 0 because the data line was just on the edge of going up fast enough to be a 1 by the time the clock went to a 1. In Example 2 protection diodes were used on the bus that had a very high capacitance. By removing the high-capacitance protection diodes and using a more common protection circuitry as shown in Figure 8, the problem was solved.
Figure 9 shows Example 3, an oscilloscope plot of a read word. This data poses the question of why the bq2060 was pulling the data line low as shown with the arrow. Available snooper data showed an ACK and then a STOP bit. The problem was the host did not intend to send a PEC byte, but because it sent an ACK (host pulled data line low at the clock), the bq2060 interpreted this as send another byte of data, which in this case, was the PEC byte. Therefore, the bq2060 held the data line low (trying to send a 0), waiting for clocks from the host. The host tried to send a stop bit because of the confusion. The solution to this issue was to make the host send a NACK after the high byte of data.
The long clock stretch shown in Example 4 (Figure 10) is uncommon but still easily complies with the SMBus specification (25-ms packet length). Example 4 is a clear example of a clock stretch. As in this example, most clock stretches happen somewhere around the ACK and NACK clocks.
ACK: A bit in the SMBus communication packet used to signify an acknowledgment of the previous byte of data.
Broadcast: A term to indicate when the TI fuel gauge becomes a master on the bus and broadcasts information to the host as a master. This is also sometimes called master mode messaging.
FG: Acronym for fuel gauge
LSB: Acronym for least-significant byte; two bytes of data.
Master: The device on the SMBus that controls the current communication packet. The master controls the clock line on the bus for any given packet.
MSB: Acronym for most-significant byte; two bytes of data.
NACK: A bit in the SMBus communication packet used to signify a no-acknowledgment of the previous byte of data. This abbreviation usually signifies an SMBus error, or it comes at the end of the last byte of a read communication packet.
Packet: A complete SMBus transaction, either read or write, from the start bit to stop bit.
Repeated start: A second start bit in the communication packet used in a SMBus read to transition from writing the SMBus command code to reading data from that command code.
Slave: This is the opposite of the master. The slave does not control the clock line except for clock stretching used to slow the transaction down to allow the slave more time, if needed.
Word: For this document, an SMBus word signifies two bytes of data (0xFFFF), translated from 0–65535 unsigned or –32768 to 32767 signed
Texas Instruments Incorporated (‘TI”) technical, application or other design advice, services or information, including, but not limited to, reference designs and materials relating to evaluation modules, (collectively, “TI Resources”) are intended to assist designers who are developing applications that incorporate TI products; by downloading, accessing or using any particular TI Resource in any way, you (individually or, if you are acting on behalf of a company, your company) agree to use it solely for this purpose and subject to the terms of this Notice. |
TI’s provision of TI Resources does not expand or otherwise alter TI’s applicable published warranties or warranty disclaimers for TI products, and no additional obligations or liabilities arise from TI providing such TI Resources. TI reserves the right to make corrections, enhancements, improvements and other changes to its TI Resources. |
You understand and agree that you remain responsible for using your independent analysis, evaluation and judgment in designing your applications and that you have full and exclusive responsibility to assure the safety of your applications and compliance of your applications (and of all TI products used in or for your applications) with all applicable regulations, laws and other applicable requirements. You represent that, with respect to your applications, you have all the necessary expertise to create and implement safeguards that (1) anticipate dangerous consequences of failures, (2) monitor failures and their consequences, and (3) lessen the likelihood of failures that might cause harm and take appropriate actions. You agree that prior to using or distributing any applications that include TI products, you will thoroughly test such applications and the functionality of such TI products as used in such applications. TI has not conducted any testing other than that specifically described in the published documentation for a particular TI Resource. |
You are authorized to use, copy and modify any individual TI Resource only in connection with the development of applications that include the TI product(s) identified in such TI Resource. NO OTHER LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE TO ANY OTHER TI INTELLECTUAL PROPERTY RIGHT, AND NO LICENSE TO ANY TECHNOLOGY OR INTELLECTUAL PROPERTY RIGHT OF TI OR ANY THIRD PARTY IS GRANTED HEREIN, including but not limited to any patent right, copyright, mask work right, or other intellectual property right relating to any combination, machine, or process in which TI products or services are used. Information regarding or referencing third-party products or services does not constitute a license to use such products or services, or a warranty or endorsement thereof. Use of TI Resources may require a license from a third party under the patents or other intellectual property of the third party, or a license from TI under the patents or other intellectual property of TI. |
TI RESOURCES ARE PROVIDED “AS IS” AND WITH ALL FAULTS. TI DISCLAIMS ALL OTHER WARRANTIES OR REPRESENTATIONS, EXPRESS OR IMPLIED, REGARDING TI RESOURCES OR USE THEREOF, INCLUDING BUT NOT LIMITED TO ACCURACY OR COMPLETENESS, TITLE, ANY EPIDEMIC FAILURE WARRANTY AND ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NON-INFRINGEMENT OF ANY THIRD PARTY INTELLECTUAL PROPERTY RIGHTS. |
TI SHALL NOT BE LIABLE FOR AND SHALL NOT DEFEND OR INDEMNIFY YOU AGAINST ANY CLAIM, INCLUDING BUT NOT LIMITED TO ANY INFRINGEMENT CLAIM THAT RELATES TO OR IS BASED ON ANY COMBINATION OF PRODUCTS EVEN IF DESCRIBED IN TI RESOURCES OR OTHERWISE. IN NO EVENT SHALL TI BE LIABLE FOR ANY ACTUAL, DIRECT, SPECIAL, COLLATERAL, INDIRECT, PUNITIVE, INCIDENTAL, CONSEQUENTIAL OR EXEMPLARY DAMAGES IN CONNECTION WITH OR ARISING OUT OF TI RESOURCES OR USE THEREOF, AND REGARDLESS OF WHETHER TI HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. |
You agree to fully indemnify TI and its representatives against any damages, costs, losses, and/or liabilities arising out of your non-compliance with the terms and provisions of this Notice. |
This Notice applies to TI Resources. Additional terms apply to the use and purchase of certain types of materials, TI products and services. These include; without limitation, TI’s standard terms for semiconductor products http://www.ti.com/sc/docs/stdterms.htm), evaluation modules, and samples (http://www.ti.com/sc/docs/sampterms.htm). |
Mailing Address: Texas Instruments, Post Office Box 655303, Dallas, Texas 75265 Copyright © 2018, Texas Instruments Incorporated |