• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 64 subscribers
  • Views 2450 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.

BQ78350-R1 - SMBus HostFETControl bytes are NAK'ed randomly

Erik Trauschke
Prodigy 50 points
Other Parts Discussed in Thread: BQ78350-R1, BQ78350

We are building a battery system which uses battery packs with a BQ78350-R1 controller. Accessing the SMBus registers in these batteries works fine except for the HostFETControl register (0x2b) which seems to randomly not acknowledge bytes sent over the SMBus. We are using an LPC1769 uC as SMBus master.


In general the access to HostFETControl works fine, however, from time to time we see that only 1 or 2 bytes of the 3 we are trying to send in (e.g. 0x2b 0x97 0x11) are acknowledged by the SMBus slave. We monitored the bus using a logic analyzer and it clearly shows that no acknowledge bit is sent by the slave before the transfer times out after around 25ms. If we immediately repeat the transmission it will succeed within 1 or 2 tries.

What we tried is to add wait cycles between two requests to the bus and lowering the clock speed to 10kHz but that didn't help.


So I'm curious if someone has seen this issue before or has any idea about what we might do wrong and would trigger such behavior.

Thanks

Erik

  • 0
    Mastermind 8415 points
    Hi Erik,

    Have you tried being less stringent on the 25ms? (The SMBus requires to put a 25ms timeout).
    We've had problems with communication with the BQ78350 until we changed the timeout delay to 26ms.

    The documentation also mentions that you need at 2ms between each transmission (but you seem to have already got that covered).

    Otherwise, check your signal with an oscilloscope to make sure it is clean.

    Michel
  • 0 in reply to Michel Solecki
    Prodigy 50 points

    Hi Michel,


    Thanks for your response. I don't seem to be able to actually change that timeout from the host end and looking at the I2C documentation the slave is doing "clock stretching" at that point, holding the clock low until it is ready. The master is supposed to wait until the clock comes back up high before it does anything else. When the slave finally releases the clock line it signals NAK, which seems more like an internal timeout in the BQ78350.


    Wrt. the signal quality I'd find it surprising that we only have issues with this one command, since it works fine with any other command.
     I'll have a look at it anyway but I'm doubtful I'll find something.

    Erik

  • 0 in reply to Erik Trauschke
    Mastermind 8415 points
    Hi Erik,

    The 25ms timeout is handled by the master (this can be done by the I2C hardware in the IC or software with timers). The master starts a timer after every byte and waits 25ms for the ACK or NACK. If the slave is holding the line low for longer than 25ms, than the master should reset its state machine (this might include resetting its peripheral) and wait for the SCL and SDA lines to return to high.
    In our case, we had to make that delay longer because the BQ78350 seemed to take a little bit more time than the specified 25ms for SMBus.
    Do you have a timer to handle the timeout? If so, you should be able to control the delay. If you don't, then it's definitely not an issue with the timeout.

    Do you actually see the clock stretch?
    I don't have the BQ78350 ready for testing, but from what I recall, the only time we saw clock stretching was during a read operation (right after the repeated start).

    Have you tried connecting the BQ78350 with BQ Studio? Do you have the same behaviour? Have you looked at the lines with the logic analyzer while it's tranmitting data with BQ Studio?

    Have you tried with another board? We've also have issues with the BQ78350 not working during development for unknown reasons and fixing the problem just by switching the IC.

    If none of those tips help, you'll have to wait for somebody from TI to look into this.

    Michel
  • 0 in reply to Michel Solecki
    Prodigy 50 points

    Hi Michel,

    I looked through the I2C code in LPCopen (the library we use for the uC) and it doesn't look like it implements a timeout.  It could be that the I2C hardware does that but I couldn't find any info about that in the documentation.

    Wrt the clock stretch it's hard to know who is pulling the clock low but I can clearly see that after the 8 bits got clocked out, the clock line stays low for 25.5 ms and then goes up while the data line stays high. Then it seem like the master takes over again. I created a screenshot of the logic analyzer output and put it here:

    The middle part where nothing happens is left out to make it easier to see what's going on.


    We haven't tested with BQ Studio since we ourselves don't do development on this level, so we don't have the necessary HW for this. We are just using commercial packs which have this controller and just thought this might be a better source of information than the vendor.

    We've seen the issue with two different boards but both of which have the same uC. However, since we only seem to have issues with this one register I'm doubtful that this would be the issue.

    Thanks

    Erik

  • 0 in reply to Erik Trauschke
    Prodigy 50 points

    Just as another data point I hooked up an Arduino which just issues I2C commands to register 0x2b and I can see exactly the same thing happening. The logic analyzer output is also exactly the same, the clock gets stretched for 25.5ms then it comes back up sending a NAK. So I'm fairly convinced that this is not a host issue.

  • 0 in reply to Erik Trauschke
    TI__Guru 73830 points
    I have not had an issue with a delay between issuing the HostFETControl enable command and the FET on/off register selection, but I have not tried using a host to send them with minimal delay. The gauge does have to communicate with the AFE, so there could be some delay necessary. There is a delay requirement, if you send a command to change one FET and then a command to change the other. You have to wait for 4s. You can change all of the FETs with one FET on/off register transmission. I have had one customer experience a communications issue when trying to read the Operation Status register too quickly to see whether the FETs changed state. I think that we recommended that he wait for 250ms before reading the register.
  • 0 in reply to ThomasCosby
    Prodigy 50 points

    Hi Thomas,

    Thanks for your reply. The problem we are seeing is not related to a delay between the enable and the actual control command. In fact, most of the time we see this issue when trying to send the access code (enabling the command). We do see the delay between issuing the FET control command and when we can send the command again. But this we also have no issue with since our code doesn't change the FET status that quickly anyway.

    What we are concerned with is that initial requests to the 0x2b register (sometimes hours after we sent the last request to 0x2b) fail with a much higher likelihood than requests to any other register we tested. We see about a 2-3% failure rate when accessing these registers even if we use a 5s delay between cycles. That's what we are curious about.

    Thanks

    Erik