EIO error on i2c.writeto_mem with current uPy versions on Pico

[Arthur-66]

Even with drivers written by several of the pro-s in this forum for e.g. BME280 or MAX44009 and various other sensors I-m having issues with EIO errors in drivers which use i2c.writeto_mem(). It seems to the more or less the same issue as was discussed in the old forum here: [RP2: Hard I2C is intolerant of clock stretching] (#8167 (comment)) already in early 2022. SoftI2C with the same drives does seem to work and on one occasion I did seem to be able to work around it by a sequence of i2c.writeto()'s. Is this a known issue and is there any solution for it, other than to fall back on SoftI2C?

[ned-pcs]

Have you added pull-up resistors on the SCL and SDA lines? If not, give this a try (with resistors somewhere between 2K and 8K ohms), as the internal pull-ups aren't very strong.

[Arthur-66]

It happens with internal pull ups, or external 4.7K or 10K ohm pull ups (with the latter being fine for ESP32s). It consistently seems to be in lines with i2c.writeto_mem() or i2c.readfrom_mem(). I believe that in the workaround in an hmc6532 driver I used separate writes with a short delay in between which seemed to solve the problem there:
# original code commented out
# data = self.i2c.read_i2c_block_data(self.address, HMC6352._READ_CMD, 2)
# data = self.i2c.readfrom_mem(self.address, HMC6532READ, 2)
bear = []
self.i2c.writeto(self.addr, HMC6532_READ_CMD)
sleep(DELAY_ACT)
bear = self.i2c.readfrom(self.addr, 2)
I-ve used the same drivers previously on older versions of uPy on ESP32 based boards with no issues at all with the same pull-ups, etc. So it may be RP2040 specific and my impression is that it may be a timing issue?

[Arthur-66]

That or just being too fast with the next byte in a row although 100K speed on the I2C bus should work.

Only "logic analyzer" I own is in my head, so can't really help you with any traces.

I wonder whether Circuitpython may have been amending some of the I2C driving code as some of the seem boards with the RP2040 seemed to be happy with cPy drivers. Fooled aroud with those a bit earlier, but prefer the uPy approach to various things. Their "portability" doesn't seem to be much higher than can be achieved with some if sys.platform statements and I find their use of letters and numbers for pins more distracting than helpful.

So back to uPy and solving this riddle for now by switching to SoftI2C it the if sys.platform == "rp2" statement. Did just try 2.2K Ohm pullups, just in case, but that makes no difference. It really is something with the writeto_mem and readfrom_mem sequence or speed of shoving the bytes through which seems to cause an issue specificially with the rp2040.

[Arthur-66]

Still it is very weird. With an SSD1306 driver on the RP2 one demo program has no problem initializing the device and running the demo with I2C, but another demo program run immediately after only gets through the initialization with either a full powerdown with I2C, or with a switch to SoftI2C. Without the hard restart I2C again results in EIO errors. Nothing changed in the wiring or anything else. All the initialization parameters are identical. And again failing on writeto_mem /readfrom_mem lines.

[Arthur-66]

Done some further searching and experimenting as with older versions of uPy more or less all sensors worked out of the box with the various drivers. I currently had my Pico on a Grove expansion base which uses pins 8 and 9 for I2C0 and 6 and 7 for I2C1.
Read somewhere that there didn't seem to be no EIO 05 errors on I2C1, but switching to that results in the same errors on the reato/writefrom_mem lines.
Noticed that the pinouts for the Pico indicate that all I2C0 pins are shared TX/RX pins except for 20 and 21, so moved a pico onto a simple pico dual expansion base and switched to those pins. Same error.
Realized that with older versions of uPy (1.17 or so) you didn't have to specify the I2C bus when initiating and read that if you didn't it may have been using SoftI2C behind the scenes. That could at least explain in part why on those versions the same sensors with the same wiring seemed to work OK.
Switched on either I2C0 or I2C1 pins to SoftI2C and the same driver works for some time but after 20 or 30 sampling cycles with 1 second delay in between SoftI2C runs into a ENODEV error with a Gy-39 sensor (combination of BME280 and MAX44009. That likely won't be a real problems as that would not be the usual way of working.
Imho there is an issue with the readto/writefrom_memory routines in the I2C implementation for the RP2024 in uPy which causes the EIO 05 errors with the hardware I2C interface with multiple different sensors, but seems to be less of a problem when using SoftI2C.

[Josverl]

If you have another rp2, you have a logic analiser in reach. https://www.hackster.io/dotcypress/la-micro-logic-analyzer-for-rp2040-aff270

That helps getting the facts of what is happening on the wire, and hopefully the solution

[Arthur-66]

Tried multiple RP2040 based boards, both the original Pico, Pico-W and RP2040-Plus, and with or without the Grove base. All the same. Some drivers work. Some drivers crash immediately with EIO 05 on the ...to_mem bits if using I2C but most do seem to work with SoftI2C at 100000 but may be flakier at 400000 than at 100000. Some examples of boards that crash with I2C but work with SoftI2C that I-ve just tested are the DS1307 TinyRTC, and the MLX90614 IR temperature sensor. The latter, for example, could not get past the ..to_mem line in its initialization, but works fine on SoftI2C. An MAX44009 light sensor that does not include such lines works without issue on I2C.

As said, the only logic analyser I have is my common sense brain. To me it seems quite clear that there is an issue in particular with the I2C.writefrom_mem(), possibly also with the I2C.readfrom_mem(). Drivers which have no ...to_mem() lines seem to always work on I2C. It is always on those lines that the EIO 05 error occurs while with all other setting identical SoftI2C semes to have less or no issues with those lines. Maybe it has to do with clock-stretching which does not seem to be done in the I2C driver, but does seem to be included (to some degree) in SoftI2C.

At least the SoftI2C route has gotten various sensor working that I-d been struggling with for a couple of days. Although some will still crash after 20 or 30 cycles in the unrealistic demo situation doing the same measurement every second, I think it shouldn't be a big problem to work around that.

[mendenm]

If you need a logic analyzer which is hosted on the same Pico as the code you are testing, I am attaching one I wrote. It uses the PIO and DMA capabilities, so it doesn't interfere with other stuff. It compresses the returned data, so all you see are transitions, and not steady state information, so it tends to return fairly small amounts of data. On a 120 MHz Pico, it can get just better than 100 ns resolution; it takes 11 cycles to detect and process a transition. Note that this is un-released code so far. I haven't edited in any license info, or anything. I will clean it up and put it on github at some point in the near future with an open-source license, so for now, use it with respect, please. It has an example of how to use it at the bottom. I will be glad to answer any questions, of course.
data_compressing_analyzer.py.zip

[robert-hh]

I cannot replicate your problems here with similar sensors. Hard I2C at RP2040 runs reliable.
So there might something wrong on your side not related to the rp2040 or the sensors itself, but causing problems. Frequent problems are caused by:

• power supply of the board.
• the USB cable. Connectors at USB cables have a limited lifetime.
• defective or unreliable breadboard. I had samples which I dumped to trash after the first use attempt.
• defective or poor patch wires.
• Incomplete wiring, especially forgetting the GND wire.
• long i2C wires. I2C is defined for short wires, like 15 cm.

Most probably you have checked that all before, but a re-check cannot hurt.

[Arthur-66]

I had checked it all and the same setups have worked without issues with the same drivers on ESP32 previously. Also if it was wiring, wouldn't SoftI2C not also be impacted in most if not all cases.
Anyway, oddly although I haven't changed the setup, other than that the notebook has been disconnected overnight from the USB hub which provides power to the notebook, and to which the Pico is connected. Today the mlx90614 works fine on either I2C or SoftI2C as does the DS1307 for the clock demo. The memory test demo of the DS1307 still fails with I2C but now with a timeout (again on a ..to_mem line), also if the USB cable is directly connected to the PC, but passes with SoftI2C.
Back to some further experimenting. Maybe the USB hub is part of the issue. I have a navigator which actually is the other way around, doesn't like the direct connect, but is fine when connected to hub for updating the firmware. If I do stumble upon an explanation, will post of course, particularly if it is something unusual not in your usual causes list.