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

You cannot use 5V powered devices. Likely they will have pullups on the SDA and SCL lines. This means that SDA and SCL lines are pulled up to 5V, which is too high for the gpio’s on the bpi-r4. They may get damaged.

If you must use 5V, then use a bi-directional level converter.

If you doubt the functionality of the i2c1 port (driver or hardware) you could always setup a software driven i2c port on any of the other gpio pins.:

https://www.kernel.org/doc/Documentation/devicetree/bindings/i2c/i2c-gpio.txt

Something like:

	i2c_gpio0: i2c-gpio-0 {
		compatible = "i2c-gpio";
		sda-gpios = <&pio 16 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
		scl-gpios = <&pio 17 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
		i2c-gpio,delay-us = <2>;
		#address-cells = <1>;
		#size-cells = <0>;
	};

But replacing 16 and 17 with appropriate numbers, finding the correct number is the tricky part…

cat /sys/kernel/debug/pinctrl/1001f000.pinctrl-pinctrl_moore/pinmux-pins

To find the pin nr which correspnds to (GPIO_XX).

After applying the dts overlay, check:

cat /sys/kernel/debug/gpio

to see the function assigned to the gpio.

Nice, thanks for the informations. I was used just 3V3, as I am used from playing with arduino. Now I verified that INA3221 is functional, I detect it on the Arduino nano.

Ouuups, now i realize what do you mean with the 5V level. the AHT10 wich I tested as the first is powered only with 3V3, but as it did not worked, I tested the INA3221 which can be powered 3V3 and even 5V, and if there is 5V logic levels along with the 5V DC power…

But, what do you think, does it is possible to have i2c damaged when I am able to see the data with the 3V3 logic level on SCL and SDA on osciloscope?

It is possible you have damaged receiving circuit on sda. I try to enable i2c1 on my r4 next days to check.

1 Like

Best option is to power the ina3221 with the 3.3V from the gpio-header. Always make sure the GND is properly connected. This way your gpio-pins are safe from over-voltage.

Only if you have supplied your ina3221 with 5V, both your sda/scl pins may have also been pulled to 5V, through the two 10k resistors you found, which is higher than the specifications. Usually they do not die immediately, your pins may have been damaged, maybe not, who knows.

So you can setup another i2c bus with ‘i2c-gpio’. You could first try it on pins other then the ones you have tried before, they should not have been subjected to over-voltage. If that works, you could try the ‘i2c-gpio’ on the same pins as the i2c1 port (with i2c1 port left disabled).

I never had problems with i2c :slight_smile: nothing needed to add as resistors or so on…

Just look into my topic here

True, that sometimes i2cdetect command shows nothing.

Try also to reset line with i2cdetect -r 1

As far as i see you only enabled the i2c1 without assigning pinctrl…was it defined in openwrt already? But yes scanning sometimes do not show up devices…remember i had this with the oled display.

Yep, he might be unlucky all devices he tries are not detectable by i2cdetect.

Rule out by connecting i2c eeprom:

https://a.aliexpress.com/_EzmZQu6

Also

Has anyone be able to get the AHT10 i2c temp/humid sensor to work? - Raspberry Pi Forums

Shows the AHT10 does show up on i2cdetect.

And this page

https://github.com/lvypaul/INA3221

Recommends using i2cdetect on the ina3221.

Most modules will have pullups included on the module, the i2c bus does require them to function correctly.

Waw, good to know that some modules/devices could be problem even detect. If it could be more strightforward with another sensors, do you anybody knows and recommends some others? As I really do not need precise current, hall sensor could be sufficient and preffered. I find some on aliexpress, but there are the cheap one only to 5A and I need limit 20A.

And as I would like wo know consumption of:

  • 12V for bpi-r4
  • 12V for hard drives
  • 5V for hard drives

use of 3-channel INA3221 looked great. Whenever I will have 3 modules, they have to have possibility to set-up different i2c address. I assume that it will not be a problem?