Skip to content
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

Reset and disconnection with W5500 #65

Open
andrewmarles opened this issue Jun 21, 2023 · 5 comments
Open

Reset and disconnection with W5500 #65

andrewmarles opened this issue Jun 21, 2023 · 5 comments

Comments

@andrewmarles
Copy link
Contributor

andrewmarles commented Jun 21, 2023

A couple of things I've noticed testing W5500 on a new version of the PicoBOB.

First, the reset pin does not appear to be toggling correctly. I do not have a scope handy to check things (in the middle of a move) but I can assign the pin in question as Auxoutput and toggle it correctly (I see the W5500 reset) so I do not think it is a physical problem. But when I assign the pin to SPI_RST_PIN it never toggles and the W5500 remains in reset.

If I leave the pin unassigned (defaults to input) then because of the nature of my board, the W5500 comes up correctly on power-up and I am able to then use Ethernet (websockets, ping etc) as expected.

That said, I have noticed that after some amount of time (still zeroing in on this, measured in hours) the board stops responding to pings and loses websocket connection. This does not happen with W5500 on the STM32/FlexiHAL (at least so far I have had it remain connected for days at a time). I will keep digging to try to see if this is maybe a local networking issue or something, but just wanted to post my experiences so far with this new stuff. Thanks very much for putting this together.

image

@andrewmarles
Copy link
Contributor Author

@terjeio
Copy link
Contributor

terjeio commented Jun 22, 2023

I'll wire up my Pico again and run some long time tests to see if I can replicate this.

@terjeio
Copy link
Contributor

terjeio commented Jun 23, 2023

FYI the network stack died after running the test job for 6 hours, the controller did not as the current stream was switched back to USB so I was able to talk it without resetting. This means that the connection was likely cleanly closed before the stack died. Running a new test now, will try to debug this if/when the stack crashes again...

@terjeio
Copy link
Contributor

terjeio commented Jun 26, 2023

After adding a 4K7 pullup resistor on the IRQ line I have now run tests for ~19 hours without failure. Can you try the same?
I have yet to check the reset line.

@andrewmarles
Copy link
Contributor Author

Interesting, I can try the same. I double checked just now and it does appear that the RP2040 has a weaker internal pullup than the STM32 so this is a plausible explanation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants