I2C issues on Pico W

Support Raspberry Pi
1

Back in September a user reported ongoing issues with I2C issues with PiicoDev modules. At that time, the solution was to downgrade Micropython to an older version (none of which are available through Thonny).

All three of my Picos (2 with and 1 without wireless) are running the 1.20.0 version of micropython.

On Sunday, all of my modules stopped working (TMP117, RTC, VEML6030) as well as a couple of other I2C devices. The non-Pico devices are “not found” and the PiicoDev devices do the following (regardless of how many are connected).

=================================
MPY: soft reboot
Traceback (most recent call last):
File “”, line 2, in
File “hmc5883l.py”, line 31, in init
OSError: [Errno 5] EIO

I had a couple more PiicoDev sensors arrive yesterday (BME280 and MS5637) and both give the same error on each of the three microcontrollers.

I found the post earlier today recommending that an updated version of PiicoDev_Unified.py be installed, which I did.

Trying with the OLED display, I now get:

    PiicoDev could not communicate with module at address 0x3C, check wiring

which repeats rapidly. The same message appears for the other devices but with a different I2C address for each.

Any suggestions as to what the problem may be?

Note: Each is being tested with the sample code from the github repository for each device’s library.

Thanks.

1 Like
2

Hi Alan

If everything was working before Sunday then there is something wrong with a common component.
The Pico itself
The I2C wiring between the Pico and the first PicoDev device.
A short between the data wires (SCL and SDA), this could be anywhere in the loop and would affect all devices.
Is the power to the O2C devices OK, ie, is the Pico outputting the required volts.
You could have too many PicoDev devices on the string which would have too many pull ups if you haven’t disabled any on the individual devices although you say everything was working up until Sunday. Or did it all quit when you attached another device.

A tip: If it was working before check everything else before you go splashing around reloading/ reflashing anything. If you have already done this you will have tied yourself in a knot and it is a bit hard to suggest where to start.
Cheers Bob

2 Likes
3

Hi Alan, welcome back. Keen to dig a little deeper into this with you.

This would’ve upgraded you to our more recent, “graceful” error handling, that instead of something cryptic:

Tells you what’s wrong and what to check first:

Just as a precaution, could you shoot us a photo of how you’ve got everything hooked up, and confirm that your address jumpers are set right?

image
image1319×431 154 KB

P.S. Once we’ve ruled out the basics, we can do stuff like replicate your setup over here.

1 Like
4

Hi James.
I believe Alan said this all worked OK until Sunday. What happened on Sunday??? Common sense should dictate any occurrence immediately prior to failure should be investigated or you could download, swap and change operating systems till the cows come home and maybe it will work again at some stage. That is not finding the root cause of the problem. It is like putting enough band aids on a cut until it stops bleeding.

I would think that if everything was OK on Saturday the address jumpers would be correct. Unless something was changed on Sunday that Alan has not told us.

Cheers Bob
EDIT:

I would suggest that this points to something common wrong with the I2C connection, Possibilities suggested above.

5

Hi Bob,

I agree entirely that it is an issue with the I2C bus. But what?

I’ve used an array of devices, with brand new, never used cables, and even wiring directly to the processor pins to avoid the JST connector on the Piico adapter board.

In most cases I get Error E05, but sometimes the failure to connect message.

I’ve also used several different Pico units, changed USB cables, USB ports.

I’ve checked that the pins in each of the JST connectors is not bent or missing.

I’ve also checked the switches on those sensors that have them, to ensure that they accord with the defaults in the library for that device and changed them (and the library) to alternates where I am sure of the resulting address.

Given that I’ve had a couple of instances where the RV3028 actually worked, I’m sure that it is a connection issue of some sort. My only other thought at this stage is that I may need to buy another LiPo adapter board in case there is a broken trace or cracked solder joint.

I’ve also tried putting the Pico on a breadboard and using jumper wires rather that the built-in JST ports, all with the same results.

Finally, I’ve re-flashed each board “just in case”!

It has to be something fundamental, surely?

Cheers.

“What we have here is a failure to communicate”
- Cool Hand Luke, 1967

6

Hi James,

See my reply to Bob below.

Here is a photo of the setup I’m using for testing:

IMG20230714172918
IMG202307141729181920×2550 344 KB

All jumpers are as per defaults. There shouldn’t be any address coinflicts according to references on your product specifications.

Here is a list of results from tests (plus what I mentioned to Bob).

For each of the following, they were connected individually using the
default addresses. A brand new cable was used for each device from a packet that
was received on Wednesday.

All libraries were downloaded fresh from the Core website and each test
was conducted using thee “main.py” accompanying the examples.

Each device tested again on a different Pico W.

Tests were also run using otheer cables (from your store) from the device to
the headers on the PiicoDev LiPo charger board in case the JST(?) connector
on the LiPo board was damaged in some way.

Results were identiocal in each case.

BMP280 Addr: 0x77 (default

MPY: soft reboot
PiicoDev could not communicate with module at address 0x77, check wiring
Traceback (most recent call last):
File “”, line 9, in
File “PiicoDev_BME280.py”, line 32, in init
File “PiicoDev_BME280.py”, line 29, in init
File “PiicoDev_BME280.py”, line 64, in _read16
OSError: [Errno 5] EIO

RV3028 Addr 0x52

MPY: soft reboot
PiicoDev could not communicate with module at address 0x52, check wiring
Traceback (most recent call last):
File “”, line 7, in
File “PiicoDev_RV3028.py”, line 84, in init
File “PiicoDev_RV3028.py”, line 81, in init
OSError: [Errno 5] EIO

MPY: soft reboot
Traceback (most recent call last):
File “”, line 9, in
File “PiicoDev_VEML6030.py”, line 28, in init
OSError: [Errno 5] EIO

TMP117 Addr: 0x48 (default)

PiicoDev could not communicate with module at address 0x48, check wiring
PiicoDev could not communicate with module at address 0x48, check wiring
PiicoDev could not communicate with module at address 0x48, check wiring
nan °C
PiicoDev could not communicate with module at address 0x48, check wiring
PiicoDev could not communicate with module at address 0x48, check wiring
PiicoDev could not communicate with module at address 0x48, check wiring
nan °C
Traceback (most recent call last):
File “”, line 19, in
KeyboardInterrupt:

MS5637 Addr: 0x76

MPY: soft reboot
Traceback (most recent call last):
File “”, line 8, in
File “PiicoDev_MS5637.py”, line 69, in init
File “PiicoDev_Unified.py”, line 70, in write8
OSError: [Errno 5] EIO

SSD1306 Addr: 0x3c ()default)
PiicoDev could not communicate with module at address 0x3C, check wiring
PiicoDev could not communicate with module at address 0x3C, check wiring
Traceback (most recent call last):
File “”, line 40, in
File “PiicoDev_SSD1306.py”, line 220, in show
File “PiicoDev_SSD1306.py”, line 229, in write_cmd
KeyboardInterrupt:

Note: I did get a single instance where the RV3028 DID work, but was unable
to duplicate that result. This is what happened when I first noticed the issue.
I’d have several devices work fine and then one would stiop responding and from
that point none would work.

I’m sure it must be something ridiculously simple, but I simply don’t know what!

Cheers,
Alan

1 Like
7

Hi Alan
This might sound silly and a lot of people do it as a last resort. Have you been round the traps with a multimeter to make sure you have volts where you should have them. This problem certainly smells like something common to everything. ALL of the PicoDev modules are not going U/S at the same time.

I suggest checking the voltages as if anything is going to be common it is going to be the supply voltage.

Here is where a logic probe is handy as a check to make sure you are getting traffic on the SDA and SCL lines. You could even make one with a couple of components. Google “logic probe” and you will find out just how simple they can be.

Basis of all trouble shooting. Power supply to all bits first. Nothing can work if this is not right.
Cheers Bob
PS an oscilloscope an be used to check the presence of traffic but not everyone has one of these (I have 2). One of the most useful devices you can have in the workshop.

8

Thanks Bob.

Very quick check on one device (Pico W) and sensor (RV30238):

Pico - Ground/3.3v(out) = 3.3v
Adapter headers on those pins = 3.3v
JST Connector = 3.3V

Passthrough on RV3028 = 3.3v

I’ve got nothing to measure current with so I’ll assume its ok at this point. Seems to point to a signalling issue?

I’m visiting my son tomorrow and his (much) younger eyes and steadier hands can do this again for me. I’m hoping his tinkering with CANBUS may mean he has some of the other equipment to check the SDA/SCL lines.

I’ve got him lined up to do a lot of soldering of headers to a heap of devices for me. I gave him my soldering/rework station and most of my other gear when I could no longer do fine work anymore.

Just had a brilliant thought. I’m going to connect one of the sensors to an ESP32 and see what happens!

Cheers.

9

Hi Alan
Looks like the supply voltage is present in all the right places. That gets that out of the way. That I think leaves signalling as the next step. You can’t just connect a LED and resistor across these lines as the measuring device has to be high impedance so as to not upset the signal lines. You might see some activity with a multimeter but they are very slow and would probably miss it. What you could do though is measure the DC voltage on these lines with no activity. They should be near 3.3V, this will check the presence of the pull up resistors. If the voltage is not present that would signify no resistors and the I2C signalling would not work. If the voltage is low then you have a heavy load on the line for some reason, such as a short circuit or low resistance to ground. A short to ground would also result in zero volts.
Cheers Bob

10

G’day Bob.

Just to confuse things, my son soldered some pins on a new Pico (not a W) for me today.

I didn’t flash micropython, but put it on the Arduino IDE, loaded the Adafruit TMP117 library and dependencies and uploaded the sketch.

BINGO! Works perfectly.

I’m now suspecting I’ve damaged the Lipo Adapter board and the I2C part of it is fried.

Tomorrow, I’m going to kill a couple of snakes and reflash the other Picos to ensure they are both ok.

If that proves successful, I’ll order another interfave board next week.

Cheers.

11

Hi Alan
I thought that interface board was basically pin extensions and a bit of smarts to operate from and charge a limo cell. Don’t see much to fry there.

It seems strange to me that this was all OK until Sunday. Have a think, what did you do on Sunday. There has to be a reason.

All that board does is extend the pins to another female header for easier access and extend the default I2C and power connections to that little connector. Did you do any soldering in that area where you might have an unwanted solder bridge somewhere. You say you have tried several Picos in that set up with the same results, also new cables etc so the problem has to be something on the interface board

I personally don’t like unexplained failures, there always is a reason. have a good think about what you were doing on Sunday. There is always the possibility of an accumulating problem that does not show up straight away but fails after some time. But that usually involves solid state devices that are being progressively damaged and the only smarts on that board appear to be involved with battery charging and management. You have already measured all the right voltages in all the right places.
Cheers and good hunting. Bob

12

Hi Robert.

After a great deal of time and swapping components I can say with absolute certainty this:

Using a Pico:

  1. Each of the I2C devices/sensors work fine, both individually and in groups as long as address conflicts are avoided.
  2. The LiPo expansion/charging board works fine.
  3. All of the patch cables work fine and all connectors seem to be fine.

Using either Pico W:

  1. Test scripts that do simple things work fine.
  2. Connect to the network is fine.
  3. Plug in ANY of the I2C sensors/devices results in that E05 reporting no devices found.

The Pico uses a Type C USB connection and Pico W uses a micro USB, but connection to a different port has no effect, and I’ve had no issue running Pi Zero Ws from the USB ports.

Based on that, I can only conclude that I have somehow “cooked” the I2C interfaces on both Pico Ws.

I’m going to call it quits on this one and buy a couple more Pico Ws later in the week when I’ve put together a few other bits and pieces to make the postage worthwhile.

So thanks for your assistance.

Cheers,
Alan

1 Like
13

Hi Alan,

Just before you jump into your next project it might be worth checking a bit more quickly!

Have you tried running an I2C scan on micropython?

You can run it from the REPL using the following:

from machine import I2C
i2c = I2C(0)
i2c.scan()

How are you flashing micropython to the Picos/PIco W’s? If you are using files would it be possible to send through a screenshot of each of the filenames?
(You’ll need to use different uf2’s for each board as the wireless interface affects some backend stuff like how the LED is toggled)

Liam

1 Like
14

Hi Liam.

I am flashing via Thonny 4.1.1 under Windows 10.

The i2c code above has zero output i.e. I get → [ ] and nothing else with three devices connected.

What I have discovered is that if the BME280 module is connected, the attaching either the VEML6030 or the OLED display SSD1306 causes the E05 error, although both work in combination with other devices such as the TMP117, RV3028, etc.

According to the documentation, there should be no address conflicts.

I’m thinking of trying to put the BME280 onto the alternate 12c interface pins, but haven’t looked into what changes I’d need to make to my code (or the Library) to do that.

Cheers.

15

Hi Alan,
I had this same I2C problem using my BME280 sensor after upgrading and running micro python from 1.19 to 1.20.

All that I did was to install one 4.7k pull up resistor to the SDA signal and one to the SCL I2C signals. And suddenly my I2C worked again.

My suspicion is that something was altered during the Micro python s/w code upgrade.

Good Luck !

1 Like
16

Thanks for that Bo.

I’ll try it out today.

Cheers,
Alan

17

Hi Alan
I would be a bit careful with too many pull ups. If you have a number of I2C devices on the line all the installed pull ups will be in parallel and could end up being quite a low value with the possibility of stressing the driving device (Arduino, RPi etc). Most devices I have seen have these resistors fitted with the facility to remove them or insert them. Apparently Bo’s BME280 device did not have them either fitted or connected. The I2C system requires at least 1 pull up on each line but apparently could be anywhere or on any one of the connected devices but you have to be careful when removing a device to keep pull ups in circuit at all times. For this reason I think people just leave all of them connected. I have not seen anything published on where the optimum position for single resistors would be.
Cheers Bob

18

Hi @Alan37799 and all

There was a known issue when upgrading MP from 1.19 to 1.20. We released a patch in PiicoDev_Unified.py quite soon after. Is it possible you’re still working with an old version of Unified?

If you haven’t already, download the latest version of PiicoDev_Unified.py (right-click, save link as) and upload it to your Pico.

2 Likes
19

Hi Michael.

I’ve been using the upgraded version of PiicoDev_Unified.py for a while.

I noted it was a solution to a problem someone else had back in September, so grabbed it again “just in case”.

Didn’t help with this, unfortunately. Certainly, the problem appears to relate to the BME280 when used in combination with other sensors (or the OLED display).

I’ve decided to move the BME280 onto a separate device by itself for the time being.

Cheers,
Alan

1 Like
20

Hi @Alan37799 - it’s good to hear you’ve found a workaround but I am perplexed with this problem.
Thank you for documenting your troubleshooting. The split-tests were a great idea but only reveal more questions :sweat_smile:

It’ll be interesting to hear your results after split testing on fresh Pico Ws
Keep us up to date, and best of luck

1 Like