STM32F103 виртуальный СОМ-порт (USB CDC) и сообщение WM_DEVICECHANGE, В сообщениях "WM_DEVICECHANGE" STM32 USB CDC не определяется к Опции

[Mazay]

На STM32F103 поднят виртуальный СОМ-порт (USB CDC). Используется стандартная библиотека от STM. Все работает. Байты летают туда-сюда. Однако, при отлаживании устройства, наверно многие обратили внимание, что после перезагрузки/перепрошивки контроллера, виртуальный порт «отваливается». Однако во всех доступных мне терминальных программах он так и остается открытым. Данные при этом естественно никакие не идут. Если в терминальной программе закрыть порт, то открыть его не получится. Нужно опять перезагрузить микроконтроллер и только тогда снова открыть порт. Т.е. правильная последовательность действий должна быть такая:
1. Закрыть порт в терминальной программе.
2. Перезагрузить/препрошить и т.д.
3. Открыть порт в терминальной программе.
Обычно про эту последовательность вспоминаешь, когда уже успел загрузить новую прошивку, контроллер перезагрузился и виртуальный порт «отвалился».

В самописной терминальной программе решил оптимизировать этот процесс. Реализовал получение от Windows системных сообщений WM_DEVICECHANGE указывающих на изменения в устройствах. Из этого сообщения нужны события DBT_DEVICEARRIVAL и DBT_DEVICEREMOVECOMPLETE – подключение и удаление устройства соответственно. Далее можно проанализировать Тип устройства которое подключилось или было удалено из системы. Наиболее интересен тип DBT_DEVTYP_PORT, который как раз и является указывающим на Последовательный или Параллельный порт. И вот тут с устройством на STM32 возникла неприятность. При подключении или отключении STM32 событие с типом устройства DBT_DEVTYP_PORT не присылается! Помимо типа DBT_DEVTYP_PORT есть общий тип DBT_DEVTYP_DEVICEINTERFACE указывающий вообще на любое устройство. Вот приходит только событие с этим типом и все. Я проверил имеющиеся у меня переходники USB<->COM на FT232, CPxxx, PL2303 и китайской CH340. При их подключении/отключении помимо событий с общим типом DBT_DEVTYP_DEVICEINTERFACE всегда приходит событие с типом DBT_DEVTYP_PORT по которому легко определить, что конфигурация портов изменилась, а получив из возвращаемой структуры поле Name, можно сразу определить какой порт подключился/удалился. Собственно вопросы к знатокам: В какую сторону стоит копнуть, чтоб и при подключение/удалении STM32 получать сообщение DBT_DEVTYP_PORT? Кто отвечает за рассылку этих сообщений? Я подозреваю, что драйвер, а он используется стандартный виндовый usbser.sys. В файле stmcdc.inf используемом при установке драйвера виртуального COM-порта прописан GUID класса портов. Так, что эта часть кажется правильной. В системе, в диспетчере устройств STM32 USB CDC присутствует в классе портов. WinAPI’шная функция SetupDiEnumDeviceInfo() возвращает среди прочих портов и STM32. Т.е. Винда знает, что это последовательный порт, но сообщения об этом не приходят.

[DeNi]

Всем доброго времени суток.
Я тоже сталкивался с проблемой, когда терминальная программа (для СОМ-портов), при внезапном отключении устройства теряла порт и при повторном подключении его не находила.

Вот в этом и стоит вопрос, что программе терминалу нужно по большей части только читать из порта, а ReadFile не завершается с ошибкой, если устройство отключить.
Программа просто продолжает читать из порта ноль байт. Не получается отследить момент когда устройство отсоединено.
И если не успеть закрыть порт, до того как устройство вставили повторно, получим Error = 2 при вызове CreateFile.

К ошибке приводит только запись с отличным от нуля количеством байт. Такое поведение характерно только для usbser.sys.

И драйвера CDC тут ни при чём. У меня HID device, соответственно никаких ST-шных дров нет вообще, а симптомы те же. Отключаемый pull-up должен помочь. Правда руки до этого у меня ещё не дошли . На него винда всегда корректно реагирует.

Как раз драйвер CDC очень даже причем. ST драйвера никогда не писала, их драйвер для CDC это только цифровая подпись для stmcdc.inf,
чтоб с их VID PID установить usbser.sys который уже имеется в Windows. Для HID устанавливается функциональный драйвер по классу устройств,
и для его привязки не важен VID PID.