Troubleshooting 2 Pi picos over Ethernet? #17199

jouellnyc · 2025-04-28T00:44:54Z

jouellnyc
Apr 28, 2025

Connecting Two Raspberry Pi Picos via Ethernet (Directly!)

Goal

Establish reliable Ethernet communication between two Raspberry Pi Picos using a short (1-foot) cable.

TL;DR

While a direct, short Ethernet connection between two devices isn't standard practice, I've managed to get it working reliably for extended periods (8+ hours). I'm seeking insights into why it's sometimes inconsistent and if there are specific Ethernet startup parameters I might be overlooking. This is purely for a fun, space-saving aspect of a larger personal project. Any advice or learning opportunities are highly appreciated!

Background & Motivation

This endeavor stems from a desire to create a compact and visually appealing setup for a larger project. Directly connecting the two Picos via Ethernet, if reliable, would be a cleaner solution than introducing a network switch. Even if it ultimately doesn't become the permanent solution, the troubleshooting process promises to be educational.

Steps Taken

Hardware Setup:
- Two Raspberry Pi Picos connected to "USR-ES1 W5500 Ethernet Network Module Hardware SPI to LAN/ Ethernet 8000 TCP ... W5100" modules.
- Interconnection via a Crossover Adapter:
- Initially used MicroPython v1.24.1 (2024-11-29) and recently upgraded to MicroPython v1.25.0 (2025-04-15), specifically the W5500-EVB-PICO build.
- The W5500 module in use looks like this:
IP Configuration:
- Both Picos are configured to assign themselves static IP addresses within the same subnet.

Observations

Inconsistent Direct Connection: Communication between the two Picos via the 1-foot crossover cable is often successful (one Pico acts as a web client, the other as a microdot web server). However, the connection is unreliable; sometimes they connect without issue, and other times they fail to establish communication.
Cable Testing: I've tried two different 1-foot crossover cables and a 3-foot crossover cable, all exhibiting the same inconsistent behavior.
Successful Switch Connection: When both Picos are connected through a standard network switch using regular Ethernet cables, the communication has been consistently reliable. This strongly suggests the issue lies with the direct connection via crossover cables.
Long-Term Stability (When it Works): Interestingly, when the direct 1-foot connection does establish, it has proven stable for extended periods. During one test, it ran flawlessly for over 8 hours without any drops or errors.
Hardware Swap: I also swapped out one of the W5500 modules with another identical unit, but the inconsistent behavior persisted.

MicroPython Configuration

Here's the MicroPython code snippet used on both Picos (with the IP address adjusted accordingly):

I followed the wiznetdoc for the pins.

import time
import network
from machine import Pin,SPI

spi=SPI(0,2_000_000, mosi=Pin(19),miso=Pin(16),sck=Pin(18))
nic = network.WIZNET5K(spi,Pin(17),Pin(20))
nic.active(True)
nic.ifconfig(('192.168.0.152', '255.255.255.0', '192.168.0.197', '8.8.8.8')) # Example IP for one Pico
time.sleep(2)
print(nic.isconnected())
print(nic.regs())
print(nic.ifconfig())
print(nic.active())

== output
True
Wiz CREG:
  0000: 00 00 00 00 00 00 00 00 00 02 31 03 28 61 9a 00
  0010: 00 00 00 00 00 00 00 00 00 07 d0 08 28 00 00 00
  0020: 00 00 00 00 00 00 ff ff 00 00 00 00 00 00 bf 00
  0030: 00 00 00 00 00 00 00 78 25 04 00 00 00 00 00 00
  0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Wiz SREG[0]:
  0000: 84 00 00 42 c0 00 ff ff ff ff ff ff 00 00 00 00
  0010: 00 00 05 c0 00 00 80 00 00 00 00 00 00 00 10 10
  0020: 40 00 02 ec 02 ec 00 00 00 00 00 00 ff 40 00 00
Wiz SREG[1]:
  0000: 00 00 00 00 00 00 ff ff ff ff ff ff 00 00 00 00
  0010: 00 00 00 00 00 00 80 00 00 00 00 00 00 00 00 00
  0020: 00 00 00 00 00 00 00 00 00 00 00 00 ff 40 00 00
Wiz SREG[2]:
  0000: 00 00 00 00 00 00 ff ff ff ff ff ff 00 00 00 00
  0010: 00 00 00 00 00 00 80 00 00 00 00 00 00 00 00 00
  0020: 00 00 00 00 00 00 00 00 00 00 00 00 ff 40 00 00
Wiz SREG[3]:
  0000: 00 00 00 00 00 00 ff ff ff ff ff ff 00 00 00 00
  0010: 00 00 00 00 00 00 80 00 00 00 00 00 00 00 00 00
  0020: 00 00 00 00 00 00 00 00 00 00 00 00 ff 40 00 00
None
('192.168.0.252', '255.255.255.0', '192.168.0.197', '8.8.8.8')
True

Question

Could the inconsistent connectivity be related to the Ethernet startup parameters being configured incorrectly by default? After some searching, I haven't found clear methods within the network.WIZNET5K class to explicitly set parameters like duplex or speed, nor much in the way of advanced debugging options.

I often encounter a "wiznet5k_send_ethernet: fatal error -5" message, although my searches for this specific error in the context of Micropython haven't yielded much information. I did notice the keyword in the Micropython source code: micropython/extmod/network_wiznet5k.c.

Any insights, suggestions for further debugging, or potential solutions would be greatly appreciated! Thanks in advance for your help!

jouellnyc · 2025-05-03T03:19:54Z

jouellnyc
May 3, 2025
Author

For comparison I put 2 of these together w/a 1 foot cable and cross over. (Alpine linux and 64 MB)

I got similar behavior in that I could ping back and forth and then all of a sudden "ping: sending packet: Network is unreachable".
Perhaps it is unreasonable to use such a short cable but again - it mostly worked so I pursued it.

I think for now I have my answer...

0 replies

KnorkFox · 2025-05-03T14:17:48Z

KnorkFox
May 3, 2025

The length of the cable, has no relevance. Any TP-Cable, up to 500m should work. There are cables, which are already crossed. You could try another one.
For the bug, i have no clue. It could be a bad sodering connection, or a software bug.
For testing, i would connect it to a PC, and ping it for hours. Just my 2 cents.

Good luck
risky

1 reply

jouellnyc May 4, 2025
Author

Great suggestion about pinging it repeatedly. Thanks for the reply.

Josverl · 2025-05-03T16:02:37Z

Josverl
May 3, 2025
Sponsor

You may not need the cross-cable at all if you set the PHY to 100Mb auto nego. IIRC The standard mandate the nego can detect crossover, though I can't find that mentioned in the specsheet.
https://docs.wiznet.io/img/products/w5500/W5500_ds_v110e.pdf

Pg. 42

4 replies

robert-hh May 3, 2025
Collaborator

The problem seems to be in the initial negotiation phase. That would explain why it is stable after the link succeeded once. Switches may better deal with auto-negotiation of phase and direction.
There might be also timing differences between using a switch or a direct cross cable. Switches use usually a store and forward approach, so the first bit of a message should not arrive before the last bit has been sent.
The length of the cable should not matter. At 100MBit, the length of a bit is about 2m, so the difference between a 1 and 3 feet cable is still below a single bit. Only a MUCH longer wire could make a difference.

though I can't find that mentioned in the specsheet.
@Josverl It's on the second page of the document you have linked.

jouellnyc May 4, 2025
Author

Thank you Robert. It still may have something to do w/the initial negotiation but interestingly I was able to wait 10-15 seconds and it did connect - with NEW hardware. I was pretty much convinced is was a timing issue, but I have more detail below. Thanks!

jouellnyc May 4, 2025
Author

You may not need the cross-cable at all if you set the PHY to 100Mb auto nego. IIRC The standard mandate the nego can detect crossover, though I can't find that mentioned in the specsheet. https://docs.wiznet.io/img/products/w5500/W5500_ds_v110e.pdf

Pg. 42

Thanks @Josverl I tried both with and without the crossover. Not much of a difference before I got this back stable with new hardware. After it was stable I also tried. My cable setup only worked with the crossover and I haven't found clear methods within the network.WIZNET5K class to explicitly set parameters like duplex or speed...but right now it appears that both side are working with with the code I initially posted.

KnorkFox May 5, 2025

You may not need the cross-cable at all if you set the PHY to 100Mb auto nego. IIRC The standard mandate the nego can detect crossover, though I can't find that mentioned in the specsheet. https://docs.wiznet.io/img/products/w5500/W5500_ds_v110e.pdf

Pg. 42

negative. On page 62:

5.5.6 MDIX
W5500 does not support auto-MDIX feature.
You really need one crossed cable between two hosts. If you connect to a switch, it does not matter, because the switch has probably auto-MDIX.

Fox

jouellnyc · 2025-05-04T21:08:49Z

jouellnyc
May 4, 2025
Author

Thanks all for the suggestions.

For comparison, I tried with a 50 ft cable w/or w/o crossover and it did not work.
I tried a little Ethernet splitter and it did not work.

Just as I was thinking it was not going to work, I got it to work with new hardware.
That is, I bought 2 more of the same modules. They did not both work but one of them did.

Initially I bought 3 and I think as @KnorkFox mentioned maybe it was a soldering issue/etc because I now have in my possession:

3 modules that work 'consistently' (at least for the last 24 hours)
1 that lights up it's red LED but does not connect
1 that lights up it's red LED initially (but a lot more faintly than the others) and then it goes out! - I have never seen that before... obviously does not connect

I.E I have a 40% module failure rate. And I think that one that is slowly fading it's LED (I don't remember that happening prior to posting) may just be the kicker so to speak. That is, it probably worked before and then now not -- who knows -- but it plausible. I was very diligent in ensuring wires and pins are lined and tight...

Further when I got these to connect now, I tested explicitly by turning one on and WAITED 10-15 seconds to turn on the other... it still worked. I did this a few times. I.E. I thought maybe I had to get these to turn on and negotiate as closely as possible time-wise. Turns out that is a huge no. I was able to wait as I mention.

So I think I'm going to turn these on/off a few times a day and see if they remain stable.

If they do , great. Maybe we got to the bottom of it and I can use the project as intended.
If the good ones fail soon, maybe I will try for a different hardware model, but I really like the space saving form factor...

If I learn anything substantial apart from this, I'll be sure to post.

3 replies

KnorkFox May 10, 2025

A high voltage esp shock, is possible. Do you care about static electricity?

jouellnyc May 10, 2025
Author

Thanks for the thought . I think I am pretty careful.

jouellnyc May 10, 2025
Author

Finally:
After a week of testing, it worked great for Day 1 and Day 2, then stopped on Day 3....Just no connection.
I changed Nothing...

Now, I literally disconnected both from each other, and immediately connected them to my LAN - both get DCHP IPs and connect to google A-OK, so it's not 'bad' hardware - they clearly work.

Just seem like an ethernet negotiation phase like robert-hh mentioned. I think I pretty much done w/this....
...unless I find a small 2-port switch...

I guess it makes more sense if I share the pic/link too of the project:

https://github.com/jouellnyc/UART/tree/main/rainbow

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

MicroPython

Troubleshooting 2 Pi picos over Ethernet? #17199

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Replies: 4 comments 8 replies

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

Select a reply

MicroPython

Troubleshooting 2 Pi picos over Ethernet? #17199

jouellnyc Apr 28, 2025

Connecting Two Raspberry Pi Picos via Ethernet (Directly!)

Goal

TL;DR

Background & Motivation

Steps Taken

Observations

MicroPython Configuration

Question

Replies: 4 comments · 8 replies

jouellnyc May 3, 2025 Author

KnorkFox May 3, 2025

jouellnyc May 4, 2025 Author

Josverl May 3, 2025 Sponsor

robert-hh May 3, 2025 Collaborator

jouellnyc May 4, 2025 Author

jouellnyc May 4, 2025 Author

KnorkFox May 5, 2025

jouellnyc May 4, 2025 Author

KnorkFox May 10, 2025

jouellnyc May 10, 2025 Author

jouellnyc May 10, 2025 Author

jouellnyc
Apr 28, 2025

Replies: 4 comments 8 replies

jouellnyc
May 3, 2025
Author

KnorkFox
May 3, 2025

jouellnyc May 4, 2025
Author

Josverl
May 3, 2025
Sponsor

robert-hh May 3, 2025
Collaborator

jouellnyc May 4, 2025
Author

jouellnyc May 4, 2025
Author

jouellnyc
May 4, 2025
Author

jouellnyc May 10, 2025
Author

jouellnyc May 10, 2025
Author