[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

• 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 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.

[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.