Does the MCC 152 prevent I2C communication outside its address space?

[Display Name]

I have two MCC 152s at 0x20 and 0x21. I also have a varying number of devices between 0x58 to 0x5F. I can see the MCC 152s just fine. However, I cannot see the other devices. When I connect to these device on an identical raspberry pi without the MCC 152s (same SD card image on CM4 with RPi I/O board without the HATs) I can see the the 0x5* devices. Why would the DAQ HATs prevent me from seeing these other devices if the addresses do not conflict? The 0x5* devices are at 3.3 V and the HATs are also set to 3.3 V. The 0x5* devices are connected directly to GPIO2, 3, and ground pins via shielded CAT6 cable.

[Display Name]

@Fausto I figured it out. Clock speeds for the devices were mismatched. The solution was to run a second I2C bus on GPIO pins 17 and 27. For anyone encountering this issue, see below for details.

The MCC 152 datasheet specifies an I2C clock speed of 400 kHz (see screen shot below):

My other devices are 5 kW, XP Power HPT5K0TS048 power supplies. The communication specification indicates a clock speed of around 100 kHz (see screen shot below).

 

This clock speed mismatch is my best guess as to why the HATs prevent me from communicating with my 5 kW power supplies. I still believe that, for the same clock speed and different address spaces, the HATs should *not* prevent communication to devices outside their address spaces, so long as the bus is small enough for the RPi to drive it. However, MCC has yet to confirm this.

In any case, the steps to setup a second I2C bus are fairly simple. These steps are as follows:

First, read the informational file within Raspberry Pi OS at /boot/firmware/overlays/README. Overlays are firmware level specifications to modify and set hardware functionality on boot. The relevant overlay for a second I2C bus is described by the `i2c-gpio` overlay:

Name:   i2c-gpio
Info:   Adds support for software i2c controller on gpio pins
Load:   dtoverlay=i2c-gpio,<param>=<val>
Params: i2c_gpio_sda            GPIO used for I2C data (default "23")

        i2c_gpio_scl            GPIO used for I2C clock (default "24")

        i2c_gpio_delay_us       Clock delay in microseconds
                                (default "2" = ~100kHz)

        bus                     Set to a unique, non-zero value if wanting
                                multiple i2c-gpio busses. If set, will be used
                                as the preferred bus number (/dev/i2c-<n>). If
                                not set, the default value is 0, but the bus
                                number will be dynamically assigned - probably
                                3.

Specifically, I need to add the following line to /boot/firmware/config.txt to create another I2C bus on GPIO pins 17 and 27 (modify pin numbers and bus number to suite your needs):

dtoverlay=i2c-gpio,i2c_gpio_sda=17,i2c_gpio_scl=27,bus=3

Note that I do not need to specify the clock speed, as the default is around 100 kHz (which is what I want for my power supplies). Moreover, it is unclear if line order matters in the config.txt file. I put my dtoverlay configuration right below the main default I2C and SPI activation portion of the file.

The new bus is implemented on reboot, and you should see another I2C bus at /dev/i2c-3 in addition to /dev/i2c-1 (along with the lower level EEPROM I2C buses).

Second, you will need to add your own pull-up resistors to the pins you choose to use for the second I2C bus. I used 1.8 KOhm resistors between the pins and 3.3 V. The Pi-EzConnect HAT by Alchemy Power makes soldering in through-hole resistors very easy. I chose 1.8 kOhms because that is what is used on the dedicated I2C bus on GPIO pins 2 and 3.

Now, I can scan both buses and see the MCC 152s on bus 1 and the 5 kW power supplies on bus 3.

I am interacting with the 5 kW power supplies via the Python smbus2 package. To do this, I simply specify bus 3 when instantiating my SMBus() object.

 

[Fausto]

Hello @Display Name.

The MCC 152 uses the I2C interface pins (GPIO 2 and GPIO 3); MCC 152 Electrical Specifications.  

Other mounted HAT boards cannot use the I2C interface pins if a MCC 152 is mounted on the Raspberry Pi.

Regards,

Fausto

[Display Name]

@Fausto thank you for the reply. Yes, I know the MCC 152 uses GPIO 2 & 3 for I2C. My question is why do they prevent the entire address space from being communicated with. Not communicating/reserving 0x20 through 0x27 makes sense. Preventing all communication on addresses outside the MCC HAT space does not make sense to me. Any guidance/info/further reading on this matter would be greatly appreciated. Thank you!

[Fausto]

@Display Name,

What are the outputs when you run the following command with the MCC 152 only, with the other board(s) only, and with all HAT boards mounted on the RPi?

i2cdetect -y 1

Thank you.

[Nick Wright]

@Display Name The 152 should not interfere with other devices using the I2C bus on GPIO2/3 unless they happened to use the same I2C address as the 152.  The I2C components on the 152 support up to 400 kHz, but we do not change the I2C speed from the default value in the library so it is likely running at 100 kHz.  

It is possible that the extra bus capacitance of having the 152s along with your devices is slowing the edges enough to have issues.  Are you using any additional pull-up resistors on SDA / SCL?  You could try capturing the I2C comms on a scope in both scenarios to see the difference, and adding additional pull-ups may improve the communications.