[bpi-r4] could not detect anything new on I2C

Hello,

I am trying to detect AHT10 and INA3221 sensors on bpi-r4. I compiled kernel with AHT and INA modules, and after kernel denied insmod aht10.ko because of unknown symbol in the modul, I recompiled kernel with these drivers added in the kernel.

I connected modules on GPIO:

  • GPIO18/I2C_1_SDA
  • GPIO17/I2C_1_SCL
  • GND
  • 5 or 3V3

when I try i2cdetect -y [0-5], there are some detects on every i2c bus, but no new device. The result is the same.

I tried to help some examples on how to work with i2c on debian, but I do not have an idea what am i doing wrong?

Maybe you need to enable the i2c bus using the devicetree (overlay).

Does it is possible that it is not enabled if it is possible to list buses and scan some devices?

$ i2cdetect -l
i2c-0	i2c       	i2c-mt65xx                      	I2C adapter
i2c-1	i2c       	i2c-mt65xx                      	I2C adapter
i2c-2	i2c       	i2c-1-mux (chan_id 0)           	I2C adapter
i2c-3	i2c       	i2c-1-mux (chan_id 1)           	I2C adapter
i2c-4	i2c       	i2c-1-mux (chan_id 2)           	I2C adapter
i2c-5	i2c       	i2c-1-mux (chan_id 3)           	I2C adapter
$ i2cdetect -y 0
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- UU -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         
$ i2cdetect -y 3
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: 50 51 -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: UU -- -- -- -- -- -- --

Bus ID 0 and 3 was choosed randomly as an example.

It looks like you have to enable i2c1 (for gpio header) in dts. I2c0 is i2c0 in dts,but i2c1 above is i2c2 in dts with the i2cmux below (the other i2c busses are channels from i2cmux).

waw, thanks for pointing me. I am trying to imagine what do you mean with the i2c1 is i2c2 in dts with the i2cmux. I assume that you mean that in the i2cdetect -l the:

i2c-1	i2c       	i2c-mt65xx                      	I2C adapter

should be in mt7988a-bananapi-bpi-r4.dts somehow pointed to the

i2c-2	i2c       	i2c-1-mux (chan_id 0)           	I2C adapter

I am so sorry @frank-w , but as I never used i2c, dts, dtsi, I have more questions than I expected, and I really do not want screw up things too much…

How it is possible that I am able to get some results from i2cdetect -y 1 if the bus is not enabled?

If so, why it is not possible to use the i2c-2 instead?

And is there any reason to not commit this configuration in the mt7988a-bananapi-bpi-r4.dts?

Maybe it is clearer when you look at zhe dts.

You have i2c0 with the pmic and i2c2 with the i2c-mux (both not accesible from gpio header pins). Linux kernel counts from 0 while creating devices,so i2c2 gets i2c1 because soc i2c1 is not enabled there…

So you just need this with recompiling and installing kernel:

&i2c1 {
	pinctrl-names = "default";
	pinctrl-0 = <&i2c1_pins>;
	status = "okay";
}

Based on my shematic pinctrl should be gpio 17+18 which is i2c1_0 in pinctrl driver.

Which is used here

So only the definition for i2c controller with enabling and mapping existing pinctrl is missing.

Great, kernel compiled and now I am able to scan I2C-1 bus:

$ i2cdetect -l
i2c-0	i2c       	i2c-mt65xx                      	I2C adapter
i2c-1	i2c       	i2c-mt65xx                      	I2C adapter
i2c-2	i2c       	i2c-mt65xx                      	I2C adapter
i2c-3	i2c       	i2c-2-mux (chan_id 0)           	I2C adapter
i2c-4	i2c       	i2c-2-mux (chan_id 1)           	I2C adapter
i2c-5	i2c       	i2c-2-mux (chan_id 2)           	I2C adapter
i2c-6	i2c       	i2c-2-mux (chan_id 3)           	I2C adapter
$ i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --

But I am still not able to scan INA3221 or AHT10. I try and solder shorter dupont cables on AHT10 directly, but I am still unable to detect it.

Using osciloscope, there is standard 3V3 high level on SDA and SCL, and I am able to see some data on both channels whenever i run i2cdetect -y 1 , but still nothing is detected. I will test more i2c capable modules i find.

Please let me know whenever anyone have another idea, as I wrote, I do not have any experiences.

Now I try INA3221 and even epaper module. Nothing was detected. I was thinking that it have to be an modul, but what about any problem which could block reading of data from SDA? Out of ideas.

Do any of the modules have pull-up resistors built-in? May need to add 2 of them.

But I believe the Ina3221 modules already include them.

I can see 2pcs of 10k resistors on the board.