STM32f4 виртуальный COM порт подключение/отключение USB Опции

[Alex_Golubev]

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

[uriy]

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

[Alex_Golubev]

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

Сообщение отредактировал Alex_Golubev - Dec 9 2017, 14:24

[prottoss]

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

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

[Alex_Golubev]

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

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

[prottoss]

Что вы думаете о такой конструкции ?

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

[jcxz]

Ничего не думаю. Чисто по протоколу, по моему, не возможно отследить отключение устройства.

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

[prottoss]

Но правильнее всё-таки - VBUS.

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

[Сергей Борщ]

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

[Alex_Golubev]

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

Вот я также думаю, но можно подстраховаться 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));
}

Сообщение отредактировал Alex_Golubev - Dec 10 2017, 06:24

[prottoss]

Вот я также думаю, но можно подстраховаться 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 должна быть заведена в МК.

[Alex_Golubev]

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

[prottoss]

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

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

[esaulenka]

Какой смысл что-то слать, если на той стороне порт не открыт и данные забирать некому?

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

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

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

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

[0men]

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

[prottoss]

Подскажите, установка конфигурации 0 - это закрытие виртуального порта, или отсоединение устройства?

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

Какой смысл что-то слать...

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

[Сергей Борщ]

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

Другого способа я не нашел.

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

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

[jcxz]

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

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

[0men]

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

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

[jcxz]

Но узаете о том, что не подключены только через VBUS.

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

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

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

[0men]

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

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

Сообщение отредактировал 0men - Dec 11 2017, 13:44

[jcxz]

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

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

[prottoss]

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

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

[jcxz]

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

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

[prottoss]

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

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

Вот тогда только SOF и спасал.

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

[0men]

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

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

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

Сообщение отредактировал 0men - Dec 11 2017, 14:48

[prottoss]

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

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

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

[0men]

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

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

[prottoss]

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

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

[0men]

В первой серии даже встроенного 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

[prottoss]

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

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

[Alex_Golubev]

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

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

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

}
?

[Alex_Golubev]

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

[golf2109]

Но если в терминале нажать conect то все нормально.

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

[Alex_Golubev]

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

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

[SanvaldYV]

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

[VladislavS]

Я так думаю какие-то массивы данных переполняются.

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

Хочу еще узнать, что за:
/* Device Status */
#define USBD_STATE_SUSPENDED 4

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

#define USBD_STATE_SUSPENDED 4 - по названию понятно, что перевод в некое остановленное состояние, но не знаю в каких случаях хост выполняет перевод подключенного девайса в состояние suspend и выводит из этого состояния (resume), у меня при работе с CDC такое состояние не возникало

Это состояние более низкого уровня. Выход из 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 встречается вот такая фраза:

The component needs to be placed as close as possible to the receptacle to add ESD protection against high ESD surge. The USBLC6 component is recommended for such protection on VBUS and USB data lines. For OTG (on-the-go) use cases, the ID pin should also be protected against high ESD surge.

То есть вроде тоже никаких предупреждений. И только на картинках между Vbus и входом контроллера стоит делитель из резисторов 47 кОм и 68 кОм, но нигде в описании ни единого слова о его предназначении. В руководстве пользователя этого делителя тоже нет, контакт разъема подключен напрямую ко входу Vbus, но там и защиты нет, а без защиты все работает. Естетсвенно, у меня в схеме этого делителя не было. В общем не повторяйте моих ошибок.

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

[Zeal0t]

... сборка USBLC6 ...
... делитель из резисторов 47 кОм и 68 кОм, но нигде в описании ни единого слова о его предназначении...

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

[Сергей Борщ]

USB VCC -> делитель -> диод ->

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

[Zeal0t]

... резистора 10 кОм последовательно в цепи Vbus между USBCL6 и процессором.

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

[Vasily_]

У меня на входе USB стоит защитная сборка USBLC6. Выпаиваю USBLC6 - все работает. Впаиваю - на Vbus зависает 2 вольта

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

[Сергей Борщ]

Не совсем понял в каком месте.
Можете пояснить?

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