Post Go back to editing

Unable to establish I2C communication

Category: Hardware
Product Number: MAX17320G22+, MAX17320

Dear Team,

1) We have designed a battery management system using MAX17320G22+ as per the EVK for a Drone Sub-system. We tried to read some parameters like device name, manufacturer name etc. But we are unable to establish communication with the IC over I2C. we were using an external controller for the purpose. also we tried to run an I2C Scanner application from Raspberry Pi. Even that was not working.   

2) Also when batteries were connected to BMS, we are able to measure the voltage across the drain of charging MOSFET, but unable to measure any voltage across the PACK+ and PACK-, meaning that the charging MOSFET is turned ON when the BMS is connected to the cells, but the discharging MOSFET is not turning ON.  

Can someone help us find out where we went wrong?

Please help us resolve this issue ASAP.

Thank you.   

Parents
  • When the batteries are properly connected, then communication or a charge source connection at PCKP will wake the device up.  The REG2/REG3 pins are a good sign of life from the IC.  When the IC is powered up, this will have 1.8V/3.4V respectively.

    What battery voltage is measured at the BATT pin?  

    If the REG2/3 pins show the device is active, can you can all I2C addresses to confirm if any are responding?

    Have you tested your communication on the EVKIT hardware?

    Thanks

    Jason

  • We are using 3.7V x 4 Li-Po batteries and measuring 14.8V across BATTP and BATTN.

    Also we are able to measure 1.8V across REG2 and 3.4V across REG3 respectively.

    We don't have the EVK on hand, so we did  not test it on EVK but the schematic is designed referring the EVK schematic. 

  • It sounds like the MAX17320 is properly powered.  Can you measure the voltage at the CHG and DIS pins and the respective gates of the FETs?  Is the voltage at the CHG/DIS pin properly reaching the gate pin of the FET?

    Are you able to get any scope shots of the communication so we can see if that looks ok?

Reply
  • It sounds like the MAX17320 is properly powered.  Can you measure the voltage at the CHG and DIS pins and the respective gates of the FETs?  Is the voltage at the CHG/DIS pin properly reaching the gate pin of the FET?

    Are you able to get any scope shots of the communication so we can see if that looks ok?

Children
  • CHG Pin measures 16V and DIS Pin measures 2.4V both at IC Pins and FET Gate pins.

    We are able to establish communication only after connecting host controller ground to CSP but as per the EVK schematic host controllers ground should be connected to CSN (SYSN) 

    Isn't this violation to the EVK schematic? because now the host controller is directly connected to the battery ground(BATT-) and not to the PACK- as shown in the EVK schematic.

  • The Sense resistor should be the only difference between the BATT- and SYS- terminals.  Communication can typially occur with gnd at either terminal, but for proper current measurement, the proper connection on either side of the sense resistor is required.  I would recommend verifying the sense resistor is connected correctly and perhaps reflow the connection of the sense resistor.

    When you are able to communicate, are you able to read all of the registers correctly?

  • The BATT and PCKP register values when calculated are correct, but individual cell voltage and average voltages seems to be wrong.

    Regarding the ground,

    We have tested on 3 PCB's, all showing same behaviour and both grounds are showing continuity when checked.

  • If the cell voltages are incorrect, then the device may be opening the DIS fet to protect from UVP.

    What are the cell voltages reading?

    Does the ProtStatus register indicate there are any protection faults?

  • This is what we read from the IC. The displayed values are not byte-swapped, while checking 16bit data, byte-swapping is needed.

    We tried to set the DISs bit of HProtCfg2 register to turn on the DIS FET, but write operation didn't reflect when read back.

    Isn't the DIS FET should be ON by default?

  • ProtStatus shows the TooColdC bit and the UVP bits are set.  If UVP is set, then discharging is disabled and DIS pin will be low.

    Your Cell voltages are showing only Cell 2 is being read correctly 0xB871 = 3.688V, but all the other cells are reading 0.  If any cell voltage is below the UVP threshold, then the UVP bit will be set and the DIS fet will be opened to prevent any additional discharge.  I'd start by verifying your cell voltage connections and getting those readings to be reflected properly by the IC.

  • We checked the individual cell voltages and at the pin level too, the voltages are same on both sides and all are above 3.3V. But the values in registers are not updated. 

    Also we tried to  some modify register values and even they are not getting updated, as shown.

      

    I'm attaching the scope screenshot for writing operation of hProtCfg2 register for your reference.

  • Write protection is enabled by default and must be disabled before you are able to write any register

    hProtCfg2 should be read only.  Writing this register should not change the state of the DIS pin.

    if nPackCfg=0x0500 then it is configured for 2 cell.  

    Have you configured the NVM with all of your desired settings or does it still contain the default values?

  • Thank you for supporting. Now, we are able to write into the registers.

    Also, all cell readings are getting updated now, after changing the NCELLS value in nPackCfg Register was set to 4 from its default value 2.

    But now we are stuck in reading manufacture name, device name etc, from SBS read block registers. As per the datasheet the value has to be in  ASCII Format. but we are getting some data which cannot be converted to ASCII Format. For Reading from SBS block, I'm using 6Ch as the device address and I had set nNVCfg0.enSBS Bit also. Can you please point me out what I'm missing?

  • The SBS registers are all read on the 0x16 Slave address.

    Also, all of these values must be initialized when you initialize the NVM, otherwise, they will have the default to 0x000