I2C3 is somehow realted to MX7D_PAD_I2C4_SDA

Technical Support
, ,
1

Hi

I drilled down a not working i2c bus to one change in the device tree.

The used bus is &i2c3 and configured on these pins:

&iomuxc {
  pinctrl_i2c3: i2c3grp {
    fsl,pins = <
      MX7D_PAD_I2C3_SCL__I2C3_SCL    0x4000007f
      MX7D_PAD_I2C3_SDA__I2C3_SDA    0x4000007f
    >;
  };
};

i2c3 {
  clock-frequency = <100000>;
    pinctrl-names = "default";
    pinctrl-0 = <&pinctrl_i2c3>;
    status = "okay";
};

and working fine:

root@colibri-imx7-12914835:~# i2cdetect -y 2
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- 6a -- -- -- -- -- 
70: -- -- -- -- -- -- -- --

When i touch the following PAD the i2c3 stops finding the chip.

//
// THIS BREAKS I2C3 !!!!!!
//
&iomuxc {
  pinctrl_w1: w1-grp {
    fsl,pins = <
      MX7D_PAD_I2C4_SDA__GPIO4_IO15      0x78 /* tried more vals 0x4000007f */
    >;
  };
};

the “MX7D_PAD_I2C4_SDA__“ is only used in imx7-colibri.dtsi at pinctrl_gpio2 which i commented out and or redefined. (I validated this by grepping it inside the kernel tree)

This also looks the same regardless of config of MX7D_PAD_I2C4_SDA__

root@colibri-imx7-12914835:~# cat /sys/kernel/debug/pinctrl/pinctrl-handles | grep -i '\.i2c' -A5

device: 30a40000.i2c current state: default
  state: default
    type: MUX_GROUP controller 30330000.iomuxc group: i2c3grp (32) function: iomuxc (0)
    type: CONFIGS_PIN controller 30330000.iomuxc pin MX7D_PAD_I2C3_SCL (86)config 0000007f
    type: CONFIGS_PIN controller 30330000.iomuxc pin MX7D_PAD_I2C3_SDA (87)config 0000007f

Hardware: Colibri iMX7d-emmc
OS: kernel 4.20y, same behavior also on Yocto 7.5.0,

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

I’d be glad to help troubleshoot this I2C issue! To provide the most accurate guidance for your specific setup, could you let me know:

  • Which exact OS and version are you running? (e.g., Yocto 7.2.0, Torizon OS 6.8.2, BSP 6, etc.)
  • Which Toradex hardware are you using? (e.g., Colibri iMX7, Verdin iMX8M Plus, etc.)

You can get this information quickly by running the tdx-info command on your device. For more details, see: Getting Device Information with Tdx-Info | Toradex Developer Center

Understanding your exact platform will help me provide the most relevant pinmuxing guidance for your i.MX7-based module and I2C configuration issue.

Common platforms include:

  • Hardware: Colibri iMX7, Verdin i.MX8M Plus, Apalis i.MX8QP
  • OS: Yocto 7.2.0, Torizon OS 6, BSP 7
  • Integration: Device tree overlays, GPIO, I2C, pinmuxing

Best regards, Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

3

Hello @m.tellian,

Could you clarify what you are trying to achieve?
Are you just trying to use the I2C4_SDA pad for another purpose or what exactly is the problem?

To me it seems odd that adding a pinctrl node changes anything by itself.
If such pinctrl node is not used by any other node, it should not even apply.

Are you sure that you are not overriding an existing node by using the same name or phandle?

Best Regards,
Bruno

4

I am using MX7D_PAD_I2C4_SDA as GPIO with the w1-gpio driver which works/worked flawlessly before using I2C3.

// COMMENTED OUT FOR DEBUGGING
// / {
//     onewire {
//       compatible = "w1-gpio";
//       status = "okay";
//       gpios = <&gpio4 15 GPIO_ACTIVE_HIGH>;
//     };
// };

This config works on its own but was commended out to debug this behavior.

Just the PAD change MX7D_PAD_I2C4_SDA__GPIO4_IO15 makes I2C3 not detect the i2c device.
”pinctrl_w1” is unique in the tree.

5

Hello @m.tellian,

Can you send me the full device tree with the intended that you expected to work in your application?

I think the snippets are losing important context.

If you prefer, you can send them via email to support.eu@toradex.com.

Best Regards,
Bruno

6

Nothing fancy not to share. To drill down and reproduce the problem i started with the plain eval board dts and added just w1 and i2c3.
The old branch is used because i have an image with CONFIG_W1_SLAVE_THERM configured which is absent in newer Torizon builds.

Meanwhile we figured out that even with the advertised working configuration the i2c communication is not reliable. I would kindly ask you to standby and be patient for my update on this.

imx7d-colibri-emmc-mccu-v3.dts (7.4 KB)

7

Hello @m.tellian,

Thanks for the additional context.
In your device tree you are attempting to modify the following nodes by re-declaring them:

pinctrl_gpio1: gpio1-grp {
...

pinctrl_gpio2: gpio2-grp {
...

This is not the correct way to modify existing nodes.
To modify existing nodes you need to use the phandle reference and write the new property:

&pinctrl_gpio1 {
...

&pinctrl_gpio2 {
...

Note that this should be done outside the scope of &iomuxc, as the phandles already point to the specific nodes.

Please try with this change and check if you still see problems related to the use of I2C3.

Best Regards,
Bruno

8

Thank you for recalling dt usage - it helped a lot.

Meanwhile I have to state that the w1 problem is hw related and should be removed from the topics title.

The i2c3 problem still exists. By trying repeatedly i found out that the sensor communictaion works unreliable ~30% of the time and so was correlated falsely with the w1 function:

root@colibri-imx7-12914835:~# cat /proc/interrupts | grep 30a40000.i2c ; i2cget -y 2 0x6a 0xf ; cat /proc/interrupts | grep 30a40000.i2c ;
57: 1897 0 GPCv2 37 Edge 30a40000.i2c
Error: Read failed
57: 1898 0 GPCv2 37 Edge 30a40000.i2c

root@colibri-imx7-12914835:~# cat /proc/interrupts | grep 30a40000.i2c ; i2cget -y 2 0x6a 0xf ; cat /proc/interrupts | grep 30a40000.i2c ;
57: 1898 0 GPCv2 37 Edge 30a40000.i2c
0x6b
57: 1902 0 GPCv2 37 Edge 30a40000.i2c

I tried to really start with the basic evalboard dts and validated by decompiling the resulting dtb. I can’t see anything double used or being different from the other working i2c. (my_notworking_i2c3.dts and my_decompiled_notworking_i2c3.dts)

I also can proof this inconstancy is not hardware related by unintentionally applying a incompatible TorizonOS dtb from my parallel work. This results in a crash in dmesg but strangely the i2c@30a40000 communication works reliably.

There is also no error doing the same procedure on TorizonOS 7.5.0-build.30

my_decompiled_working-possibly-by-accident_i2c3.dmesg.txt (22.4 KB)

my_decompiled_notworking_i2c3.dts (55.9 KB)

my_decompiled_working-possibly-by-accident_i2c3.dts (62.4 KB)

my_notworking_i2c3.dts (1.7 KB)

9

Hello @m.tellian,

Thanks for the update.
I will have a look at the new information and get back to you when I have some suggestions.

Best Regards,
Bruno

1 Like
10

Hello @m.tellian,

The current I2C configuration on my_notworking_i2c3.dts should be valid.

Regardless, I would recommend that you setup this I2C bus also with the recovery functionality as done for I2C4 here: imx7-colibri.dtsi

It would be worth also checking if the sensor is working properly, if you connect it to a different I2C port, do you still see the issue?

Best Regards,
Bruno