• State TI Thinks Resolved
  • Locked Locked
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 64 subscribers
  • Views 798 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.

BQ40Z80: BQ40Z80 SMBUS

Star Xu
Genius 9645 points
Part Number: BQ40Z80
Other Parts Discussed in Thread: EV2400

Hi

EV2400 were collected as shown in figure is the use of logic analyzer, read the smbus BQ40Z80EVM plate sequence diagrams.

why can the first reply immediately that is soon, and the second reply (red frame) but have to wait so long to reply, the third, four, five, why wait for a period of time after the reply for the next byte read, the last stop is the same why wait for a period of time just stop?

Waiting for your reply.

Thanks

Star

  • 0
    TI__Genius 12215 points

    Hi, Star

       The first byte is the address of the gas gauge, the reply, which I think refers to acknowledge, is generated by the I2C engine of the gas gauge, no FW intervention is required. So there is not delay for this.

       The following byte is the command of the transaction, the I2C engine of the gas gauge needs to raise an interrupt and await the FW to fetch and interpret and decide what to do next. before the FW in the gauge can make any decision, the I2C engine of the gauge pulls down the SCLK of I2C. When FW in the gas gauge think this is a valid command, the gauge would acknowledge the command, at this moment, the gas gauge release the SCLK signal, you will see a rising edge on SCLK at this moment. meanwhile, gauge also pulls down SDATA. when host(EV2400) see this, it takes it as acknowledge, and pulls down the SCLK so as to start next frame which starts with Repeat Start pattern. As it always takes longer time for the FW in the gauge to check and validate the command, you will see the wait time longer than the previous one to acknowledge the I2C address byte.

       The 3rd byte indicates this is read operation, the following bytes on the SDATA are sent by the gauge at the rate of the SCLK signal generated by host(EV2400), the acknowledge bits of the following bytes are generated by EV2400, as this is only read the 8 bit frame, not validation is needed, the acknowledge bit is just given by the I2C engine at host side, FW intervention is not needed as well under this scenario. so there is not delay for acknowledge bit.

       But MCU in EV2400 needs to put the byte received by I2C engine to the buffer for the FW to read and process, the EV2400 will be able to read next byte after this is done, EV2400 would pull down the SCLK until the byte in the I2C engine is fetched by the FW. This is why you see the EV2400 wait for a while for the next byte read until the end of this transaction.