[BUG] PR #15931 breaks ttyACM

[jlaitine]

Description / Steps to reproduce the issue

After PR #15931 , I am experiencing USB crashes in the following use case:

1. Have ttyACM serial connection open between the PC and NuttX device (MPFS 64-bit risc-v)
2. Continuously send data from PC to the device, and from device to PC
3. Pull the USB plug

Result:
[CPU0] riscv_exception: EXCEPTION: Load access fault. MCAUSE: 0000000000000005, EPC: 00000000a003490a, MTVAL: 000000014065b788
[CPU0] riscv_exception: PANIC!!! Exception = 0000000000000005
[CPU0] dump_assert_info: Current Version: NuttX 10.4.0 fa125d9 Mar 17 2025 14:27:35 risc-v

Reverting commit c497c5f fixes the issue

Here is some further info:

• priv->nwrq increases uncontrollably after the USB has been disconnected. Also before disconnecting, it grows beyond CONFIG_CDCACM_NWRREQS
• priv->nwrq increase causes also debugassert at cdcacm_unbind, if unbinding the connection
• priv->txfree gets corrupted in cdcacm_sndpacket, here the EP_SUBMIT(ep, req); will cause a call to cdcacm_wrcomplete, which keeps adding the same wrcontainer to the txfree.

The issue is seen in SMP, single-core and in CONFIG_BUILD_KERNEL and in CONFIG_BUILD_FLAT

On which OS does this issue occur?

[OS: Linux]

What is the version of your OS?

Ubuntu 22.04

NuttX Version

master

Issue Architecture

[Arch: risc-v]

Issue Area

[Area: Drivers]

Host information

No response

Verification

• I have verified before submitting the report.

[yangsong8-a1]

@jlaitine
Is the action of unplugging the USB in the process of continuous data transmission?
What tool is used for continuous data transmission? Can you share it?
Can you explain the detailed steps to reproduce the problem? I will follow your step to reproduce it.
thank you！

[michallenc]

Hi, I also had some issues with CDC ACM after the patch, but only for our custom Silicon Heaven protocol, wasn't able to reproduce it with a simple application I could share to reproduce. To be short, we use a lot of request-response communication and sometimes the response is not sent from the board to the computer. This happens only after the patch and I don't think it is caused by the protocol as it only uses calls like fwrite/fread/etc. It seems more like some timing issue with endpoints or requests.

The configuration change of CONFIG_CDCACM_NWRREQS and CONFIG_CDCACM_NRDREQS from 4 to 8 helped, but this seems more like a hot workaround than a proper solution. I have tested it only on SAMv7 MCU, so it may be related to that MCU as well (the USB there is a mess, it is slow as hell, I am getting 10 times slower communication than I should have, but haven't had time to look at that properly yet).

This is just for info, maybe it is related to this issue, but I don't expect you to invest time into this as this can't be easily reproduced and might be only SAMv7 related. I plan to look in to it in some days, hopefully.

[jlaitine]

I have re-produced the problem now also on i.MX93 target.

I wrote a test program to show the issues specifically:

1. serial IOCTL:s are broken (I used FIONREAD in the test app)
2. the whole device crashes when exiting the app

0001-Replace-helloworld-with-ttyACM-test-app.txt

These issues are not present with the same app if the PR is reverted. Attached test app as a patch (renamed to .txt because github doesn't accept patch files). The patch just replaces the helloworld example in the "apps". Tested against current nuttx master.

Steps to re-produce:

1. Make sure cdc acm is not already initialized at boot in board files or such, otherwise you can't initialize/uninitialize cdcacm by the app
2. Have the following configs and build the image:
   CONFIG_BOARDCTL=y
   CONFIG_BOARDCTL_USBDEVCTRL=y
   CONFIG_EXAMPLES_HELLO=y
   CONFIG_CDCACM=y
   (and the other needed cdcacm configs)
3. launch the "hello" app in nsh terminal
4. open another terminal on PC to /dev/ttyACMx
5. note that test app should keep printing "Hello World" to the other terminal
6. type in characters to the other terminal, monitor that they are printed on the nsh terminal by the test app
7. type ctrc-c to exit the test app
   -> this will lead to crash

Other test showing that serial ioctls don't work;

1. comment out the line "bytes_to_read = 1;" in the test app, re-build, re-run
2. now the nsh terminal should print out 2 characters after entering 2 chars to the PC side (doesn't work because the FIONREAD always returns 1).
3. after entering more characters the sw will eventually lock up

[acassis]

@yangsong8-a1 please take a look!

[yangsong8-a1]

@acassis ok

[yangsong8-a1]

I tried 3 boards, esp32s3-devkit, raspberrypi-pico-2, sim usbdev, and after exiting the test app, it did not crash. I will try other environments.

[jlaitine]

Does the FIONREAD ioctl work for you on those platforms?

[yangsong8-a1]

There is indeed a problem with FIONREAD ioctl. I will solve this problem first.
Could you please help to analyze the crash problem in depth? I haven't found a suitable reproducible environment so far.
Thank you.

[jlaitine]

There is indeed a problem with FIONREAD ioctl. I will solve this problem first. Could you please help to analyze the crash problem in depth? I haven't found a suitable reproducible environment so far. Thank you.

I'll come back to this after the FIONREAD ioctl thing is resolved, just in case the issues are related