• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 62 subscribers
  • Views 153 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

BQ40Z50-R2: SMBus timeout in reported start portion

Beginner
Intellectual 2221 points
Part Number: BQ40Z50-R2

Customers raise a question about SMBus timeout question for one host doesn't follow SMBus spec. 

The following is a standard SMBus protocal to read byte. If host pull clock low during repeat start section to cause but timeout, 

a. Will this cause gauge reset SMBus engine? 

b. What data gauge will reply if host send future days to complete whole communication? 

This is a real case they met. Since they cannot change host behavior, they need our comments to explain what's our expectation. 

For quick test, TI gauge won't reset engine and data and host can get the correct data but competitor cannot. Please help to check above question. 

  • 0
    TI__Guru** 102455 points

    Hello Beginner,

    I'm not sure I understand fully the question. If a timeout occurs the gauge should reset whatever communication it received previously and you will need to resend whatever was sent before the timeout.

    Can you explain the tests they performed? 

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    TI__Intellectual 2221 points

    This is from a bad host who doesn't follow up spec. When host is sending command to read something, time-out could be happened during repeat start section few time. Customers would like to confirm what's our expectation when gauge met this case?

    Actually, I know gauge should reset and host should resend command again. However, what I saw is gauge won't reset and host won't resend too. This is why I need to check if you about our expectation for gauge firstly.  

  • 0 in reply to Beginner
    TI__Guru** 102455 points

    Hello Beginner,

    Can you share logic analyzer captures of the issues you're discussing? It will be easier to look at the actual data and what the gauge is responding with to understand your question.

    The gauge is SMBus v1.1 complaint, so any specifications for timeouts should be upheld.

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    TI__Intellectual 1550 points

    Hi Wyatt,

    According to the customer test results(Here) , TI and the competior seems to have different behavior in that case. So,customers would like to confirm what's our expectation when gauge met this case?

  • 0 in reply to HY
    TI__Guru** 102455 points

    Hello Cheer,

    Thank you for the additional data.

    Let me check with our firmware team which would have a better understanding of the intricacies.

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    TI__Guru** 102455 points

    Hello Cheer,

    I heard back from the firmware team.

    The behavior seen is expected for our device. The reason is that most of our command actually work as separate transactions (write, stop, start, read) instead of the repeated start. That is also why the PEC byte is correct only for the read operation and not the whole write + command transaction.

    When the read is sent it will always pull the data from the last write command, so it can be used as a method to retry the communication. This means if you send the write, and then a read some time later it may not be valid for the present conditions in the register.

    Sincerely,

    Wyatt Keller