• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 64 subscribers
  • Views 1141 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.

BQ40Z50-R2: SMBus read word specification not met

Akash Gujarati
Prodigy 80 points
Part Number: BQ40Z50-R2
Other Parts Discussed in Thread: BQ40Z50, BQSTUDIO

Hello,

I noticed some odd behavior when trying to read data from the fuel gauge.

Following the SMBus specification, a read word operation has no stop between the write and the read i2c operations. If I use this protocol, the fuel gauge returns bad data often. Sometimes the data makes sense but other times it is garbage.

 NO STOP - READ WORD - PASS

 NO STOP - READ WORD - FAIL (Bad data)

However, if I break the protocol and insert a stop between the write and the read operation, then the fuel gauge consistently returns the correct value.

 WITH STOP - READ WORD - PASS

Is there a bug in the bq40z50 implementation of the SMBus protocol?

  • 0
    TI__Guru* 76230 points
    Akash
    I am not a comm expert, but if you found a way to get it work by breaking it up what else is the issue here?

    thanks
    Onyx
  • 0 in reply to Onyx Ahiakwo
    Prodigy 80 points

    I would like to design a deterministic system that works as expected so it would be valuable for the expert at TI to confirm that what works is how the device was designed to work. The documentation states that the SMBus specification is followed. So either the fuel gauge has a bug in its implementation; the documentation needs additional information about the deviation from the SMBus behavior; or my understanding of the specification is wrong. Either way, this issue needs some resolution.

    I'm a bit surprised at how frivolous your response is. I would think that if there is nothing useful to contribute then maybe just don't respond?

  • 0 in reply to Akash Gujarati
    TI__Expert 6575 points

    Hi Akash,

    From the logic analyzer captures, the only anomaly I see in the failed transaction is that there is an extra clock pulse on the failed read.

    However, I also see some other differences when I use bqStudio and look at the signals (apart from the PEC).

    I see a distinct ACK compared to what you are seeing.

    The extra clock pulse can definitely cause an issue in reading out the correct value.

    To debug the issue, I would recommend looking at the same transaction using bqStudio, vs your standard host. I would ignore the PEC part of the transaction using bqStudio.

    I am also attaching an application note on SMBus for reference6562.SMBus made simple_v6.pdf

    Please let me know if this helps resolve your issue.

    Regards,

    Swami

  • 0 in reply to Swaminathan Ramanathan75031
    Prodigy 80 points
    That is a really good catch, Swami! I totally missed the extra clock. I don't know what is causing it but I'll take a look at this on the scope to make sure that it isn't an artifact of the logic analyzer. Although, the coincidence is too much to believe that this comes from the logic analyzer.

    Thanks for your help! I will close this for now and if I can't get the problem fixed on my side, then reach out on the forum again.
  • 0 in reply to Swaminathan Ramanathan75031
    Prodigy 80 points
    Just to tie up all loose ends. It turned out that the problem was with the microcontroller that we were using. The i2c block puts out a tiny clock (~0.6us) after a clock stretch which is really problematic with a 100 kHz clock (Basically, the i2c block did not handle clock stretching correctly). The fuel gauge doesn't see that first clock so everything is offset by 1 clock on the fuel gauge causing the problem that was seen.