2023-12-15 04:45 AM
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.
Solved! Go to Solution.
2023-12-15 12:35 PM
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.
2023-12-15 06:24 AM - edited 2023-12-15 06:25 AM
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.
2023-12-15 08:41 AM
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.
2023-12-15 12:35 PM
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.
2023-12-15 12:51 PM
Thanks for an explanation! I indeed already implemented a timer and as far as I see it works.
2023-12-15 01:18 PM - edited 2023-12-15 01:20 PM
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.
2023-12-15 08:33 PM
But for serious purposes get rid of the ST's broken and bloated parody of a USB stack and use a stack developed by competent people:
https://github.com/hathach/tinyusb/tree/master/examples/device/cdc_dual_ports/src