USB CDC device stuck

Forum|Forum|2 years ago
December 15, 2023
6 replies
3818 views

Hi All,

Here is the situation:

Device:

STM32G0B1CET6N - connected to PC with USB. USB CDC stack is running inside MCU.

PC:

Win10 Pro 64-bit, COM-port is recognized, Teraterm is running and both in and out data directions are working OK when the Teraterm is configured to the corresponding port.

Problem: When the Teraterm is not configured to the corresponding port (i.e. disconnected), the MCU firmware does not receive USB_ISTR_CTR interrupt and TxState remains 1, so further transmission is stuck.

Question: Is it possible to avoid this? (Monitor some endpoint status before sending data or other way?)

Thanks a lot and Best Regards,

Boris.

This topic has been closed for replies.

Best answer by Pavel A.

The most general and robust way (not relying on the host s/w to say goodbye gracefully) indeed is a timeout on send. For example if no IN requests (polls) come from the host for N seconds [and your TX queue/buffer overflows] you can decide that the host stopped listening. Of course, handle USB device events such as reset, re-enumeration, drop of voltage detector (for a self-powered device) - this also signals loss of connection. The USBD library provides callbacks for these events. IIRC there are no status variables in the library, you can roll your own state machine.

Pavel A.

No, when the host (program or driver running on the host) stops polling the USB device, the device cannot send anything. What to do in this situation, you decide.

RiseAuthor

Associate II

Hi Pavel,

Thank You for the answer. I understand that the device cannot send anything. The question is if it is possible to determine from within the MCU FW that host has stopped polling (or does not do it at all). Maybe there are some status variables withing the stack? Otherwise, the only option I see is a timeout, after which the MCU FW will stop sending data and will continue to make other things.

Best Regards,

Boris.

Pavel A.Best answer

The most general and robust way (not relying on the host s/w to say goodbye gracefully) indeed is a timeout on send. For example if no IN requests (polls) come from the host for N seconds [and your TX queue/buffer overflows] you can decide that the host stopped listening. Of course, handle USB device events such as reset, re-enumeration, drop of voltage detector (for a self-powered device) - this also signals loss of connection. The USBD library provides callbacks for these events. IIRC there are no status variables in the library, you can roll your own state machine.

RiseAuthor

Associate II

Thanks for an explanation! I indeed already implemented a timer and as far as I see it works.

gbm

Super User

You may implement SetControlLineState request . When the terminal opens, the received state is 3. You may start sending data no sooner than approx. 50 ms later. On disconnect, state changes from 3 to 1 or 0.

My STM32 stuff on github - compact USB device stack and more: https://github.com/gbm-ii/gbmUSBdevice