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]

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]

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 #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.