cancel
Showing results for 
Search instead for 
Did you mean: 

USB CDC device stuck

Rise
Associate II

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.

1 ACCEPTED SOLUTION

Accepted Solutions
Pavel A.
Evangelist III

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.

 

View solution in original post

6 REPLIES 6
Pavel A.
Evangelist III

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.

 

Rise
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.
Evangelist III

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.

 

Rise
Associate II

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

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.

Piranha
Chief II