• State
  • Locked Locked
  • Replies 13 replies
  • Subscribers 66 subscribers
  • Views 6648 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-R1 SMBUS NACK

user117843334
Prodigy 110 points
Other Parts Discussed in Thread: BQSTUDIO, BQ40Z50

Hello

Sometimes, when I'm doing an smb block read to 0x44, I get a nack on the smbus address. Why ? IIRC, smbus protocol does not allow a device to nack its address.

Here is an oscilloscope capture of the problem:

Thanks for the help !

Philippe

  • 0
    TI__Expert 3385 points
    Hi Philippe,

    Is this delay a fixed delay or is your host allowing clock stretching.

    Best,
    Justin
  • 0 in reply to Justin Erfan
    Prodigy 110 points
    Hi Justin,

    The host does allows clock stretching. It's not super clear on the screenshot, but the low level of the clock is slightly higher than when the host is pulling it down.

    Thanks for the help,
    Philippe
  • 0 in reply to Justin Erfan
    Prodigy 110 points
    I have to add that I'm doing several consecutive SMBUS access. But I'm waiting 15ms between each transaction (bqStudio is more or less doing this also). This problem occur infrequently, but it is quite easy to reproduce over ~100 transactions.
  • 0 in reply to user117843334
    TI__Expert 3385 points

    It's possible that is the problem. You should not attempt to send reads more often than every 22mSec and writes more often than 66mSec for Block Read/Write. Can you try to increase your delay and see if this helps?

    Best,

    Justin

  • 0 in reply to Justin Erfan
    Prodigy 110 points

    Dear Justin,


    I've implemented a wait of 22ms after each smb Block read and it still fail randomly (it seems a bit less).

    Here are the exact access which are triggering this problem (the sleep 22ms is done in order to wait at least 22ms between the start of each cmd. the time to transfert the data is not included into it)

    smbWriteWord(0x0, MAC_DASTATUS1)

    smbReadBlock(0x44)

    sleep(22ms)

    smbWriteWord(0x0, MAC_DASTATUS2)

    smbReadBlock(0x44)

    sleep(22ms)

    smbWriteWord(0x0, MAC_CHARGINGSTATUS)

    smbReadBlock(0x44) [usually fail at this point]

    sleep(22ms)


    smbWriteWord(0x0, MAC_GAUGINGSTATUS)

    smbReadBlock(0x44)

    sleep(22ms)


    smbReadWord(0x14) [charging Current]

    sleep(22ms)

    smbReadWord(0x0A) [current]


    BTW, I'm wondering if this 22ms timeout is not a direct violation of the SMBus specification. The device is allowed to NACK the transfer after the address, but not the address itself.

    Thanks for the help,


    Philippe

  • 0 in reply to user117843334
    TI__Expert 3385 points

    SMBus made simple v6.pdfHi Philippe,

    Is there a delay built into the smbWriteWord command? You need to wait at least 66ms between write commands. I see you do a WriteWord and ReadBlock consecutively. Can you verify if there is indeed a delay?

    In addition I included a useful document called SMBus made simple for your reference.

    Best,

    Justin

  • 0 in reply to Justin Erfan
    Prodigy 170 points
    Justin, I'm having similar issues with the BQ40z450 NACKing it's address... Doesn't happen often, but it's happening.

    Is it absolutely true that you have to wait 66msec between write commands, and if so, where is that in the 40z50 documentation?

    Is this just EEPROM writes (e.g. writing GG during manufacturing), or is this writes to RAM based variables (e.g. changing mAh mWh reporting)?

    A correct response for an SMBus device is to slave-stretch while it processes data or NACK the written data. SMBus allows up to 25msec cumulative stretching for slave devices per transaction.

    An Incorrect response for an SMBus device is to NACK it's address, or have an arbitrary time-out that is not possible to implement in Multi-master situations (how does one master know to wait 66msec after another master?)

    Regards,

    Adrian
  • 0 in reply to Justin Erfan
    Prodigy 110 points

    Hi Justin,


    Indeed, if I implement a such wait it does not fail anymore. But the device access is /very/ slow.

    BTW, according to the SMBus specification version 2.0, section 4.2 (page 19):

    "An SMBus device must always acknowledge (ACK) its own address."

    So it seems that the bq40z50 is not fully smbus compliant.

    Does we have to implement a such wait if we are doing a simple "SBS command" (such as a block read with cmd 0x56 which is identical to a manufacturer access to 0x0056) ?

    Thanks,


    Philippe

  • 0
    Intellectual 380 points

    You have an extra acknowledge from the master on the last byte read in the block, this confuses the firmware as it indicates in a i2c transaction that it will be clocked again to continue reading. Most of the BQXXXXX firmwares can't handle an erroneous ack in a transaction. Some pull the data line low indefinitely, others eventually timeout the transaction. 

  • 0 in reply to Marek Roszko
    Prodigy 110 points
    I'm not sure to understand, but I don't see any extra ack. The last byte read is long because the bq40z50 is doing clock stretching. We have 8 clock pulse, then a long time, and then the ack.
  • 0 in reply to user117843334
    Expert 2475 points
    You could try adding more delay time from the last ACK to the START bit to see whether this helps.
  • 0 in reply to TEC
    Prodigy 110 points
    well, this is a violation of the SMBUS specificaiton.
  • 0 in reply to user117843334
    Intellectual 380 points
    That is the extra ack.

    Per I2C/SMBus, when you have the master reading, the master gives ACKs on each byte to say "continue" to the slave. You are giving it an ACK on the last byte you read, this tells the bq40z50 to expect the master to read again. Unfortunately due to BQXXXXX firmware bugs, they never seem to handle the extra ACK properly (i.e. time it out).

    Per I2C, you are not supposed to acknowledge the final byte you read.