USB CDC detect dis-/connect Events (IDFGH-6065)

[moefear85]

Currently, there are are no dis-/connect events for usb cdc. Checking DTR/RTS is not a reliable way to detect usb dis-/connects, since many tools, including esptool.py, make non-standard use of them. This means there is no definite, unambiguous way to differentiate a dtr/rts toggle from a dis-/connect. Hence any call to tinyusb_cdcacm_write_flush(...) while the USB is disconnected, silently hangs. Using a timeout isn't a reliable solution, because it still causes hangs until the timeout is triggered, which would require very small values for it, but there are cases where larger timeouts are necessary under the assumption that the usb is still connected. Hence timeouts are also not a reliable/unambiguous way to detect USB disconnects.

Optionally, an additional esp-idf function that when called, returns a value that indicates USB connection status, would be a good idea.

[igrr]

Linking the related upstream issue: hathach/tinyusb#482

[moefear85]

TinyUSB does provide disconnect events for USB... the issue is simply that esp additions to CDC-ACM don't pass these on. One can manually register for those events though, look into components/tinyusb/tinyusb/usbd.c.

[dreamtrek]

got the same issue. I found unplugging event in usbd.c, but it never trigged.

[tore-espressif]

Hello @moefear85 @dreamtrek ,

"Device Connected" event is implemented an you can use in two ways:

1. Defining void tud_mount_cb(void); function.This function will be called when ESP32Sx is connected to USB Host
2. Calling bool tud_connected(void); that will return current connection status

For "Device Disconnected" event it is a little more complicated: USB mandates self-powered devices (this is your case) to monitor USB bus voltage. If you don't have USB V_BUS connected to ESP, you will never get the disconnection event.

As a workaround you can define void tud_suspend_cb(bool remote_wakeup_en); that will be called when self-powered device without V_BUS sensing is disconnected from USB Host.

I will leave this issue open as we need to provide an example of USB device with V_BUS sensing

[moefear85]

@tore-espressif

I understand detecting disconnect events is relatively complicated if one wants to strictly adhere to the standard. But I already discovered long ago that tinyusb actually properly detects these events as it logs them anyways, even without monitoring any lines, except the event isn't officially exposed. That's the point I made above. It would be useful though if esp-idf would expose it officially. I forgot now the name of the relevant event, but later I can patch it and create a PR. Right now the bugs in the uart subsys are more important. idf5 seems to be silently inserting BREAKs or malformed frames where they don't belong, which is inhibiting target chips from responding to any flashing attempts over an esp-based usb-uart-bridge.

[tore-espressif]

I don't understand what you mean by 'officially exposed`. The TinyUSB API is fully exposed, you can use it. (But it doesn't work without V_BUS sensing on ESP. The line monitoring is done by the USB-OTG peripheral, not TinyUSB)

Right now the bugs in the uart subsys are more important

We can discuss UART in different thread.

[moefear85]

I mean that there is no explicit callback function that one can assign for the event. It is consumed fully internally by tinyusb. ofcourse anyone can modify any part of the code, even private includes, but these aren't proper solutions. to be fully proper, such callbacks for disconnects would even have to be locatable in the documentation. but they aren't at the moment, because the event exists, but not a method to assign a callback like there is for CDC line coding and rx events.

[tore-espressif]

Agreed, two forms of callbacks is definitely misleading.

We plan to refactor the whole USB device side, I'll keep this in mind, thanks again!

[moefear85]

Upon closer inspection of usbd.c, and seeing the line 583:

if (tud_suspend_cb) tud_suspend_cb(...);

I realize why defining tud_suspend_cb works as a solution. Further testing also revealed DCD_EVENT_UNPLUGGED is never triggered because of reasons you mentioned above. The first time I looked at the code in the past, I just assumed since they are there, they get triggered. I see now this assumption was false. thx for the tip. Still, recieving DCD_EVENT_SUSPEND and DCD_EVENT_BUS_RESET are close and useful enough. But there is no assignable callback for it, so something like:

if (tud_reset_cb) tud_reset_cb(...);

would also be useful. Also, as a suggestion for the future when unifying the callback system, wouldn't the default event loop be ideal for this purpose? thx anyways. I'll close this for now since it contains enough information for others to move forward and prevent unwanted blocking when the usb cable is unplugged.

[wuyuanyi135]

I was investigating the same thing these days. I found checking tud_cdc_n_connected reflects the correct state of whether the CDC port has been opened or not.