Open dutchcompo opened 4 years ago
Try without and parameters - dtoverlay=i2c-gpio
- does that work?
How can I use pins 23 and 24 as i2c sda and scl? Is that still build in and now automatically connected? Or is this feature gone? I will try your request later this week.
As it happens, 23 and 24 are the defaults - run dtoverlay -h i2c-gpio
to learn about an overlay - but the point of the test was to find the simplest configuration that still fails to boot.
Alas, dtoverlay=i2c-gpio without parameters is not working with my RPI3B. Rainbow screen and no boot. Can you reproduce this bug?
I'll try when I can.
I have the same issue. When I add dtoverlay=i2c-gpio
to /boot/config.txt
, rasppbery pi not boot.
I tried add some params bus=3,i2c_gpio_sda=2,i2c_gpio_scl=3,i2c_gpio_delay_us=2
, but still the same.
Problem is with the latest Raspberry Pi OS 2020-05-27 on Raspberry PI 3B and also 3B+
kernel: Linux raspberrypi 4.19.118-v7+ #1311 SMP Mon Apr 27 14:21:24 BST 2020 armv7l GNU/Linux
With an older kernel 4.19.66 -v7+ #1253
everything works fine.
I installed all the latest updates: Linux Barry 4.19.118-v7+ #1311 SMP Mon Apr 27 14:21:24 BST 2020 armv7l GNU/Linux
But I copied an old i2c-gpio to /boot/overlays/ And this works fine with my i2c light sensor.
The file is 1055 bytes. How can I check the version of an overlay?
Maybe this give a clue on the working version?: sudo i2cdetect -l i2c-3 i2c 3.i2c I2C adapter i2c-1 i2c bcm2835 I2C adapter I2C adapter
This was broken on Apr 08 and fixed on May 02. The broken overlay is 1087 bytes long, and the fixed version is 1127 bytes long. If your overlay is 1055 bytes long it predates the breakage, so you're OK.
You can download a fixed version of the overlay from here: https://github.com/raspberrypi/firmware/raw/master/boot/overlays/i2c-gpio.dtbo
I am sorry. The RPI is booting now and with i2cdetect -l I can see the i2c master. But with i2cdetect -y 3 I don't see my light sensor with address 29.
What is your dtoverlay line now? Do you have pull-up resistors on the I2C lines?
I connected the light sensor https://learn.adafruit.com/adafruit-tsl2591 and this is working for a year or two now without problems. Are the pull-ups with the new software necessary? If so, I will try it later this week. I don't have resistors at home. At work a lot but due to the crisis I have to work at home.
I used with the new overlay the line dtoverlay=i2c-gpio,bus=3,i2c_gpio_delay_us=1,i2c_gpio_sda=23,i2c_gpio_scl=24 and I used the line without parameters. Both gave an i2c master but no connection to the light sensor. I copied back the old overlay and everything is working as expected.
Pullups are always advisable, but you can sometimes manage without them.
Can you still make it work by just reverting to the original 1055-byte overlay and without changing anything else?
I have it working now with the 1055 overlay without parameters.
That's odd. The difference between the original and current overlays is the addition of the i2c-gpio,sda-open-drain
and i2c-gpio,scl-open-drain
properties to get rid of a warning. My understanding was that this would make no practical difference - the GPIO hardware doesn't support open-drain pins - and my limited testing was successful, but perhaps it does make a difference after all.
Tomorrow I will try a 10K pullup-resistor. I hope I still have one somewhere. Else I have an small tour on the bike.
Ran into same issue. Configured a RasPi 3B+ with clean OS load based on 2020-02-13 Raspbian around end of March 2020. Edited "config.txt" to add two (2) additional I2C busses (used Instructables guide: https://www.instructables.com/id/Raspberry-PI-Multiple-I2c-Devices/ ). Respective lines follow:
dtoverlay=i2c-gpio,bus=4,i2c_gpio_delay_us=2,i2c_gpio_sda=17,i2c_gpio_scl=27 dtoverlay=i2c-gpio,bus=3,i2c_gpio_delay_us=2,i2c_gpio_sda=23,i2c_gpio_scl=24
System uses two (2) SHT-30 encased sensors, one on i2c-3; one on i2c-4. On i2c-1, other sensors and LCD displays including SHT-31D (all SHT sensors had same address, chose to configure additional I2C busses rather than use I2C mux). Also required modification to "/usr/local/lib/python3.7/dist-packages/adafruit_blinka/microcontroller/bcm283x/pin.py" to specifically add respective pins for the additional I2C busses.
System had been updated regularly and had been running almost continuously. After the recent update and upgrade 30 May, system hung with rainbow screen on reboot. After some internet searching, found https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=275504&p=1669283&hilit=i2c+gpio#p1669283. Was able to replace "i2c-gpio.dtbo" (1087 bytes) from update with older "i2c-gpio.dtbo" (1055 bytes). System booted fine. All sensors working on respective I2C busses. Continuing to monitor.
Further testing on second, separate RasPi 3B+ with latest Raspberry Pi OS 2020-05-27 and clean load. Only peripheral was DS3231 RTC. Once dtoverlay lines added to config.txt, system displayed boot hang at rainbow screen. Replaced "i2c-gpio.dtbo" (1087 bytes) with older version as was done with first system. System booted normally. Then replaced with new i2c-gpio.dtbo downloaded from above link. System booted normally.
Still need to test on first system that was regularly upgraded and currently has older i2c-gpio.dtbo.
I just got a 'hello world' from an i2c display with the newest kernel and newest i2cgpio.dtbo. That means some change in the software effects the working of my adafruit light sensor. I am going for a quest to find a 10k pullup resistor.
Have you changed frequencies of the clock?
My old project box is keeps more than I knew.
Even with a pullup my light sensor is not working with the new i2c-gpio. The LCD display is now also not working any more with the new i2c-gpio. The old is functioning. I am puzzled.
If all you have to do to switch from working to non-working it to change from the old overlay to the new overlay then the new overlay is clearly breaking something. I suggest you continue to use the old overlay and I'll look at reverting the change.
Testing with a BMP180 on a 5.4 kernel I find that I need the new overlay otherwise the data line never changes, with or without an external pull-up. Something is driving it low, and I think it must be the driver itself, as if the signal is inverted. Switching back to 4.19 I get the same behaviour.
It is strange I was playing with my old i2c display and old overlay (1055 bytes). Put the new overlay (1127 bytes) in the boot, restarted. And it is still working. Is there another process running which sometimes take ownership of that pin? I have connected the wires properly!
I switched the rpi off for 3 minutes. And now I am getting only the 'Hello' of the Hello World and again it is not working any more.
There is something strange going on, but I don't think there's enough evidence that the overlay change should be reverted. When I next get a moment I'll look at the effect of the new properties on the GPIO driver.
I wrote a python script which send continuously a counter to my i2c display without a delay. With the old overlay I stopped the script my self at the count of more the 256000 counts. With the new overlay it stops most of the time at less than 50.. I did not touch the hardware at all, it can not be movement in wires. The problem is reproducible. The raspberry pi has a real existing reliability problem with i2c devices. and it is not the hardware.
Well, you have a workaround for now, and I will get back to this since it is so easy to see a difference when I expected none.
Follow-up to original post... On first system, replaced "i2c-gpio.dtbo" (1087 bytes) from update with older "i2c-gpio.dtbo" (1055 bytes). System booted fine. All sensors working on respective I2C busses. It has been running since last post with all sensors posting data. All code is Python3/Circuit Python with Adafruit Blinka.
I have now replaced the functioning "i2c-gpio.dtbo" (1055 bytes) with new downloaded "i2c-gpio.dtbo" (1127 bytes) and rebooted the system. System does not hang and boots normally. In terminal, typing "sudo i2cdetect -y 1" shows all connected sensors. Repeating command for both i2c-3 and i2c-4 does not show the single connected SHT30 sensor on each bus. Expected address is "44". Something has definitely changed with regards to the two latter versions of "i2c-gpio.dtbo".
Reverted back to old "i2c-gpio.dtbo" (1055 bytes) and rebooted. Boots fine, all sensors on all I2C busses are recognized.
For additional reference:
I can confirm. Raspberry 2, LCD2004 on i2c hardware, BME280 on i2c software. With "i2c-gpio.dtbo" (1127 bytes) always after some time, a few hours, communication with BME280 "freezes". With the older "i2c-gpio.dtbo" (1055 bytes) everything is fine.
This issue is now making sense. There are two forms of open-drain marking that the i2c-gpio overlay can use: the first is a flag to the i2c-gpio driver that says "this is really an open-drain GPIO, but you can drive it as normal", and the second is a flag on the GPIO declaration saying "I would like this GPIO to be used in open-drain mode". Both of these have the effect of silencing the warning - however, with the latter, gpiolib is capable of using open-drain emulation for devices that don't really have open-drain outputs (such as BCM283x/BCM2711), whereas the former disables this emulation.
Testing didn't show any problems with the first attempt, but probing the pins as analogue voltages rather than as digital logic levels shows contention on the lines - a setup where the I2C device had lower drive strengths would probably have failed.
There's a fixed version of the overlay (and other overlays that use i2c-gpio) in the current branches.
The new version is available to download here: https://drive.google.com/file/d/1-4vyUf83--nReBnNGhY_VZSHckXOEjo2/view?usp=sharing
Update. Downloaded the new "i2c-gpio.dtbo" (1055 bytes) from Google Drive link. On existing system, replaced older functioning "i2c-gpio.dtbo" (also 1055 bytes) and rebooted the system. System booted normally. In terminal, typing "sudo i2cdetect -y 1" shows all connected sensors. Repeating command for both i2c-3 and i2c-4 also shows the respective SHT30 (addr 44) sensor on each bus this time. Running existing Python3/Circuit Python with Adafruit Blinka code. Initial indications show all sensors reporting data and displays updating as expected. Will let system run and monitor.
I will test it as soon as possible. But that will be late Saturday afternoon.
There's no rush. I'm confident it will work, and it's already in the repo.
My lcd counter is working without problems for more than an half an hour. Than I stopped it my self. My Adafruit TSL2591 light sensor and BME 280 Temperature/humidity/pressure are working well. Thanks! When will this be available in the update repository? It is now the time of year young students start experimenting with all kind of sensors at home. I do not want them to be disappointed it is not working..
I'd like to get a 5.4 kernel into the kernel apt package as soon as possible - I'm not sure if there will be another 4.19 release before then. You always have the option of sudo rpi-update
, but updating just that one overlay would be safer.
Update. System running solid for last three (3) days. All sensors and displays on all I2C busses functioning normally. Thanks for the updated "i2c-gpio.dtbo" file.
The current rpi-update kernel (5.4) includes the fixed overlay.
thanks so much guys! beginner here. roasted my i2c pins with first robotics project was looking for workaround all other tutorials didnt work and ran into booting problems etc
now I have i2c on other pins this was super helpfull well done
Since the last update this week (21-7-2020 done) the parameters should be given. Without bus 3 will not be found,
dtoverlay=i2c-gpio,bus=3,i2c_gpio_delay_us=1,i2c_gpio_sda=23,i2c_gpio_scl=24
Which parameters do you think need to be provided? What is the minimum set? Note that the default bus value may have changed.
dtoverlay=i2c-gpio,bus=3,i2c_gpio_delay_us=1,i2c_gpio_sda=23,i2c_gpio_scl=24
Without these parameters bus 3 is not found,
i2cdetect -l
i2c-1 i2c bcm2835 (i2c@7e804000) I2C adapter i2c-11 i2c ffffffff.i2c I2C adapter
Bus number 3 indeed changed to 11.
If you don't specify a bus number then, as the help says (dtoverlay -h i2c-gpio
) you'll get one assigned automatically by the system - it used to be 3, and now because of the i2c-mux to support the camera it is 11, but it isn't safe to rely on this.
I can live with those changes for as long I can rely on the correct use and effect of the parameters.
The parameter bus=3 is not mentioned on this page: https://github.com/raspberrypi/linux/blob/rpi-4.1.y/arch/arm/boot/dts/overlays/README ??
Because it didn't exist in rpi-4.1.y - that tree is over 4 years old. rpi-5.4.y is the current tree,
Found it ;)
Use the command:
$ dtoverlay -h i2c-gpio
for a description which is correct for the installed kernel and overlays.
This line in the /boot/config.yxy on my rpi3, gives the rainbow screen and the RPI3 does not boot.
dtoverlay=i2c-gpio,bus=3,i2c_gpio_delay_us=1,i2c_gpio_sda=23,i2c_gpio_scl=24