i2c: No support for bus recovery imx.rt and or timeout on bus busy

[EmbedWise]

Describe the bug Running a simple main loop program that reads out i2c sensor values or controlling an i2c GPIO extender in a loop, causes the i2c peripheral at a non-deterministic time interval to become unresponsive.

Please also mention any information which could help others to understand the problem you're facing:

• Target platform teensy41
• After the bus becomes unresponsive i2c function returns -EIO (-5 Error Input Output) and never recovers from this

To Reproduce Steps to reproduce the behavior:

1. Simple main loop with the retrieval of sensor values e.g. BME280 or
2. Simple main loop with the writing of outputs of the MCP23017

Expected behavior In theory a perfect working I2C peripheral with no hanging/unresponsive busses. If it still becomes unresponsive a way to recover. E.g. bus recovery function, currently not implemented for the imx.rt.

Impact A none robust working I2C bus is a show stopper

Environment (please complete the following information):

• OS: MacOS
• Toolchain GCC GNU 10.3.1
• Commit tag version 2.7.1

Additional context Only a kernel reboot warm/cold recovers the bus. Not e.g. the shell command i2c recover, since it is not implemented in the imx rt driver.

Issues that are related to this issue:

4040 with reference to #27715.

The main question is what is the overall structure that is preferred with respect to bus recovery?

[henrikbrixandersen]

@EmbedWise You are encountering this on the teensy41 board? Just to confirm as I don't see any support for this board in upstream Zephyr.

[EmbedWise]

@henrikbrixandersen Yes via the teensy41. The dts goes from teensy41 to teensy40 to nxp/nxp_rt1060.dtsi to nxp/nxp_rt.dtsi. In these dtsi the i2c interfaces are defined.

zephyr/boards/arm/teensy4/teensy41.dts

Enabling:

CONFIG_I2C=y

And defining in an overlay

&lpi2c1 {
  status = "okay";

  bme280: bme280@77 {
        /* 0x76 - SDO <-> GND */
        /* 0x77 - SDO <-> VCC */
        compatible = "bosch,bme280";
        reg = <0x77>;
        label = "ENVIRONMENTAL_SENSOR";
    };

};

Which points to nxp_rt.dtsi

        lpi2c1: i2c@403f0000 {
            compatible = "nxp,imx-lpi2c";
            clock-frequency = <I2C_BITRATE_STANDARD>;
            #address-cells = <1>;
            #size-cells = <0>;
            reg = <0x403f0000 0x4000>;
            interrupts = <28 0>;
            clocks = <&ccm IMX_CCM_LPI2C_CLK 0x70 6>;
            label = "I2C_1";
            status = "disabled";
        };

[github-actions[bot]]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

[github-actions[bot]]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

[henrikbrixandersen]

@EmbedWise Please see https://github.com/zephyrproject-rtos/zephyr/pull/46472 - also worth noting is the bus-idle-timeout devicetree property. It can help if the controller sees a spike on the I2C bus and regards that as another I2C "master" using the bus.