SLUA475 November   2016 BQ2060A , BQ20Z80 , BQ40Z50-R1 , BQ40Z50-R2 , BQ40Z60 , BQ78350-R1 , BQ78350-R1A

 

  1.   SMBus Made Simple
    1.     Trademarks
    2. 1 Getting to Know SMBus
      1. 1.1 Closer Inspection
      2. 1.2 Final Considerations
        1. 1.2.1 Clock Stretching
        2. 1.2.2 Broadcasting (Master Mode Messages)
        3. 1.2.3 PEC
          1. 1.2.3.1 How to Calculate PEC
        4. 1.2.4 Examples
          1. 1.2.4.1 Example 1
          2. 1.2.4.2 Example 2
          3. 1.2.4.3 Example 3
          4. 1.2.4.4 Example 4
    3. 2 Most Common Problems
    4. 3 Glossary
    5. 4 References
  2.   A SMBus Reference Sheet
    1.     19

2 Most Common Problems

  1. Capacitance: It is important that the data line is clean and well within an intended defined state when the clock pulse goes high; otherwise, results can be unpredictable. Capacitance or a weak pullup can cause troubleshooting difficulties because of inconsistent effectiveness. Rolloff caused by capacitance can cause the data line to be in an unknown state when the clock goes high, which causes confusion to the SMBus engine.
  2. Clock high time: This is one of the more common overlooked problems. The clock must be high for less than 50 µs during the middle of a communication packet. This rule has no exceptions. If the clock is high longer than 50 µs, then the SMBus engine on the slave most likely times out.
  3. Communicating too fast: This is common when using an I²C hardware engine to perform the SMBus communications. The SMBus engine is only specified at 100 kHz. Communicating faster than this causes timing minimum rules to be violated.
  4. Broadcast or other collisions: In most TI advanced fuel gauge solutions, slave broadcasting (sometimes called master mode messaging) is disabled by default. This problem has been greatly reduced in recent years. Because most hosts or chargers do not accept broadcast messages, it is good practice to disable them if they are not being used.
  5. Wrong-sized pullup resistors: Overall resistance must be approximately 10 kΩ for the SMBus clock line and 10 kΩ for the SMBus data line. Multiple masters can cause problems here because the resistors are in parallel, which reduces the overall resistance on the line. Whenever the SMBus line is pulled low, poor low voltage is noticeable. Remember to test the resistance using an oscilloscope on the receiving end of the line.
  6. Too-fast data to clock transitions: This is often a problem on firmware-controlled host engines. For most high-speed processors, there must be enough NOP instructions between the data line going high and prior to the clock going high on each bit. This is especially important on the start, stop, and repeated start bits..
  7. Bad PEC computation: To date, no TI fuel gauges that support PEC have been proven to produce an incorrect PEC computation. If you are getting an error because the PEC is incorrect, then most likely it is an error in your PEC computation code. Check for roll off or carry errors.
  8. Non-SMBus-compliant host: Many failed communications occur because the host is not SMBus-compliant, and the user cannot change the host design. TI SMBus engines are mostly hardware engines and allow little manipulation. Therefore, it is important to ensure that the host is SMBus compliant prior to releasing the product.
  9. Using an existing I²C engine to run SMBus: This usually works well, but the user must be attentive to the I²C speed. Many modern I²C hardware ports on microcontroller (MCU) units can run at 100 kHz or 400 kHz. Always use 100 kHz. Even then, the port may exceed 100 kHz at time. Ensure that the clock cannot be high for more than 50 µs.
  10. Host does not allow clock stretching: This is especially a problem if the host is firmware driven. The host must check the clock after it sends it high to verify that it actually went high. If it does not do this, then the slave may be trying to slow the clock down and it ignores this and continues. This causes loss of arbitration, and both master and slave get confused.