Привет.
Как понять программно что шнурок USB отключен от device и сейчас не нужно передавать данные Host? Используется Cube. Стандартные функции приема передачи данных.

Мало что понятно.
У вас на STM32F4 сделан CDC Host. К нему соединяется сторонний девайс. Вам надо понять подключено к вашему хосту устройство или нет?

Нет сделан CDC device (виртуальный COM порт). Надо понять отключен device от Host (ПК) или нет.

Мониторить VBUS?

Можно смотреть и Vbus.
Что вы думаете о такой конструкции ?

if(hUsbDeviceFS.dev_state==USBD_STATE_CONFIGURED) {
CDC_Transmit_FS(testDataToSend, strlen((char*)testDataToSend) );
}

Ничего не думаю. Чисто по протоколу, по моему, не возможно отследить отключение устройства. То что встроено в STM32 (USB или OTG) основано на мониторинге VBUS.
Ну и, на мой взгляд, это самый надежный вариант.

Ну почему невозможно. Можно например отслеживать наличие SOF-ов. Пропали - значит нет хоста.
Но правильнее всё-таки - VBUS.

Это выгоднее с точки зрения экономии ресурсов. Повесить прерывание...

Какой смысл что-то слать, если на той стороне порт не открыт и данные забирать некому? После прихода в CDC запроса setup request с типа SET_CONTROL_LINE_STATE с параметром 3 порт открыт, можно слать привествие. После прихота этого же запроса с другим значением параметра или после установки конфигурации 0 - порт закрыт. Во всяком случае у меня это красиво работает и под линухом и под виндовсом: пользователь запускает терминалку и получает приветствие. Как это сделать в кубе - разбирайтесь сами, когда я скомпилил пример из куба и получил 25 К кода только от голого виртуального последовательного порта - написал свой стек.

Вот я также думаю, но можно подстраховаться Vbus еще. В Cube есть:
/* Device Status */
#define USBD_STATE_DEFAULT 1
#define USBD_STATE_ADDRESSED 2
#define USBD_STATE_CONFIGURED 3
#define USBD_STATE_SUSPENDED 4

Написал вот так:
if( (hUsbDeviceHS.dev_state==USBD_STATE_CONFIGURED) ){
CDC_Transmit_HS(p ,strlen (text));
}

Устройство будет сконфигурировано хостом, и тут, бац, выдернули шнур. Устройтство осталось сконфигурировано, потому как от хоста не получало пакета SET_CONFIGURATION = 0. Что дальше?
Выдернуть могут на любом состоянии. Но узаете о том, что не подключены только через VBUS. В STM32F4 есть регистры/биты, которые могут сигнализировать об отключении (некогда копаться в даташите чтобы указать точно). Но, естественно сама линия VBUS должна быть заведена в МК.

prottoss все работает я конечно еще протестирую, но сегодня у меня все работало.
Я хочу еще спросить а как правильно программно делать disconnect от usb в режиме cdc?

Да вроде ни каких примудростей нет:
1. Запретить прерывания от USB-модуля в МК.
2. Отключить pull-up резистор от шины.

Сергей, полностью поддерживаю! Почему-то все остальные поняли вопрос буквально...


Параметр 3 - это при наличии DTR со стороны хоста.
И если большинство "обычных" софтин поднимают его, то нежно любимый мной Bray Terminal оставляет его на усмотрение пользователя. И по умолчанию он там выключен...

Подскажите, установка конфигурации 0 - это закрытие виртуального порта, или отсоединение устройства?
Если первое, то флажок "connected" можно ставить по любому SET_CONTROL_LINE_STATE.
Давно собираюсь переделать свою реализацию...

if (hUsbDevice_0 == 0) то шнурок отключен

SET CONFIGURATION = 0, это значит устройство не сконфигурировано - доступ к нему не разрешен операционной системой - читай - ошибка где то.

Вопрос был о том, чтобы программно определить отключение шнурка устройства от порта.

Другого способа я не нашел.
Мысль интересная. Писал давно. При закрытии порта точно вызывается SET_CONTROL_LINE_STATE с параметром 0. А вот set_configuration вроде бы вызывается только при подключении устройства.

Автору вроде нужно не открытие/закрытие COM-порта в винде, а отрывание USB-шнурка. Шнурок могут выдернуть и не закрывая COM.
А также по стандартным запросам от host-а никак не определить факт отрывания шнурка.
Только VBUS или SOF.
SOF кстати - более универсальный способ чем VBUS.

мой вариант прекрасно работает

Не обязательно. Я уже писал. VBUS элементарно может быть не подключен, при этом USB вполне себе нормально будет работать. В этом случае нужно использовать SOF.


Ваш - находится у вас, а у автора может быть другая схема.

у меня тоже через куб, как и у автора. Это штатная переменная в кубе

Куб уже научился и провода подпаивать?

да, конечно, через SOF - это отличная идея. Но требует определенных программных затрат. Нужны таймауты. Если у ТС устройство в разработке, я бы рекомендовал выделить линию порта МК под мониторинг VBUS. Я делаю именно так.

У меня в практике был случай, когда в устройстве (с USB-device) использовалась ADUM4160 и схемотехник VBUS нормально завёл на неё, а вот как МК, находящемуся за барьером, дать знать об отключении хоста - не подумал. И линия VBUS которую он завёл в МК, всегда сидела в "1".
Вот тогда только SOF и спасал.

Никогда не использовал КУБ - пользуюсь самописным софтом. Вот мне интересно, как Вы думаете, или может быть точно знаете - каким образом данная библиотека отслеживает выдергивание шнурка. Как говорил раньше - у STM32 c OTG есть средства - есть регистры и биты, по которым можно отследить состояние VBUS (если линия подключена). У МК с USB-device вообще таких средств мониторинга нет. Как там КУБ определит? Возможно, что как предложил jcxz по SOF, но я сомневаюсь, что в КУБ-е это реализовано.


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

у него все уже подпаяно, если внимательно почитать.

куб определяет при вхождении в прерывание OTG_FS_IRQHandler через флаг USB_OTG_GOTGINT_SEDET

Да. Но VBUS должен быть подключен, иначе Вы постоянно будете висеть в этом прерывании.
И как решить вопрос с МК, у которых нет OTG? Например STM32F103? ...Хотя ТС озвучил F4xx серию, тем не менее, пускай вопрос будет риторический.

там, видимо, как то иначе, не работал с первой серией

В первой серии даже встроенного pull-up нет. Но, тем не менее, повторюсь не в первый раз - для точного и быстрого определения отключения шнурка - VBUS.

USB_OTG_GOTGINT_SEDET как раз и работает с VBUS

Bit 2 SEDET: Session end detected
The core sets this bit to indicate that the level of the voltage on VBUS is no longer valid for a
B-Peripheral session when VBUS < 0.8 V

Совершенно верно. Я об этом и говорил много постов в этом топике.

Vbus я опрашиваю.

Чем эта не нравится:
if( (hUsbDeviceHS.dev_state==USBD_STATE_CONFIGURED) ){

}
?

Столкнулся с еще одной проблемой USB.
Когда подключен шнурок USB и есть напряжение Vbus и выполняется условие hUsbDeviceHS.dev_state==USBD_STATE_CONFIGURED. И при этих условиях передавать данные на пк без открытого терминала COM порта (просто шлем данные). То через некоторое время микроконтроллер зависает. Функция передачи while(CDC_Transmit_HS(p ,strlen (text)) != USBD_OK); выдает USBD_BUSY. Но если в терминале нажать conect то все нормально.

а что посылает терминал при нажатии connec?

данные вываливает (терминал). И программа (зашитая в микроконтроллер), дальше продолжает работать, все нормально. Я так думаю какие-то массивы данных переполняются.
Хочу еще узнать, что за:
/* Device Status */
#define USBD_STATE_DEFAULT 1
#define USBD_STATE_ADDRESSED 2
#define USBD_STATE_CONFIGURED 3 // эта знаю для чего
#define USBD_STATE_SUSPENDED 4
ни где не смог найти для чего они нужны. Может в них разгадка.

#define USBD_STATE_DEFAULT 1 - это исходное состояние USB-device, устанавливается при инициализации и остаётся таковым до подключения к хосту
#define USBD_STATE_ADDRESSED 2 - промежуточное состояние при подключении, хост уже установил адрес, но ещё не передал конфигурацию
#define USBD_STATE_SUSPENDED 4 - по названию понятно, что перевод в некое остановленное состояние, но не знаю в каких случаях хост выполняет перевод подключенного девайса в состояние suspend и выводит из этого состояния (resume), у меня при работе с CDC такое состояние не возникало

Мне кажется, вы не совсем понимаете парадигму работы USB. Устройство не передаёт данные хосту! Оно кладёт данные у себя в "заветную нычку" (конечную точку) и ждёт пока хост их сам заберёт. Если забрал, то можно ещё положить. Если не забирает, то накапливайте данные вне "нычки" или выкидывайте, тут уж вам решать сколько данные "не протухают".


Это когда хост не проявляет никакой активности на шине. Например, устройство отключили в диспетчере устройств. Можно переводить процессор в режим энергосбережения. Если не стоит задача микроамперы ловить, то можно забить. Хост сам даст RESET когда захочет с вами поработать.


Это состояние более низкого уровня. Выход из SUSPEND происходит через RESUME, RESET и Enumeration. Пока "жив CDC" не может быть суспенда.

Вот я нарвался... Как писал выше - определял открытие порта по SET_CONTROL_LINE_STATE. До сих пор устраивало. Теперь потребовалось определять закрытие порта и/или выдергивание кабеля. С закрытием порта никаких проблем - SET_CONTROL_LINE_STATE справляется. А вот с выдергиванием кабеля меня настигла большая ж... неожиданность. Не гененрится прерывание SEDET. Искал-искал, читал-перечитывал описание - ну вроде бы нечему там не работать, напряжение просело - получи прерывание. Ткнулся вольтметром на Vbus - а там 2 вольта...

У меня на входе USB стоит защитная сборка USBLC6. Сборка по рекомендации ее производителя подключена к D+, D- и Vbus. И вот тут начинается смешное: при появлении Vbus набортный OTG FS включает подтяжку на D+ и держит ее включенной постоянно: если он ее отключит, host воспримет это как отключение устройства. При пропадании Vbus (проседании ниже 0.8 В) OTG_FS генерит прерывание SEDET и отключает подтяжку (или в обратной последовательности, не знаю) - все должно быть красиво. Но у меня при выдергивании шнурка эта подтяжка через защитные диоды USBLC6 попадает на Vbus и не дает Vbus просесть до 0.8 В. Выпаиваю USBLC6 - все работает. Впаиваю - на Vbus зависает 2 вольта и прерывания нет. Странно, что об этой ситуации ничего не сказано в документации на USBCL6, ведь она позиционируется как защита и для self-powered device тоже. Да еще и в AN4879 от ST встречается вот такая фраза:
То есть вроде тоже никаких предупреждений. И только на картинках между Vbus и входом контроллера стоит делитель из резисторов 47 кОм и 68 кОм, но нигде в описании ни единого слова о его предназначении. В руководстве пользователя этого делителя тоже нет, контакт разъема подключен напрямую ко входу Vbus, но там и защиты нет, а без защиты все работает. Естетсвенно, у меня в схеме этого делителя не было. В общем не повторяйте моих ошибок.

Весь день убил. Теперь ночью придется делать то, что должен был делать днем.

Аналогичная ситуация.
У меня на делитель заводится питание с USB разъема.
Делитель подключен к контроллеру для определения подключили/отключили разъем.
То же долго не мог понять почему при отключении разъема на делителе "висит" 2V.
В результате было сделано так:
USB VCC -> делитель -> диод -> и только потом питание от USB идет на питание USB сборки и питание схемы.
В этом случае при выдергивании шнурка процессор "не продавливает" через сборку делитель.

Я тоже сначала думал про диод, но потом нашел AN4879 и понял, что делителя будет достаточно. У меня включена нижняя подтяжка на Vbus, поэтому оазалось достаточно резистора 10 кОм последовательно в цепи Vbus между USBCL6 и процессором.

Себе для заметки на будущее.
Не совсем понял в каком месте.
Можете пояснить?

Я использую NUF2042XV6T1G, с ней таких проблем нет.

Нажмите для просмотра прикрепленного файла
И внутри включаем подтяжку вниз. Она по документации 40 кОм, но у меня измерения на трех платах показывают 2.8 В на входе Vbus после резистора 10 кОм, т.е. реально сопротивление внутренней подтяжки около 15 кОм. Ну или ставить там полноценный делитель 47 кОм и 68 кОм, как нарисовано в AN4879 и внутреннюю подтяжку не включать.