Дано: есть ПЛИС на базе МК stm32105. К ней прикручен usb, программно поднят cdc по примерам от st и допилены операции приёма/передачи. В неопределённый момент usb кабель выдергивается(возможно даже в момент передачи/приёма, но это не суть). Через некоторое время подключается обратно.
Найти:
1)как программно отлавливать отключение usb кабеля? что при этом не плохо бы сделать?
2)как собственно программно отлавливать обратно подключенный кабель?

Вообще ни у кого ни одной идеи нет? Никто не сталкивался с такой проблемой?

VBUS вообщето пропадает.

если куда нужно подключен
а то просто на питание вешают

В ст шной библиотеке есть ивенты и на дисконнект и на ресет и так далее

для филпсов не видел...
error, sof, reset, power, suspend, resume... disconnect не видел
корки разные, но события-то должны быть? покажите

Хорошо, я глянул в дебаге как что происходит при отключении/включении кабеля
1 подключение кабеля: после прерывания почему то сваливается в Handle Suspend Interrupt, затем Handle Reset Interrupt->Handle Enumeration done Interrupt->Handle Reset Interrupt->Handle Enumeration done Interrupt. Всё хорошо, устройство определилось
1 отключение кабеля: кидает USBSUSP в регистре OTG_FS_GINTSTS и собственно обрабатывается Handle Suspend Interrupt.
2 подключение: Handle Suspend Interrupt->Handle Reset Interrupt->Handle Enumeration done. Но устройство не определяется как положено, а висит как Unknown Device.
Все последующие подключения/отключения никаких прерываний не кидают.
И тут самое интересное, что в обработчике прерываний есть Handle Connection event Interrupt и Handle Disconnection event Interrupt, но в эти обработчики программа не попадает за всё то время, в которое я делал эти манипуляции.
Если вы знаете, что есть эти ивенты, то возможно вы знаете как ими пользоваться? Знаете почему при отключении сваливается в Handle Suspend Interrupt. Расскажите пожалуйста или скажите как поправить, что бы всё работало.

Я полазил по коду. В обработчик Connection/Disconnection event Interrupt программа в действительности и не может пройти, ибо замаскированы SRQINT и OTGINT. Хотя собственно эти обработчики, кроме как сброс бита прерывания, ничего не делают.
Почему входит в Suspend mode тоже понятно:

Но всё равно не понятно чего не хватает устройству для работы... Почему то при повторном подключении кабеля обрабатывается один раз Handle Reset Interrupt->Handle Enumeration done, а не два раза как при первом соединении. Хотя почему кидает USBSUSP при первом подключении кабеля, так и не стало ясно. Так же почему то перестало кидать прерывание USBSUSP при отключении кабеля, чудеса... И еще не понятно, почему не формируются прерывания при подключении/отключении кабеля после второго подключения кабеля. Вопросов много, ответов нет...

А устройство после отключения кабеля остается с включенным Pullup к D+? Возможно, там собака порылась

Возможно, завтра попробую на работе. Но в usb nutshell написано обратное. Или я не правильно понял?

Пробовал софтварно отключать подтяжку, после отключения кабеля кидает HardFault_Handler в startup_stm32f105xc.s

во. значит по событию ПО пытается вызвать неопределённый обработчик.

Я на самом деле просто делал видимо не правильно. Я подтяжку вырубал с помощью регистра GCCFG и сбрасывал бит VBUSBSEN. После чего вылетало Hard Fault.
Я почитал, правильно было сбрасывать потяжку софтаврным дисконектом в регистре DCTL выставлял единицу в бит SDIS. Ничего не поменялось кароч.

Хочу поднять старую тему, ибо я решил проблему. Может быть это кому и поможет.
Не знаю как у других, но у меня вылетал Hard Fault, после функции free(), собственно сразу же после повторного присоединения кабеля.
Так что её тупо надо закомментить, потому как она смысловой нагрузки не несёт(только отрицательную нагрузку).
Вызов этой функции лежит в usbd_cdc.c в функции USBD_CDC_DeInit:

Примерно так должно быть.
Причина глюка проста: по задумке разработчиков HAL драйверов, указатель pdev->pClassData должен освобождаться из динамической памяти функцией free, хотя никакими функциями типа calloc, malloc память не выделялась. Да и вообще в данных драйверах никакого управления памятью нет. Так что будет достаточно строчки pdev->pClassData = NULL, чтобы всё работало!

Нет, так лучше не чинить. Если потом все же по каким-то причинам захочется динамического выделения, то пользователь пойдет править USBD_malloc и USBD_free, не подозревая, что вызов USBD_free закоменнтирован. И получит утечку памяти. Так что лучше закомментировать вызов free(). Ну а то, что останется вызов лишней пустой функции - так такого Г в этом коде навалом, никто и не заметит несколько лишних байтов.