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: Failed to estabilish connection between BMS and Arduino Uno Board

Part Number: BQ78350
Other Parts Discussed in Thread: BQSTUDIO,

Hi everyone, 

I have been working with this BMS for two months now, but I can't even get the connection between the BMS system and any MCU. I previously tried to establish the communication using an STM32F407 board without any result. I used the function HAL_isDeviceReady() to check the address of the BMS (which should be 0x16/0x17 according to the datasheet), but the board didn't recognise any of address.

I gave up on that and I started using the Arduino Uno board, thinking that it would be much easier. I was wrong. I still have the same problem. I created a code to check whether the board sees that any slave address is connected to any of the possible 128 addresses but the board doesn't recognise anything. Actually as soon as I connect the BMS data line the Serial port freezes and only prints a few characters. The Arduino code that I am using is shown below.

Can someone help please!!

P.S. I must mention that both the HAL_isDeviceReady() and the Arduino code that I wrote work with any other I2C device that I have tested.

#include <Wire.h>
//#include <inttypes.h>
//#ifdefined(ARDUINO) && ARDUINO >= 100

//#include "Arduino.h"
/*
#define printIIC(args) Wire.write(args)
inline size_t CheckAddress::write(uint8_t value) {
send(value, Rs);
return 1;
}*/
 
void setup()

  Serial.begin(2000000);
  Wire.begin();
 
 
  Serial.println("\nI2C Scanner");
  //while (!Serial);             // Leonardo: wait for serial monitor
  //delay(1000);
}
 
 
void loop()
{
  byte error, address;
  int nDevices;
 
  Serial.println("Scanning...");
 
  nDevices = 0;
  for(address = 0; address < 127; address++ )
  {
    Serial.print("Scanninng address");
    Serial.println(address);
    // The i2c_scanner uses the return value of
    // the Write.endTransmisstion to see if
    // a device did acknowledge to the address.
    Wire.beginTransmission(address);
    error = Wire.endTransmission();
 
    if (error == 0)
    {
      Serial.print("I2C device found at address 0x");
      if (address<16)
        Serial.print("0");
      Serial.print(address,HEX);
      Serial.println("  !");
 
      nDevices++;
    }
    else if (error==4)
    {
      Serial.print("Unknown error at address 0x");
      if (address<16)
        Serial.print("0");
      Serial.println(address,HEX);
    }   
  }
  if (nDevices == 0)
    Serial.println("No I2C devices found\n");
  else
    Serial.println("done\n");
 
  delay(5000);          // wait 5 seconds for next scan
}

  • Hi Gianmarco,

    I can see this is a very frustrating situation.

    See the application report SMBus Made Simple, it may be helpful.  Remember that the address 0x16/0x17 is the address on the bus.  When entering into your tool you may need to use the 7 bit address 0x0B with the read/write separate.  

    On your code, I'm not an Arduino or STM programmer.  Have you checked with Arduino forums or examples?  Lockup of the serial port may need reference to the port provider's documentation.

  • WM5295 said:
     When entering into your tool y

    Hi WM5295, thanks for your reply.

    What do you exactly mean by 'entering your tool'?

    By the way I am already using the 7 bit address and I change it depending if I need to read or write (e.g. readfunction(address|1) ).

    I have also used the examples found online (there are many of them) but none of them works. I beginning to believe that it's a hardware issue. Even tho the BMS works when using bqstudio via the EV2300.

  • Hi Gianmarco,
    I meant whether your tool uses the 7 bit address with read/write separate or the 8 bit address. It sounds like yours uses 7 bit.
    If bqStudio will talk to the gauge it sounds like the gauge works. I hope you can find the MCU issue.
    You should be able to put a scope on the bus and see the gauge ACK the EV2300 communication due to a bqStudio read, then compare the result from the MCU. The clock speed will be different of course, but the message structure should be the same.
  • Hi WM5295,

    Thanks again for your reply. I am trying to work out what the error from the MCU could be and I found a document explaining the most common problems with SMBus. It includes 10 possible issues, but I have excluded most of them and narrowed  it down to:

    2. Clock high time: This is one of the more common overlooked problems. The clock must be high for less than 50 µs during the middle of a communication packet. This rule has no exceptions. If the clock is high longer than 50 µs, then the SMBus engine on the slave most likely times out.

    3. Communicating too fast: This is common when using an I²C hardware engine to perform the SMBus communications. The SMBus engine is only specified at 100 kHz. Communicating faster than this causes timing minimum rules to be violated.

    4.Broadcast or other collisions: In most TI advanced fuel gauge solutions, slave broadcasting (sometimes called master mode messaging) is disabled by default. This problem has been greatly reduced in recent years. Because most hosts or chargers do not accept broadcast messages, it is good practice to disable them if they are not being used.

    Could any of these be the problem? If so how can I check if it is and most importantly how can I solve it?

    Thank you.

  • Hi Gianmarco,
    For #4 I expect broadcast is off. I don't turn it on and have not seen a broadcast from the bq78350. It is probably off unless you have turned it on.
    For #2 and #3 you will need to look at the bus with an oscilloscope. Compare the timing to the values you note, and to the data sheet, and the structure to the SMBus Made Simple apnote linked in the earlier post. Your oscilloscope may be able to decode the bus transaction to give you more insight on the activity.
    I don't know we specifically stated it before, but be sure the bq78350 VCC is powered (~ 2.5V) and can talk to its bq769x0 monitor. The values from the monitor are critical to the operation of the bq78350 and if it does not find the monitor it will spend most of its timeline trying to find it. SMBus communication will be intermittent in this situation.