USB CDC device stuck
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-12-15 4: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.
- Labels:
-
STM32G0 Series
-
USB
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-12-15 6:24 AM - edited ‎2023-12-15 6: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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-12-15 8: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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-12-15 12:51 PM
Thanks for an explanation! I indeed already implemented a timer and as far as I see it works.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-12-15 1:18 PM - edited ‎2023-12-15 1: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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-12-15 8: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
