Why does I2C voltage changes when activating eth0 network interface ?


Everything is validated on our IMX6UL, but we are facing a problem with I2C3.

With IOMux, we activated I2C3 with pads SCL W17 and SDA W19. Each routed with a pull-up 2.2k resistor, to 3.3V.

While validating I2C with a simple slave, we discovered that the I2C voltages SDA and SCL were falling down when we did “ifconfig eth0 up” rising back to normal when we did “ifconfig eth0 down”.

The I2C communication was very noisy and unusable when the eth0 interface was up.
We tried again without any slave connected, just monitoring the SCL and SDA voltages, and the problem was still present.

Here are the concerned portions of the device tree :

&i2c3 {
pinctrl-names = “default”;
pinctrl-0 = <&pinctrl_i2c3>;

/* Uncomment and fill with your current scl/sda lines. */
//scl-gpios = &lt;&amp;gpio3 8 GPIO_ACTIVE_HIGH&gt;;
//sda-gpios = &lt;&amp;gpio3 7 GPIO_ACTIVE_HIGH&gt;;

status = "okay";


    pinctrl_i2c3: i2c3grp {
        fsl,pins = &lt;
            MX6UL_PAD_ENET2_RX_DATA0__I2C3_SCL        0x4001b8b0
            MX6UL_PAD_ENET2_RX_DATA1__I2C3_SDA        0x4001b8b0

&fec1 {
pinctrl-names = “default”;
pinctrl-0 = <&pinctrl_enet1>, <&pinctrl_enet_mdio>;
phy-mode = “rmii”;
phy-handle = <&ethphy1>;

 * Optional fields.
 * Configure the PHY reset with a GPIO in your design.
//phy-reset-gpios = &lt;&amp;gpio5 6 GPIO_ACTIVE_LOW&gt;
//phy-reset-duration = &lt;26&gt;;

status = "okay";

mdio {
    #address-cells = &lt;1&gt;;
    #size-cells = &lt;0&gt;;

    ethphy1: ethernet-phy@0 {
        compatible = "ethernet-phy-ieee802.3-c22";

         * Add your custom PHY configuration.
        reg = &lt;0&gt;;


    pinctrl_enet1: enet1grp {
        fsl,pins = &lt;
            MX6UL_PAD_ENET1_RX_DATA0__ENET1_RDATA00        0x1b0b0
            MX6UL_PAD_ENET1_RX_DATA1__ENET1_RDATA01        0x1b0b0
            MX6UL_PAD_ENET1_RX_EN__ENET1_RX_EN        0x1b0b0
            MX6UL_PAD_ENET1_RX_ER__ENET1_RX_ER        0x1b0b0
            MX6UL_PAD_ENET1_TX_DATA0__ENET1_TDATA00        0x1b0b0
            MX6UL_PAD_ENET1_TX_DATA1__ENET1_TDATA01        0x1b0b0
            MX6UL_PAD_ENET1_TX_CLK__ENET1_REF_CLK1        0x4001b031
            MX6UL_PAD_ENET1_TX_EN__ENET1_TX_EN        0x1b0b0

    pinctrl_enet_mdio: mdioenetgrp {
        fsl,pins = &lt;
            MX6UL_PAD_GPIO1_IO07__ENET1_MDC        0x1b0b0
            MX6UL_PAD_GPIO1_IO06__ENET1_MDIO        0x1b0b0

Mathieu GALLE, Vitirover

Are you able to reproduce this issue on a cc6ul SBC Pro development board?

We do not own the Pro development board, so we could not test. We checked on the Express board with the expansion port I2C and did not observe the problem (we were not able to check with our exact I2C pins because it is rooted on a LGA pad).

There is only one I2C set on the Pro board, and our problem seems to happen when we use a second one, so my guess is that it would work on the Pro.

The W17 and W19 pins can be rooted either as I2C3 SDA/SCL or ENET2RDATA 00/01 : this could be a link between I2C and Ethernet.

W17 and W19 are connected directly (only with pull-ups), so we could not blame this problem on our custom card.

Since this question, we tried to ping the network via ethernet while a program was using the I2C bus heavily. Since this moment, it is impossible to use the ethernet connection, both from Linux and UBoot, suggesting that we broke something trying to use I2C and Ethernet simultaneously.

I would recommend buying an SBC Pro and trying it there. If you are able to reproduce, open a support case and we will look into it. If not, the problem is probably with your design. I believe we have other customers who use eth0 and I2C3 with pads SCL W17 and SDA W19 and I’ve never heard of such problem.

If you can’t resolve this issue, please open a support case by sending email to tech.support@digi.com

On the SBC Pro kit Hardware documentation, I see only one I2C, so I suppose that the pads we are concerned with (W17 and W19) are not used. So, it is not possible to test this on the SBC Pro.

Thank you for your help, we are waiting for a new custom card with I2C routed on different pins. We still did not understand the issue, but hopefully we can just work around it. I’ll keep you informed.