Судя по тому, что IOCTL к хабу из юзермоде вызывается, я предложил бы вам попробовать отключить-включить соответствующий "корневой USB концентратор". Тот в который воткнут ваш девайс. Его можно найти по тому, что после втыкания вашего девайса, во вкладке питание появляется XX ма (возможно и название Serial.. - непомню), соответствующее вашему девайсу. Кстати очень интересно, а после сбоя там эта цифра продолжает оставаться?

Ну всё указывает на мою версию, но девайс не пропадает из списка...

Чтоб возникла сингфазная помеха достаточно не всю вилку, а только ОДИН её контакт в розетку втыкать.

На самом деле можно любой - USB Serial Convertor является родительским устройством для устройства последовательного порта, а требование перезагрузиться - привет от разработчиков драйверов FTDI.




По вашей версии должен произойти detach - но устройство в списке - значит произошел attach + последующая реэнумерация устройства + работает SOF. Но SOF нет, вывод - версия не верна.

Скорее всего произошла следующая ситуация: из-за ошибки на линии хаб сделал disable порта, к которому подключено устройство - статус порта можно прочитать из драйвера и сделать определенные действия по выходу из такой ситуации -действия не произведены.

Продолжает оставаться. 100 мА у меня. Я даже "Обновить" нажимал...

Далее.
1. При неработающем приложении (порт не открыт) отключаю и задействую обратно "Корневой USB-концентратор" и мой конвертор после этого не работает! Приходится дёргать за шнурок...

2. При работающем приложении (порт открыт и идёт обмен) после отключения и задействования ... винда предлагает перезагрузиться. Соответственно отключение и задействование ... без перезагрузки никакого влияния на устройство не оказывают.

Это к вопросу о том, чтобы попробовать после сбоя отключить и задействовать...



По вашей версии должен произойти detach - но устройство в списке - значит произошел attach + последующая реэнумерация устройства + работает SOF. Но SOF нет, вывод - версия не верна.



С помощью D2XX можно это всё сделать?
Я не понимаю почему приложение наглухо виснет до передёргивания шнурка?

По моей версии из-за синхфазной помехи происходит detach и всё. Никакого attach после этого не было. В своё время я с этим разбирался - вешал сниффер на хаб и смотрел какие сообщения он шлёт. Так вот: в аналогичном по симптомам случае, хаб говорил что устройство извлечено из него И ВСЁ. По моей версии сингфазная помеха приводит к тому, что при ОТСУТСТВИИ обмена на шине обе линии и D+ и D- на короткое время =0 становятся (т.е. никаких ошибок нет). Вроде 16-ти полноскоростных бит достаточно. И хаб об отключении девайса сообщает, а вот о последующем подключении почему-то не сообщает. И всё - девайс потерянным оказывается.
Только сейчас подумал - а м.б. у топикстаркера HIGH спид девайс?!? Там вроде подругому. Я с HIGH спид не разбирался - пока не надо было. М.б. из-за этого из списка он не пропадает?

Мне это кажется крайне маловероятным. Этож какая помеха д.б. чтобы 3 попытки перепосылки собой закрыть!

Кстати всё это легко проверить. Если просто девайс подключить и никакого обмена с ним не вести, а вот выключателем-то пощёлкать. И в таких условиях отключение с переходом в слип проверить. Если обмена с девайсом никакого не будет, а девайс всё равно отключится, то версия об ошибках сама-собой отпадёт.

Ну точно FTDI накосячил.


Попробуйте. Они документируют функции FT_CyclePort, FT_ResetPort, FT_ResetDevice.
Про FT_CyclePort так и пишут:
"The effect of this function is the same as disconnecting then reconnecting the device from USB. Possible use of this function is situations where a fatal error has occurred and it is difficult, or not possible, to recover without unplugging and replugging the USB cable. ... "

PS to n_bogoyavlensky. Отредактируйте своё сообщение - в качестве цитаты привели не моё высказывание.

У вас все устройство питается от УСБ? Сколько хавает? Мож попробовать внешний источник?

При чем тут 3 перепосылки, я говорю об ошибках Babble and Loss of Activity

снял сниффером логи при сбое и при выдергивании.
Сравните
[attachment=29818:ft232bm_...se_fault.html] - ft232bm сбой от помехи (6294) во время обмена, устройство в девайс менеджере присутствует и числится исправным даже после обновления
[attachment=29819:ft232bm_..._Removal.html] - вытаскивание шнурка во время обмена

Т.е. о появление ложного SOP как следствие помехи.
Но это д.б. помеха которая заставит ОБА ПРОВОДА В ВИТОЙ ПАРЕ поменять своё состояние на ПРОТИВОПОЛОЖНОЕ И РАЗНОЕ. D+ должен изменить состояние с 1 на 0 и ОДНОВРЕМЕННО D- с 0 на 1. Что это за помеха такая???
Гораздо более вероятно, что под влиянием помехи ОБА провода в одинаковое состояние перейдут. Было D+ =1, D- =0, а станет D+ =0 и D- =0. И всё это продлится 2.5 микросекунды (вполне нормальная помеха) т.е. 30 бит на фул спид, а не 16 как я писал. Иначе это вроде ложный EOP будет, а там ничего страшного не произойдёт.
Но конечно всё это пока только рассуждения. Нужно реальные данные посмотреть. Что там хаб в на GET_STATUS вернул? Чему равно слово wPortStatus после ошибки?
Когда я с этим разбирался (с помощью снифера), там вроде PORT_CONNECTION=0 был, но за давностью лет могу и напутать. А м.б. у меня тогда другой случай был.
Хорошо бы если бы топикстартер у себя сниффером посмотрел.

Что-то я не понял ничего. Ваш снифер видимо данные не показывает. Мне лично SnoopyPro нравится. Он халявный и хороший - рекомендую скачать и пользоваться. Единственный недостаток - логи отправлять нельзя/у меня что-то не получается. Но самому смотреть самое то.
1. На хаб в который девайс будете вставлять его натравите.
2. Хаб в диспетчере устройст выключите/включите.
3. Пакеты к хабу он начнёт показывать (штук 30), но вы их пока не смотрите (что-то у меня чтобы посмотреть останавливать приходится).
4. Вставте ваш девайс в порт. При этом ещё штук 30 пакетов пройдёт.
5. Вытащите (ещё 30) и теперь пакеты смотрите.
Другой вариант - сбоя дождитесь.
Интересовать вас должен собственно:
SetupPacket
a3 00 00 00 0x 00 04 00 (где x N порта) - это GET_STATUS к хабу. Хаб в ответ должен 4 байта вернуть (0400 - длина). Биты в этих байтах - состояние (и изменение состояния) данного порта. Об этом в главе 11 написано. Вот значение именно этих битов нас и интересуют.
А у вас какое-то огромное число пакетов в логе. Там видимо и к девайсу пакеты в куче. Тут что-то в районе 100 пакетов быть должно всего. И это с учётом включения самого хаба.

Кроме как в конце фрейма, перед стартом следующего, что приводит к disable порт.

Где вы это прочитали? Ссылку если можно (глава и пункт). Я что-то ничего такого про EOP не знаю. Да это и совершенно не логично. Это, наоборот, ложный SOP действует так как вы описали.

USB 2.0
11.2.5 EOF1 and EOF2 Timing Points
...At the EOF2 point, any port that has upstream connectivity will be disabled as a babbler....

snoopypro у меня винду ронят в бсод если я мониторю корневой хаб.
usblyzer все показывает, только приходится мышой по пимпочкам жмакать, я выловил то что вы хотели увидеть

В ответ на Get Port Status к хабу (a3 00 00 00 номер_порта 04 00)
возвращаются данные 01 01 02 00
В сответствии с таблицами 11-20 и 11-21 получается:

wPortStatus :
* A device is present on this port
* This port is not in the Powered-off state

wPortChange :
* Over-Current Status has changed

сразу после этого посылается Clear Port Feature - C_PORT_ENABLE (23 01 00 11 00 01 00 04)
затем вечно и безуспешно долбит Sync Reset Pipe and Clear Stall

Но там-же написано, что хаб как-раз EOP не дождался, а конец кадра уже наступает... Т.е. именно SOP ложный был.
Смысл (как я понял) там такой: если хаб всё ещё в состоянии WFEOP (т.е. получил SOP и EOP ожидает) в момент EOF2 (завершения одномиллисекундного кадра - скоро уже следующий SOF прийдёт) - вот тогда хаб disable порт и делает.

А вы как поняли? Только жел-но по русски.


Что-то у меня совсем другие данные получаются. 01 01 - это значит wPortStatus=b0000000100000001. Т.е. начиная с младшего бита:
b0=1 - устройство присутствует на этом порте
b1=0 - порт заблокирован!
b2=0 - не в суспенде
b3=0 - сверхтока нет
b4=0 - сигнала сброса (Port_Reset) нет
b8=1 - на этот порт питание подано
b9=0 - full спид девайс подсоединён к этому порту
Аналогично для wPortChange=b0000000000000010
b0=0 - нет изменения в состоянии соединения
b1=1 - произошло изменение в заблокировании/разблокировании порта
b2 и т.д. =0 - не произошло больше никаких изменений.

Тут вы видимо что-то напутали. Что за килобайт данных (00 04 в конце)?

Если больше ничего не попутано, то вроде выходит, что действительно это не то случай, который у меня был. У меня в wPortStatus b0=0. В этом случае похоже "Седой" прав. Действительно babble произошёл (лишний SOP). Теперь нужно подумать как с этим бороться...