Unable to establish I2C communication

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?

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?

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

Thank you so much for supporting, all these problems are sorted out with your support.

We have brought two USB-I2C adaptor from two different make, one from Waveshare and another from www.amazon.in/.../B0BLKDX6LF.

We are trying to establish communication between model gauge configuration wizard application downloaded from ADI page and our custom board using these adaptors, but the application is showing NO USB ADAPTOR.

So, can you please suggest a way to establish communication between the application and our BMS Board???

Thank you so much for the support. We have sorted out all these.

We are using two USB-I2C adaptor one from Waveshare and another from Spiffysky. We tried these to establish communication between model gauge Configuration Wizard and our custom board. But the application shows NO USB ADAPTOR. It seems that the Application is not detecting the converter itself. But  the device is recognised in the device manager.

Can you please suggest a way to establish communication between the Application and our custom board using any of these converters.

Spiffysky USB-I2C adaptor

Waveshare usb to I2C converter

Application Window

Device Manager

Connection Setup

I'm glad we have been able to overcome all of your initial issues.

The EVKIT GUI is designed to interact with the FTDI chip that we have on our EVKIT board.  I can't provide any insight into using any other USB to I2C adapters.  The best method for you to use the EVKIT GUI would be to order our EVKIT hardware and connect it to your PC.  The EVKIT hardware then has some test points and a header that you can use to connect over to your system.