tinyusb: Repeated disconnections causes the cdc_msc demo to stop functioning.

Describe the bug While testing whether the Synopsys driver survives a USB disconnect and reset, I decided to test repeated disconnects. After enough disconnects and reconnects, the cdc_msc demo will stop working on my laptop; both the Mass Storage device fails to appear, and the serial port will not send or echo data. This is despite me hearing the “device connected” jingle.

Set up (please complete the following information):

OS: Windows 7
Board: stm32f407disco
Firmware Code: e.g examples/device/cdc_msc

To Reproduce Steps to reproduce the behavior:

Compile the cdc_msc demo. I used the stm32f407disco board. Make sure to use my branch- I thought the bug was related, but I’m not sure anymore.
Repeatedly plug and unplug the USB cable into the host/device (this only works for boards which don’t rely on the user USB cable for power).
Eventually, the Mass Storage component will fail to mount in Explorer. Additionally, while the serial port will appear according to Windows, and opening it will succeed, the port will never send data (banner or otherwise).

Expected behavior Repeated connections and disconnections should consistently bring back both the CDC and MSC interfaces. The MSC interface should always be responding to IN packets.

Screenshots Not applicable.

Additional context I have attached a zip file of the bus activity from my Beagle: disconnect.zip

The MSC interface eventually stops responding to IN packets after enough disconnects/reconnects. Eventually Windows gives up trying to talk to the device completely; this naturally also breaks the CDC portion of the demo. Unfortunately at present, I don’t know enough about MSC or SCSI to debug this myself.

The CDC portion of the demo works fine, even after the MSC portion of the demo stops responding, up until Windows stops talking to the device completely.

I am not able to reproduce this in hid_composite.

About this issue

Original URL
State: closed
Created 5 years ago
Reactions: 1
Comments: 23 (14 by maintainers)

Most upvoted comments

I just tested the bugfix from #1021 with a simple CDC application on a custom STM32F105 hardware.

Using the last commit 89e4586 before bugfix led into the known behavior which stopped the CDC class to work after a few reconnections. Using the commit 48f17ef just after bugfix has always been stable to me. Even after 30 reconnections everything worked fine. Same positive behavior with the current master of course 😉.

duempel on Aug 16, 2021

This is on an nRF52833, not on a Fomu.

xobs on Apr 19, 2020

I’m working on it 😃 But my beagle is preventing my J-Link from working, so I need to dig out an ST-Link.

jeremyherbert on Dec 24, 2019

I managed to connect the debugger, and blink_interval_ms is set to BLINK_MOUNTED. So this is probably related to #209

Some random notes:

Debugger says:

_usbd_dev.configured = 1
_usbd_dev.connected = 1
_usbd_dev.remote_wakeup_en = 1
_usbd_dev.remote_wakeup_support = 1
_usbd_dev.self_powered = 0
_usbd_dev.suspended = 0

ISTR register only has the SOF bit set, all other status flags are 0. USB interrupt is no longer triggering. NVIC shows interrupt is still enabled however.

Beagle capture went from 70kB to ~600MB in about a minute while this was all happening. Seems to be a ton of data on EP3_OUT (~140 000 handshake NACKs, see pic below ), then device re-enumerates. Device re-enumerated 7 times before getting into this stuck state.

beagle

jeremyherbert on Dec 22, 2019

I think I have tripped on this bug as well. I have the tinyusb device (STM32F042) connected to a powered hub, and the hub is connected to my laptop. With enough sleep/wakeup cycles on the laptop, it seems to be disconnected.

mac os seems to enumerate the device as a “Vendor specific device”. I’m going to set up a second PC to try and reproduce.

MacBook_Pro

jeremyherbert on Dec 22, 2019