-
Notifications
You must be signed in to change notification settings - Fork 412
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hang with Pico W when using a W5500 and WiFi at the same time. #2156
Closed
Comments
earlephilhower
added a commit
that referenced
this issue
May 15, 2024
When a ping is sent from the Pico, a raw_recv callback is added which sees all raw incoming packets to detect the response from the ping target. If while waiting for the target response an external ping packet arrives this incoming ping request packet will be processed by the LwipIntfDev<>::_pingCB which will return "0" not processed and which *should* not change the payload unless it handles the actual packet. Unfortunately, the 20 byte header was unconditionally stripped off of the packet before checking if this was our response, changing the payload address and causing an assertion in LWIP. Fix by using absolute offsets inside the raw packet for the ping response checks. Fixes #2156 Fixes #2149
earlephilhower
added a commit
that referenced
this issue
May 15, 2024
When a ping is sent from the Pico, a raw_recv callback is added which sees all raw incoming packets to detect the response from the ping target. If while waiting for the target response an external ping packet arrives this incoming ping request packet will be processed by the LwipIntfDev<>::_pingCB which will return "0" not processed and which *should* not change the payload unless it handles the actual packet. Unfortunately, the 20 byte header was unconditionally stripped off of the packet before checking if this was our response, changing the payload address and causing an assertion in LWIP. Fix by using absolute offsets inside the raw packet for the ping response checks. Fixes #2156 Fixes #2149
This issue was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Discussed in #2149
Originally posted by rpineau May 7, 2024
Fisrt some background :
I have a system where a "rotator" Arduino Due controls an observatory dome and a "shutter" Arduino Due which control said dome shutter.
The "rotator" arduino due use a W5500 to connect to the local network and both Due communicate with each other using XBee modules:
Local network <----> [W5500/Rotator Due/XBee] <-----> [Xbee/Shutter Due]
I'm now working on replacing these with Raspberry Pi Pico W and want to use the WiFi connection to replace the XBees.
I ported the code to the Pico W. Core 0 is for communications (Ethernet, WiFi and serial) and Core 1 takes care of the motion (it drives
stepper motor using the AccelStepper library) :
Local network <----> [W5500/Pico W/WiFi] <-----> [WiFi/Pico W]
The problem(s):
When disabling WiFi on the "rotator", Ethernet works fine and all is good.
But as soon as I want to add WiFi problems starts and the WiFi connections between the 2 Pico W keeps failing.
It also seems to create some timeout on the W5500 side (pinging the "rotator" Pico W from a machine starts failing).
To try to figure out the issue I made 2 small test firmware that only use the ping function.
As far as I can tell the issue comes from the Pico W that also has the W5500 . After a bit of time it locks up in the wifi ping function.
I also try with just WiFi between the 2 Pico W. This is more stable but I see a lot of drops at the beginning and then latter on (not repeatable timing as far as I can see).
So the question is .. Am I doing something wrong or is this a "bug" and the Pico W can't do Ethernet and WiFi at the same time ?
The test code can be found there :
https://rti-zone-files.s3.amazonaws.com/test-rp2040.tgz
Thanks for any insight.
Rodolphe
The text was updated successfully, but these errors were encountered: