2018-05-04 05:46 PM
Context. I using CubeMx on a STM32L462 with FreeRTOS (works fine). When enabled, MX_USB_DEVICE_Init() is added to the default FreeRTOS task to activate a USB channel which also works fine.. I have my USB channel set up as a CDC serial io device (works fine) and have a VUSB bus detection on a GPIO EXTI input pin (also works fine but isn't hooked in).
Case 1. If the application is sending via CDC_Transmit_FS the normal mechanism will busy out forever when the USB port disconnects which causes my queues to back up like a pluged up drain. This is bad. I would normally expect some sort of a FAIL return in this case so that I could simply flush the output bytes rather than letting them pile up in the queues.
Question 1: What is the normal HAL/CubeMx mechanism for the application to know that it is not connected to an active computer port.
Question 2: Given the ability to detect VUSB's presence, being plugged in or unplugged, what is the normal HAL/CubeMx mechanism to deinit and reinit the STM's USB device subject to the answer to Question 1.
Any pointers will be helpful.
#usb-inactive #usb-vbus #usb-init #usb-deinit #usb-active2018-08-10 09:37 AM
Sorry, bumping old zombie unanswered threads off my feed