INA226: Issue with addressing 16 chips on the same I2C bus.

Jaakko,
Are you using resistors between the Address pins and the SCL, SDA, VS or GND pins? We prefer direct connections.
Also, I'm a little confused - are you saying that when you send the address 0x48 on the bus, the device at 0x4c responds?

I'm not using series resistors on A1 and A0, directly connected to the pins. When I scan the whole bus for I2C addresses, I get only the addresses which are marked with green on the table. Eventhough I have all the 16 ICs soldered on the board.

So on the table the Addr column tells the I2C slave address (from datasheet) with that A1/A0 configuration. Addr found on BUS column tells which address was read (scans all the I2C bus addresses and sees which respond) from I2C bus when only that particular device with that A1/A0 configuration was connected on the bus.

When for example I send address 0x48 on the bus, there is no response. When I address 0x4c, some IC responds (not sure which one). For some reason the ICs which have SDA or SCL connected to either A1 or A0 do not get their address right. Could there be something wrong with the linux I2C communication timings which is causing the ICs not locking their address correctly?

I could try to test the circuit with e.g. Arduino to see if it's the linux setup which is causing the issues.

thanks,
Jaakko

Jaakko,

I would suggest to narrow down the scope of the debugging efforts by focusing on one part at a time.  If you can, test each part individually, with no other parts on the bus.  Or change the address of one part to all possible addresses and make sure your controller can talk to it with every address.

If you suspect something is up with the I2C communication - you might take an oscilloscope and check that the SCL and SDA lines are showing you what you're expecting.

As for isolating which part is responding when you send a command, try forcing a bus voltage to just one device and see if it returns the appropriate codes for that bus voltage.  If you do them one at a time, you can track down which ones are responding, and to what.

Also, if your pullup resistor on the I2C bus is too small or too large, it could affect communication.  If this is a potential issue, or perhaps the master can't drive 16 parts simultaneously (it probably can, but who knows), then adjusting the pullup larger or smaller may help.  Also, try running the I2C bus speed at 400kHz or less, or even different speeds to make sure that's not the issue either.

I would suggest to narrow down the scope of the debugging efforts by focusing on one part at a time. If you can, test each part individually, with no other parts on the bus. Or change the address of one part to all possible addresses and make sure your controller can talk to it with every address.
-This is what I did. Had only device at a time connected to the bus and checked the address it is responding. The table corresponds to that.

No chance you have an INA226EVM? Always good to start with a working setup, plus you can separate the controller from the INA226 board and test each subsystem separately.

If I recall correctly, the device address is determined at the start of each i2c transaction. It might be good to see if there are any noisy transients or artifacts on the bus lines. It's highly suspect that the addresses that work best for you are the ones that tie to stable voltages like gnd and vs.

Unfortunately I don't have the EVM. I have some Arduinos and STM32 EVkits so I'll try with those to see if I can see all the correct addresses (better control for the I2C bus from MCU than from Linux environment).

There might be some noise on the lines also.. need to scope more thoroughly the I2C line.

Thanks,
Jaakko