Здравствуйте.
Делаю переходник USB-UART CDC. После энумерации он тут же уходит в suspend. Если на ПК ещё нет драйвера, то уйдёт в suspend сразу после его установки. А до этого будет ждать, и высылать дополнительные дескрипторы по запросам ПК.
Если же подключать устройство при уже установленном драйвере, то уходит в suspend немедленно после энумерации.
При этом пишет в диспетчере устройств что есть Virtual COM Port, но запуск невозможен [код 10].

Вопрос такой. Этот самый suspend - это в моей программе какая-то ошибка энумерации, или для CDC устройств так и должно быть?

Как вывести устройство из suspend я тоже не понимаю (если это вообще обратимое состояние, конечно). В программе, при появлении события suspend всё перевожу в состояние микропотребления (но модуль USB остаётся включен), "усыпляю" процессор, разрешаю прерывания, и жду события resume, которого всё нет.
Я правда точно не знаю, сколько при этом потребляет устройство от шины USB - но в других приложениях, при тех-же действиях, устройство "кушало" примерно 50-70uA. Т.е. требованию, о потреблении менее 0.5мА вроде как должно соответствовать...

Агурова читал, программные семплы разных производителей для CDC смотрел (для STM32, AVR, MSP430), но так и не понял главного - suspend это норма, или какая-то исключительная ситуация???

Контроллер может перевести в саспенд устройство когда захочет. Что бы понять нормальность нужно читать стандарт, благо он выложен в открытом виде и если смотреть только то что нужно, то там с сотню страниц. Не припомню правда что бы винда любила загонять в саспенд лишний раз, обычно она ресеты любит. Есть remote wakeup которые позволит выходить из саспенда по желанию устройства и соответсвенно передаватбь принятое.

Всё вышесказанное в случае отсутствия ошибок. Но раз саспенд есть, то предположу что и ошибки есть. Рекомендую полностью логировать обмен по ЮСБ, прочитать стандарт и вдумчиво посмотреть на обмен. Возможно любой снифер USB натолкнет на правильные мысли быстрее.

Спасибо. Внутренний лог обмена я снимаю - и вроде бы всё нормально (есть опыт с классом устройств MSD). Правда нормально до тех пор, пока suspend не возникает
Начал делать простенький сниффер под Saleae Logic - в последней версии появилось декодирование USB Low Speed и Full Speed. Попробую снять лог инициализации PL2303, или COM-переходника на AVR-контроллере (он вроде в Low Speed работает).

Вообще если возникает саспенд, а винда пишет что запуск невозможен, значит что-то в обмене незадолго до суспенда ей не понравилось. Присмотритесь к этим последним транзакциям, наверняка там где-то ошибка.

А вы не "усыпляйте" процессор и не переводите всё в микропотребление - сделайте только вид, возможно не пропустите resume.
Вроде варианты как вас можно усыпить - вы сообщаете сами при энумерации - возможно надо их покрутить.

Оно не CDC.
Скорее всего отвечаете NAK на какой-то специфический для CDC запрос.
Сгенерите "кубом" пустой проект поддержки CDC для любой STM платы - уж он часами стоит и не отваливается. И снимайте лог с его инициализации.

Сообщение отредактировал Genadi Zawidowski - Oct 25 2016, 20:21

Сниффер сделал, ошибку нашёл. Спасибо всем за участие и идеи
Движок энумерации делался для MSD, а поскольку MSD не использует всех возможностей шины, то для экономии места в нём были сделаны некоторые упрощения, за ненадобностью. Когда я подставил в движок дескрипторы CDC, то он в тех местах где "упрощено" - стал слать пустые пакеты, типа просто подтверждать приём. За что от Хоста получил Suspend
В общем буду переписывать движок, чтоб был совсем уж универсальный.

Что нового узнал при снятии логов.
1. Suspend в процессе энумерации и работы сам по себе не возникает. Т.е. всё-таки, это ситуация неправильная. Проверил на PL2303, CP2102, FT232R и AVR-CDC (на ATMega48). Даже к бездействующему устройству непрерывно шлются Sync-пакеты. Только и разницы, что для Low Speed это каждые 8ms, а для Full Speed каждую 1ms.

2. Программа Saleae Logic научилась расшифровывать USB Low Speed и Full Speed, что радует

3. PL2303, CP2102 и FT232R, хоть и USB-COM переходники, но дескрипторы у них не стандартные для CDC (нет функциональных дескрипторов, о которых пишет Агуров, и которые в спецификации CDC), и потому без специально написанного под них драйвера работать напрямую с Windows они не могут.
Зато на Android-смартфоне, все вышеназванные переходники (включая AVR-CDC на Mega48) работают без дополнительных драйверов. Такой вот парадокс

Может быть будет интересно...
Добавлял второй CDC в устройство (к уже имеющимся CDC и AUDIO).
Поскольку от него не требовалось передача данных, а только LINE CONTROL функции, решил в качестве адреса INTERRUPT и DATA ENDPOINTS прописать 0x8E/0x0E. Всё работало пока не подсоединил устройство через USB HUB.
Возможно, было виновато было то, что адрес был одинаковый.

Сообщение отредактировал Genadi Zawidowski - Oct 28 2016, 08:12