Reset and disconnection with W5500

[andrewmarles]

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.

[andrewmarles]

My WIP branch is here:
https://github.com/Expatria-Technologies/RP2040/tree/picobob_deluxe

[terjeio]

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

[terjeio]

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]

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]

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.