USBNSH is not working on STM32F4Discovery

[acassis]

I decided to help Ed to fix to USB issue #6531 and decided to test the USB on STM32F4Discovery board.

Unfortunately version 10.3.0, didn't work, then I decided to test 10.2.0, also didn't work, version 10.0.0 shows the "nsh>" but doesn't work and display the message: "nsh: nsh_session: readline failed: 9"

The only working version was 9.1.1! It means it was working around Dec 2020, but stopped to work some time later.

Once again we need to find a way to automatically test these boards, unfortunately only getting a board passing on CI test is not enough.

These are the step to duplicate the issue

$ ./tools/configure.sh stm32f4discovery:usbnsh
$ make
1) Flash the firmware in the board
2) Connect a Micro USB cable to CN5 connector
3) It will create a /dev/ttyACM0 on your computer, then configure minicom to use this /dev/ttyACM0 port
4) On minicom press ENTER 3 times, the "nsh>" will not show up

[acassis]

Can someone else confirm the issue is happening for you too? @masayuki2009 @xiaoxiang781216 @btashton @pkarashchenko @hartmannathan ... ?

[ALTracer]

@acassis I happen to have access to a similar board. I tested stm32f429i-disco:usbnsh which has USB FS 1.5 Mbps via USB-HS internal PHY (the other pins conflict with SDRAM), and I was disappointed. ICMP ping and DHCPd seem to work okay both ways with my Linux PC host, but iperf3 quickly crashes the board somewhere in mm, I think. Keep in mind FS permits only 64-byte packets, and I had set default MTU of around 512. iperf3 settings: I tried TCP, UDP, default packet length and 64-byte length, low bitrates and 1M. Telnet works, which is the sole purpose of "usbnsh", I guess.

I wanted to test some networking servers on that board because it boasts 8 MBytes of 45-nanosecond SDRAM on FMC, and then move on to prototyping on another device. The servers in question crashed another board (nucleo-h743zi2 with true Ethernet) due to insufficient SRAM.

[hartmannathan]

@acassis I have not had the opportunity to check with this board yet. Currently in the midst of some heavy duty work on a different arch. I'll try to look into it soon.

@ALTracer is it possible that some task(s) need a larger stack size?

Has the issue appeared recently? (i.e., has it been known to work in the past?) If so, I would try git bisect to find which commit introduced the regression.

[masayuki2009]

@acassis

I tested the following configurations remotely.

stm32f4discovery:usbnsh DELL OptiPlex 7050 (ubuntu 18.04 x86_64 + gcc-arm-none-eabi-10.3-2021.10 + picocom)

the latest master: OK nuttx-10.3.0: OK nuttx-10.2.0: OK

Please note that the USB cable between the stm32f4discovery and the PC has always been connected.

[zouboan]

I build on ubuntu 16.04 and gcc-arm-none-eabi-7-2017-q4-major the stm32f4discovery:usbnsh on nuttx-master and nuttx-10.3.0 is OK with minicom

[acassis]

thank you @ALTracer @hartmannathan @masayuki2009 and @zouboan for confirm it is working, so the issue could be in my computer

DELL XPS 9510 (using default Ubuntu 20.04 arm gcc toolchain: gcc version 9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599] (15:9-2019-q4-0ubuntu1) )

[acassis]

@ALTracer about your comment:

Telnet works, which is the sole purpose of "usbnsh", I guess

The "usbnsh" configuration doesn't use or depends on telnet, but I understood what you are using: rndis over USB and running telnet to access that board. Since you just want to use this board was server, it could be better to use nsh over serial and let the USB network reserved to your web server purpose.

I saw that Masayuki just included the iperf configuration to stm32f4discovery rndis profile, I will test iperf too to see if the issue also happens on stm32f4discovery.