• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 2 answers
  • Subscribers 63 subscribers
  • Views 455 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

BQ40Z50-R3-DEVICE-FW: Occasional PEC Byte Errors in SMBus Communication

BQ40Z50-R3-DEVICE-FW: SMBus Idle Condition (Leads to PEC Errors)

Eric Castle
Intellectual 710 points

Part Number: BQ40Z50-R3-DEVICE-FW

Hi Eric,

I have returned to this issue again. Initially I had thought that your reply made sense. However, with more reading of the SMBus specification and looking at additional data captures, I think I disagree with your argument.

1) If I understand you correctly, you say that the fuel gauge thinks that the bus has violated the Thigh-max requirement (50 us). However, I do not think that Thigh-max applies to a repeated start. In "Smbus110.pdf", section 8.1: The table lists minimum repeated start condition setup time (Tsu:sta) and minimum hold time after repeated start (Thd:sta), but lists no maximum time for these values. Figure 8.1 also shows the clock being higher longer than Thigh-max during a repeated start.

2) I think a bus idle condition requires both lines to be high for > 50 us. Why? Unfortunately the 1.1 spec isn't super helpful on this. I see the following statements:

a) 3.2: The bus becomes free again after certain time following a STOP condition or after both the SCL and SDA lines remain high for more than 50 us.

b) 5.2: The bus is free after a STOP condition or after the SCL line remains high for more than tHIGH, MAX. [Does not mention SDA status, so somewhat ambiguous]

So which is it? I think that the first statement is pretty clear, whereas the second statement does not discuss SDA (so it could just be assumed to be high here still). Additionally, the 2.0 (and later) versions of the specification all specifically say that bus idle requires both lines to be high, so I think the second statement was an unintended ambiguity in the 1.1 version. 

Thoughts?

Thanks,

-Eric Castle

  • 0
    TI__Guru** 105760 points

    Hello Eric,

    I believe the 50us spec may have been used in the communication engine (not using both SDA and SCL). I will check with the team and get back with you.

    Sincerely,

    Wyatt Keller

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

    Hello Eric,

    It is only the SCL line that is looked at for the timeout.

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    Intellectual 710 points

    Hi Wyatt,

    Ok, that's really good to know! That would explain the problem that I'm having working with this charger (my application is required to be compatible with it).

    The charger tends to keep the clock line high for ~90-95 us during a repeated start (but only high with SDA for ~50 us). See the picture below. As I stated above, I think the charger's behavior is allowed under the SMBus spec. 

    Some follow-up questions:

    1) Does the communication engine have a 64 us timeout for SCL being high? 

    2) Is this communication engine in firmware or in hardware? 

    3) If firmware, could TI make a custom version that looked at both the SDA and SCL lines being high for > 64 us? Or a custom version with a longer timeout for SCL? (say > 100 us) 

    4) Alternatively, do older versions of the firmware behave differently in the communication engine?  

    5) Might other TI fuel gauges behave differently with this? (e.g., BQ40Z80)

    Thanks,

    -Eric Castle

    Note that the overlap between SDA and SCL being high during the repeated start is ~50us.

  • 0 in reply to Eric Castle
    TI__Guru** 105760 points

    Hello Eric,

    After the 50us T_high time for SCL it will cause the errors, there are no other timeouts besides those in the datasheet.

    The communication engine involves both hardware and firmware, I don't believe the 50us is a firmware specification. We can only do minor changes in firmware.

    I believe all the multicell gauges have the same communication engine and similar specs.

    Sincerely,

    Wyatt Keller