I2C broken on RPi Pico-w v1.20.0-50-g786013d46 (and previous 1.20.0)

[gregwa1953]

I've been fighting I2C on the Pico-W builds since 1.20.0 came out. I always get an "OSError: [Errno 5] EIO when trying to read or write to ANY I2C device.

Trying to run the SOFTI2C scan per , the code is

from machine import Pin, SoftI2C

i2c = SoftI2C(scl=Pin(9), sda=Pin(8), freq=100_000)

i2c.scan()              # scan for devices

i2c.readfrom(0x3a, 4)   # read 4 bytes from device with address 0x3a
i2c.writeto(0x3a, '12') # write '12' to device with address 0x3a

buf = bytearray(10)     # create a buffer with 10 bytes
i2c.writeto(0x3a, buf)  # write the given buffer to the peripheral

Even that doesn't run, but gives a different error at line 7 (i2c.readfrom(0x3a, 4) # read 4 bytes from device with address 0x3a )
OSError: [Errno 19] ENODEV

I've searched and did find something but it was a bust. The orriginal suggestion was to replace the line

i2c.writeto(adr, dat)
with
i2c.writeto(adr,bytearray([dat]))

But that gets an error TypeError: can't convert bytearray to int
And, just in case someone suggests that it is bad pins in the breadboard, it runs on 1.19x just fine and nothing has changed when I updated the MicroPython firmware.

Someone please help
Greg

[robert-hh]

I confirm that it fails with the build from the download page, and it works with a self-built image with the same build prompt:
MicroPython v1.20.0-50-g786013d46 on 2023-05-06; Raspberry Pi Pico W with RP2040
It works as well with the v1.20 release build:
MicroPython v1.20.0 on 2023-04-26; Raspberry Pi Pico W with RP2040

Edit: @dpgeorge There seems to be a problem at least with the daily build v1.20.0-50 for PICO W. It refuses operation with I2C. scan() works, but nothing besides that. A self-built firmware works, as well as the release build. The firmware for the standard PICO board works.

[gregwa1953]

Thank you @robert-hh !
After beating my head on the problem a bunch more, I found the following...

For the RPi Pico (not W) running MicroPython v1.20.0 on 2023-04-26, the default pins seem to be
I2C Configuration: I2C(0, freq=399361, scl=5, sda=4, timeout=50000)
I2C Configuration: I2C(1, freq=399361, scl=7, sda=6, timeout=50000)

Running I2C devices on only those pins will work.

For the RPi Pico-W running MicroPython v1.20.0-50-g786013d46 on 2023-05-04, the default pins are the same as the non-W Pico.
Running the I2C devices on the default pins ONLY allows I2C to work for either Buss 0 or 1.

From the release notes for the RP2 port...
machine_i2c: use pico-sdk's default pins for I2C
boards: remove all I2C,SPI pin defs that already match pico-sdk

So it looks like four pins are the only ones that will be allowed to use I2C. Quite a shame, but it is what it is.

[robert-hh]

So it looks like four pins are the only ones that will be allowed to use I2C. Quite a shame, but it is what it is.

It's not like that. Just the default pins have been changed. You can always specify different pins in the constructor. For my test, I used sda=Pin(8) and scl=Pin(9). There was just a difference between the v1.20.0-50 firmware loaded from the download page and the v1.20.0-50 firmware which I have built myself using the files from the repository. The self-built firmware works with the I2C setting, the downloaded one not. And the release version of v1.20.0 works as well. So there is a problem with the nightly build image.

[gregwa1953]

Thank you @robert-hh .
Maybe you could offer to provide your self build code to the R2 group and the inconvenience could be put to bed ;o)

Again, thank you very much!
I can live with either set of defaults, as long as I know which set to use. 😁
Gregwa1953

[robert-hh]

Maybe you could offer to provide your self build code to the R2 group and the inconvenience could be put to bed ;o)

???

[gregwa1953]

Thank you again @robert-hh.
Please take my previous statements as a workaround rather than a definitive statement at least until the latest nightly build images are fixed.

Gregwa

[jimmo]

@robert-hh @gregwa1953 I have been trying to investigate this but can't quite get to the bottom of it.

Here's what should be the case:

• On the Pico (and Pico W), between v1.19.1 and v1.20.0, the default pins for I2C(0) changed from 8/9 to 4/5.
• There should be absolutely no difference between v1.20, any nightly since, and between the downloadable firmware or firmware built yourself.

I wrote a simple test:

# v1.19.1 (from micropython.org/download)
# i2c = machine.I2C(0) # default is 8/9
# i2c = machine.I2C(0, sda=Pin(4), scl=Pin(5)) # check non-default pins
# i2c = machine.I2C(0, sda=Pin(20), scl=Pin(21)) # check (other) non-default pins

# v1.20.0 & nightly-v1.20.0-117 (both from micropython.org/download)
# i2c = machine.I2C(0) # default is 4/5
# i2c = machine.I2C(0, sda=Pin(8), scl=Pin(9)) # check non-default pins
# i2c = machine.I2C(0, sda=Pin(20), scl=Pin(21)) # check (other) non-default pins

Each one of those configurations (when the wiring was changed to match) worked when I subsequently did a scan and read/write operations.

@gregwa1953 One thing I did notice is that the device seems to need a hard reset when switching pins. i.e. If I had it working, then physically changed the wiring, updated the code to use the new pins, it would not work until I did a hard reset. The scan worked, but the first write raised EIO.

So maybe that's what you're seeing? If so, then that is a bug I think, you should be able to switch pin assignments at runtime.

[gregwa1953]

Yes, I've seen that as well, although sometimes it takes 3 or 4 hard resets before things work as they should. I probably could wait a few more seconds between resets, but let's be honest. In a prototyping environment, once you have it working you really shouldn't have to change it very often. Usually, only when you run out of space on that side.

I REALLY appreciate your help @robert-hh ! Thank you again.

Gregwa1953

[robert-hh]

One thing I did notice is that the device seems to need a hard reset when switching pins.

I can look into it, but at the first glance it's strange. This is an old part or the code. When you change the pins, you have to call the constructor again. In machine_i2c_make_new(). There, i2c_init() from the SDK is called. The first thing that happens in i2c_init() is to call i2c_reset(). So resetting the I2C hardware is done. It may be that the previously used pins have to be configured back to GPIO mode. That can be tested by Python code.

[gregwa1953]

I've got at least 1 Pico original and 1 Pico-W that are (somewhat) free, so if you need me to do any testing to help you out, please feel free to let me know what I can do to help.

I've never been able to build a MicroPython port successfully and I'm the LAST person that you would want digging into C code, but I'll try to do anything I can to help out. Just let me know.

Gregwa1953

[robert-hh]

That's OK. I just looke dinto the code because I guessed, that a I2C reset was missing on soft reset. But that seems to be there. So maybe the GPIO pins have to be cleared. So you can try the following sequence

1. Enable and use I2C on pins 4 and 5
2. Set pin 4 and 5 back to GPIO mode by declaring them as Pin objects
3. Enable and try to use I2C on pins 8 and 9.

Optionally do a soft reset between steps 2 and 3.

[gregwa1953]

That's an AWESOME thought.
I never considered setting the pins back to GPIO mode.
I'll give that a try later today. ( I've still got my snout into my morning coffee and my eyes will barely focus, so it will take a bit of time).

Thank you again for hanging in with me to fight this issue.

Gregwa1953