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

BQ76952: I2C Communication errors / Communication error received over time

Ali Batuhan Demirci
Prodigy 70 points
Part Number: BQ76952
Other Parts Discussed in Thread: EV2400,

Hello, TI Experts,

We have a custom board and there is a MCU that can communicate with IC via I2C. In the first communication with the IC we often get timeout errors (NO ACK). However the communication is successful afterwards. But it still does not mean that the system is communicating in a healthy way. Because we keep logs with the MCU (Stm32F0xxx) and we observed that communication errors are repeated in these logs. The images regarding the error we experienced when we first communicated with the IC are as follows.

Error-free communication on the same data

We also have standalone board (NOT EVM) and we kept log with EV2400. We observed failures in communication there. Some rows (like temp, Cell 1 voltage etc.) was missing.   

Some information about IC,

  • 0
    TI__Guru 54715 points

    Hi Batuhan,

    From the waveform it looks like you  are sending command 0x68, internal temperature.   The BQ76952 will clock stretch commands if needed if it was busy with another task or to get the data.  When the part NACK'd it apparently did not understand the command.  Check to see if some other command was sent prior which might have the part busy.  Also check the analog signal integrity of the bus to see if there could be data errors.

    The EV2400 is typically slower than an MCU.  If you log too much data it can overrun the timeline and you will get missing values in the log or sometimes missing rows.

    The display shows version 0.18 of the EV2400.  We do recommend the newer firmware version of EV2400, see the tool folder for an installer.

  • 0 in reply to WM5295
    Prodigy 70 points

    Hi WM5295,

    First of all Thank You for your comment, 

    Yes, As you said we send Command 0x68 in the First communication, so we does not send any command before this. 

    By the way we tried both types of commands (Sub and Direct Command) and than we started with the direct command, because we thought it would be easier. 

    Data line looks fine, and obviously the slave did not send the ACK when it released the clock line. So that the slave ignores this.

    if possible I want to ask a question,  when we send a subcommand to the slave, it takes some time to execute the requests of that Subcommand, right? And according to TRM, we know through inquiry whether a request is ready or not.The slave can respond when busy in this case. In what situations the slave cannot answer? 

  • 0 in reply to Ali Batuhan Demirci
    TI__Guru 54715 points

    Hi Batuhan,

    I clicked the wrong button, there may have been some status changes.   

    I agree direct commands should be simpler. Command-only commands are simpler still.  Do you have errors with those also?  With a direct command the part will clock stretch until it can reply or ack.   

    I can't duplicate your observation, the part will frequently strech the clock but pulls down SDA when releasing the clock so that it acks the command. The EV2400 then sends the read address and clocks out data.

    Updating the EV2400 is also recommended. Here is a link to a newer one than in the tool folder: https://tidrive.ext.ti.com/u/hFkU19bZFNWWWRTW/EV2400Updater-0.32-windows-installer.exe.zip?l 

    Be sure to look at the waveforms with a scope, it can show detail missed by the Saleae.  Signal integrity is the most likely cause of communication problems.

    The BQ76952 TRM indicates the processing time for subcommands in table 9-2.  If the device does not understand the command it does not answer.