[BUG] w5500-evb-pico is not reachable over usbnsh

[bskdany]

Description / Steps to reproduce the issue

The w5500-evb-pico appears offline after flashing config usbnsh starting with commit 1fe07d0838084016b47aeb4650dfec29590f45be which is related to pr #15285

Steps to riproduce:

1. git checkout 1fe07d0838084016b47aeb4650dfec29590f45be
2. ./tools/configure.sh -l w5500-evb-pico:usbnsh
3. sudo dmesg says the device appears offline
4. Repeating the same process with the commit coming right before it badb5c5ac69574aca724a79f5256e8d8b49e8ba8 shows that it is perfectly functional

On which OS does this issue occur?

[OS: Linux]

What is the version of your OS?

Pop!_OS 22.04 LTS

NuttX Version

master

Issue Architecture

[Arch: arm]

Issue Area

[Area: Board support]

Verification

• [x] I have verified before submitting the report.

[acassis]

@wengzhe any idea why that commit could break usbnsh ?

[linguini1]

@wengzhe any idea why that commit could break usbnsh ?

If I had to guess it might be that something is crashing before NSH is booted, the startup time is quite long on the working builds which I'm guessing is due to starting the networking services

[linguini1]

I have bisected myself and I am of the impression that this was a mistaken perception of fail to boot because of the duration of the boot sequence when starting networking services. I am able to boot the W5500-EVB-Pico on the latest master branch of both the nuttx-apps and nuttx kernel repos. I'll wait for @bskdany to test again and confirm but I think this issue might be able to be closed

[justapotato213]

I can reproduce the same issue on Windows 11 with WSL, using commit badb5c5ac69574aca724a79f5256e8d8b49e8ba8 has the device in device manager show up while 1fe07d0838084016b47aeb4650dfec29590f45be doesn't.

If I had to guess it might be that something is crashing before NSH is booted, the startup time is quite long on the working builds which I'm guessing is due to starting the networking services

One thing I noticed is that the board's debug LED remains solid with badb5c5ac69574aca724a79f5256e8d8b49e8ba8 while flashes on and off repeatedly with 1fe07d0838084016b47aeb4650dfec29590f45be, so your theory seems right.

[acassis]

I can reproduce the same issue on Windows 11 with WSL, using commit badb5c5 has the device in device manager show up while 1fe07d0 doesn't.

If I had to guess it might be that something is crashing before NSH is booted, the startup time is quite long on the working builds which I'm guessing is due to starting the networking services

One thing I noticed is that the board's debug LED remains solid with badb5c5 while flashes on and off repeatedly with 1fe07d0, so your theory seems right.

The the status LED flashes, it means the system crashed. Probably you need to increase the stack size to get it working.

[bskdany]

It looks like this issue is router dependent, it works if I connect the w5500 to a bridged wifi connection over LAN from my laptop. It doesn't work if I wire directly to the router. I am able to get shell if I enable CONFIG_NETINIT_THREAD but once I'm in there is a lot of lag, running ifconfig hangs everything.

[acassis]

@bskdany good finding, maybe it it blocked waiting some specific packet (DHCP??) and for some router it doesn't come and the boot process get stuck. When you enable CONFIG_NETINIT_THREAD the boot process works in parallel to network initialization.

Suggestion: use wireshark to investigate what happen in both routers. Did you try to use a laptop with Linux to share Internet with your pico board? I used it to investigate why MQTT wasn't working on NuttX: https://acassis.wordpress.com/2022/10/31/trying-to-fix-a-mqtt-communication-issue-with-nuttx-and-tagoio/