Если нет, тогда вы правы.
Ну тогда отловить программно такую ситуацию довольно просто - обработкой сообщения WM_DEVICE.



А вот у него и спросим.


Тогда эта возможность не была документирована.

Пока проверил только IOCTL_USB_HUB_CYCLE_PORT - detach и последующий attach устройства - прекрасно работает из UserMode c драйвером хаба.

Остальное проверю позже, как будет время.

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

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

Работает. Странно. А у меня что-то в своё время не получилось. А точно срабатывает?
Что с портом после detach происходит? SOF-то пропадает? Девайс в суспенд переходит?

Совсем интересно. Видимо это какой-то другой случай... И ошибок никаких в диспетчере не показывается? А SOF продолжает идти? Его осциллографом отлично видно, да и тестер покажет частоту 1 кГц. Только тыкаясь щупами можно случайно девайс разбудить. Тогда эксперимент некорректным будет. Ещё рекомендую на ножку, которая суспенд показывает, светодиод повесить.

Работает также как и IOCTL_INTERNAL_USB_CYCLE_PORT, вызванный из драйвера.
Как написано в комментарии usbioctl.h:
"
This IOCTL will simulate a plug/unplug on the drivers upstream
port. The device will be removed and re-added by PnP.
"
В драйвер менеджере вижу удаление и появление драйвера.
В устройстве вижу полный цикл энумерации.
Проверил на MT-Link, USB-COM (один свой на CP2103, второй покупной на Prolific),
своих двух платах(одна на С8051F326, вторая PDIUSBD + AVR),
на Olimex LPC-P2148 и MLPC2368 от StarterKit.

Следует обратить внимание, что документирован этот запрос неверно, делать нужно как написано
в usbioctl.h, а именно:
1. Вызывать для драйвера хаба, а не хоста.
2. Передавать в качестве входного параметра указатель на DWORD c номером порта, начинающегося с 1.

Очень интересно!
А что если попробовать всё это дело после пропадания устройств, вызванных входом самого компьютера в слип? Для этого нужно чтобы во время засыпания компьютера на USB девайсы продолжало поступать +5 вольт, но SOF пропадал. Т.е. девайсы в суспенд попадали бы. Тогда после пробуждения компьютера USB девайсы пропадут (они останутся в суспенде). Можно-ли с помощью detach/attach к хабу заставить компьютер их найти?

Я уже тут писал, что проблема в драйверах этих устройств или настройках драйверов или в самих устройствах, ведь переход в suspend не изменяет device state и после resume реэнумерация не нужна.

Попробуем.




Ошибок не показывается.
Попробуем в понедельник!

Так, а что конкретно отключить, а потом задействовать?
Последовательный порт или USB Serial Convertor?
После выбора из списка "Отключить" и того и другого винда предлагает перезагрузиться...
Может, я не там отключаю?



SOFа нету, пропадает он после сбоя, хорошо это вижу
USBDP - "1",
USBDN - "0",
PWREN# - "1".

Т. е., конвертор спит, и хост ему ничего не шлёт...

Докладываю о следующих экспериментах!

Ниже перечисленные эксперименты производил без прожектора и его кабеля. К сожалению, прожектор забрали не неопределённое время. А сбои оставили

1. Запитал вторую половину конвертора (смотри структурную схему выше) от внешнего источника питания (трансформатор + линейный стабилизатор). В месте подключения провода от источника к плате установил электролит 100.0 и керамику 0.1.
Сбоить не перестало. Тыркаем вилку источника питания - иногда сбоит. Т. е., для возникновения сбоя совсем не обязательно наличие огромного пускового тока 30 А AC-DC моего прожектора...

2. Попробовал включать источник питания через автоматический выключатель - ситуация не изменилась.

3. В настройках микросхемы (EEPROM) установил вместо "USB 2.0" "USB 1.1". Скорость обмена упала раз в пять, сбои не прекратились.

Судя по тому, что 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

снял сниффером логи при сбое и при выдергивании.
Сравните
Нажмите для просмотра прикрепленного файла - ft232bm сбой от помехи (6294) во время обмена, устройство в девайс менеджере присутствует и числится исправным даже после обновления
Нажмите для просмотра прикрепленного файла - вытаскивание шнурка во время обмена

Т.е. о появление ложного 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). Теперь нужно подумать как с этим бороться...

Народ, вы что то грузитесь. По-моему проблемму не там ищите. У меня 5 устройств лежит на FT есть с высоковольткой и ШИМом, все работают без нареканий. Автор темы даже пропал, наверное все почнил. Я все же думаю все из-за питания через усб.

Вы не правы.
Само собой виновата разводка и качество исполнения платы. Но уметь на программном уровне данную проблемум обойти тоже хорошо бы знать.
Мне лично интересно чем закончится данная ветка по теме.

Можно конечно и обойти программно, но "болезнь нужно лечить, а не убивать симптомы..."

AndreyS +1
Скорее всего это именно разводка проводников от разъема USB до микросхемы, сам наступал на эти грабли

Вы неправы, впрочем как и многие дугие заявляющие "поменяй шнурок на менее китайский и не парься" или "у меня ничего не виснет, поэтому проблемы не существует".
Бороться защитами и разводкой с помехой дело безнадежное. Всегда найдется помеха, которая пролезет через самую навороченную защиту и завесит вашу систему в самое неподходящее время.
Интерфейс для индустриальных применений должен обеспечивать:
* защиту от помех (фильтрация, развязка, разводка)
* автоматическое восстановление работы после воздействия мощной помехи (или софтверного сбоя) при условии что оборудование не вышло из строя. Вот с этим у usb боо-льшие проблемы!

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

+1 (и это только класс B будет!)
Мне приходится по 2 девайса (самодельные переходники USB-CAN) на одну линию CANа в разные её концы вешать чтобы:
1. Если ОДНО зависнет - всё работать продолжало.
2. Если линию (USB или CAN безразлично) в ОДНОМ месте рубануть - всё работать продолжало.

Насчёт SnoopyPro. У меня он хабы без проблем смотрит. Он что-то там в реестре оставляет если некорректно выйти. Питание вырубить или вроде даже просто uninstal и uninstal service перед выходом не сделать. Сам сталкивался с тем, что комп виснуть начинал после этого. Очень интересная ситуация происходила - втыкаешь девайс с определёнными VID PID - полный вис. В свай девайс такие VID PID прописал - тоже виснет.

А меня тут 2 крамольные мысли посетили:
1. Про FTDI (Надеюсь любителей этого девайса здесь нет).
А м.б. это такое исключительное гуано, что под воздействием помехи у него ВНУТРЕ что-то сбивается и SOP оно шлёт? С другими девайсами (процессоры с USB функциями и просто внешние USB интерфейсы) такой картины ведь не наблюдается.
2. Про ложные EOP.
А м.б. стоит самому ложные EOP формировать? В конце кадра когда все посылки завершены. Ничему ведь тут вроде не повредишь? А если в пределах кадра ложный SOP случился, то ложный EOP его скомпенсирует и всё работать продолжит. В смысле никакого babble и LOA не случится! Минус на минус дают плюс! Сейчас у меня девайса, на котором такое попробовать можно под руками нет, но как будет - попробую.

Добрый день.

Я с вами полностью согласен.

Хотелось бы теперь вернуть всех к теме разговора

Как вы можете прокомментировать ответ galjoen?

Для galjoen: И какие мысли появились у самого galjoen?
Долго я письмо писал. Уже ответили.



Неа. Это относится как минимум еще к CY7C68013.
У меня подобное наблюдается когда рядом (за стенкой) кто-то начинает баловаться пуском двигателей (короче когда начинают работать станки и силовые установки). Причем это происходит судя по всему не по питанию (фазы физически разные).
Устройство лежит в железном, заземленном ящике. Вот только USB хвост торчит. Пробовали мы различные способы заземления экрана USB, но пока в данном случае наилучший результат дала короткая связь от разъема USB к заземляющему концу (без резистора и конденсатора) самого прибора. Защитные диоды по сигнальным проводам не спасают от этого. Применяли мы и специальные USB 2.0 шнуры с ферритовыми кольцами.
Такое (зависание USB устройства, засыпание его) происходит редко, но метко (пользователям надоедает именно процесс выдергивания шнурка).
Устройство имеет собственное питание и для отвиса приложения достаточно выдернуть воткнуть шнур. Попытка остановить устройство и пустить его снова приводит к сообщению винды о презапуске (короче на лету не отсоединяет драйвер при таком состоянии устройства). Но такое происходит исключительно на скорости High-Speed при отключении хаба с USB2.0 и соответствующем перевешивании устройства системой на Full-speed такой зависимости не наблюдается. А у народа ведь есть USB флешки Вот они USB2.0 обратно и включают.

Наблюдается.
У меня с разной степенью вероятности виснут все устройства, нужно только внимательно за ними наблюдать. Устройства с внешними подключениями в целом виснут чаще чем usb свистки, устройства обмен с которыми осуществяется изредка виснут намного реже устройств которые обмениваются информацией непрерывно. Low speed устройства виснут очень редко. Симптомы зависания во многом схожи с тем что обсуждается в этой ветке.
Впрочем если предположить что помеха воздействует на хаб так и должно быть.

В догонку. Не успел по времени дописать.

Причем (как нам показалось, а может это так и есть) такое наблюдается практически всегда на машинах с Intel ICH5 (чипсет 865) и чипсетом 945 (какой там мост я уже не помню) и никогда на машинах с Intel ICH4 и VIA (именно по этому мы это засекли только на клиентских машинах, у нас то VIA. Мы их по всякому били, но стабильно все работало).

Да отошёл я как-то в сторону от таких USB проблем. Как стал свой девайсы лепить, которые в такой ситуации сами о себе заботятся, так и интерес ко всему этому потерял т.к. думал, что хабом управлять невозможно. А зря. Если, как пишет "Седой", из юзермоды можно хабу SetupPacket отправлять, то вроде всё это просто решается.
По моему мнению нужно хабу такой SetupPacket отправить:
a3 01 04 0n 00 00 00 00 (n - N порта)
Т.е. SET_FEATURE + PORT_RESET к тому порту того хаба, в который наш девайс подключен.

Кстати что там у вас с "Clear Port Feature - C_PORT_ENABLE (23 01 00 11 00 01 00 04)". Там ведь точно что-то напутано.



Из моего опыта - имеются два типа хостов. Один который соглашениям о HID удовлетворяет, а другой нет. Основное различие в том, что если при работе HID через контрольный канал NAK хосту вернуть, то одни (соответствующие) следующую транзакцию только в следующем кадре начнут (через милисекунду), а другие (несоответствующие) сразу-же. Вначале были только соответствующие хосты, и когда появились несоответствующие у меня с ними все работать перестало (ну очень плохо работало). В основном несоответствующие с AMD процессором шли. Мне даже пришлось один такой купить чтобы разобраться в чём дело. Он PCI, у него NEC на чипе написано. И VIA вроде к несоответствующим тоже относились (за давностью забыл). М.б. эти китайцы не только на один (HID) стандарт наплевали, но и на другой? Или наоборот?

Озвучу свое видение проблемы по итогам обсуждения и собственного опыта:

1. Одной из причин "непонятного поведения" программ, работающих с USB устройствами (не только на основе FTDI) является перевод порта хаба, к которому подключено устройство в disable state, при этом устройство остается подключенным.
2. Алгоритм работы стека используемых USB драйверов не производит выхода из такой ситуации, что приводит к "зависанию" программы.
3. Возможно алгоритм так и должен работать, так как предполагает, что такая ситуация является ненормальной и следует избавляться от причин, ee вызвавших.
4. Вероятность появления ненормальной ситуации не равна 0.

Как можно видоизменить работу алгоритма:

Драйвер устройства:
1. Драйвер устройства должен читать статус порта (IOCTL_INTERNAL_USB_GET_PORT_STATUS)
2. При появлении ситуации disable port направить запрос IOCTL_INTERNAL_USB_ENABLE_PORT
3. Если IOCTL_INTERNAL_USB_ENABLE_PORT вернет ошибку, то произвести
IOCTL_INTERNAL_USB_RESET_PORT.

Firmware устройства:
Должно уметь различать USB_RESET, полученные в состояниях Configured и Powered, и правильно их обрабатывать.

PS. Судя по документации WDK и тексту заголовочных файлов действия, производимые драйвером, можно сделать и из UserMode, обращаясь к драйверу хаба и/или хоста. Но это нужно проверять.
PS2. Да, кстати, забыл дать ссылку на предлагаемый алгоритм
http://download.microsoft.com/download/5/b...SBdrv-tips2.ppt
обратите внимание на Recommended URB error recovery steps

Попробуем.



Извиняюсь. Только я не пойму, как его отредактировать?



Проверим.



Схему привёл.
Левая часть устройства питается от USB.
Потребление не должно быть большим... проверим.



Я не знаю что такое "сниффер" и с интерфейсом USB пока знаком очень поверхностно



Автор не пропал, он здесь
Попробуем запитаем не от USB ещё и левую часть...



Хм... я не думаю, что сделал плату плохо...
Вот, вид сверху (фотография) и картинка из OrCAD'а - верх и низ платы.

Жду замечаний по качеству разводки

Да. Вот ещё что.
Экран USB-кабеля соединён с общей цепью устройства (левая часть на приведённой мною схеме).
На нижней стороне ПП распаяны на общую цепь конденсаторы 47 пФ (в сантиметре от разъёма) и электролит по питанию +5 В (100.0).



Вот здесь вот поподробнее, пожалуйста

Даю верхний и нижний слои ПП отдельно, чтобы было лучше видно...

В принципе согласен, но хочу заметить, что можно улучшить данный алгоритм (хотя и этот м.б. будет работать). Если посмотреть таблицу 11-1, то там видно, что нужно делать в каждом состоянии порта. Т.к. состояние порта нам доступно через IOCTL_INTERNAL_USB_GET_PORT_STATUS, то можно не делать лишних попыток, а сразу предпринимать нужные действия. И ещё я думаю, что IOCTL_INTERNAL_USB_ENABLE_PORT ни при каких условиях не будет возвращать ошибку. Откуда там может появиться ошибка? Только в одном случае - хаб на Setup вернёт STALL, а больше ни при каких условиях. Но хаб никогда не будет STALL возвращать. Просто порт останется в состоянии disable и всё. Нужно просто после подачи команд хабу проверять его состояние - опять же IOCTL_INTERNAL_USB_GET_PORT_STATUS.
На мой взгляд наибольшие сложности доставит поиск хаба и порта в который воткнут наш девайс. И ещё нужно как-то разделить ситуацию когда девайс действительно выдернули, и когда ошибка. Кол-во попыток восстановления ограничить что-ли?

Я так думаю, что при IOCTL_INTERNAL_USB_ENABLE_PORT USB_RESET не происходит. Просто девайс выйдет из Syspended и всё. А при IOCTL_INTERNAL_USB_RESET_PORT резет произойдёт. Кстати его вроде нужно подавать только если порт в состоянии Disconnected (хаб думает что девайс выдернут из порта). Но вот восстановить настройки в девайсе, а именно это, я думаю, имелось ввиду под правильной обработкой, может и программа на компьютере. Особенно это актуально для девайсов на базе FTDI и т.п. В них ведь невозможно ничего изменить внутре.

У меня в своё время не получилось, но видимо это из-за той ошибки в документации, на которую вы указали. Но вообще, если этой возможности нет, то все наши рассуждения - это пустопорожняя болтовня. Тогда нужно девайсы делать антизависающие - я в своё время по этому пути пошёл.

От драйвера зависит.
Я снял лог при замыкании D+ и D- на HID устройстве на базе pic18f2550.
Нажмите для просмотра прикрепленного файла
Оно таки само развесилось, в логе видно что реакция на сбой сильно отличается от ftdi и действия гораздо более осмысленные. Впрочем замыкания более 2-3 секунд HID тоже не переносит - виснет без каких либо сообщений об ошибках также как и ftdi.


Может с точки зрения usb.org и должен, но нас такое поведение категорически не устраивает.


насчет действий из UserMode - это отдельная интересная тема.
Я перезапуск силами PC делал как в исходнике devcon.

Сразу что мне не понравилось в разводке - толщина цепи питания. Там на месте кабеля я так понимаю дожен быть разъём? А где кондер на 4-й ноге? Тантал бы ещё по питанию и катушку на 5 В. хорошо бы поставить после УСБ разъёма.
Оффтоп: Похоже свою ФТ я убил замыканиями пинцетом ног D+, D-. Видимо случайно не то замкнул. Теперь она все время висит в суспенде. А винда ругается что устр-во не опознано.

Да, Pic здесь ни при чём. Надо отдать должное - майкрософт видимо над HID хорошо поработал. Ещё-бы - это ведь их изобретение. Хотя и MassStorage, когда я его исследовал, мне очень понравился. Ну на 1 треть запросов отвечаешь, на 2-ю треть не отвечаешь, а на 3-ю - вообще STALL посылаешь и всё работать продолжает! На реальные флешки смотришь (самые китайские) - там такой бардак, а всё работает. Никто ничего не замечает! Единственно вот с составным устройством там у них глюк. Если из-за ошибок в одном из интерфейсов энумерация происходит - другой теряется.

А что там за Clear Port Feature (3, Enable/Disable Change) в логе? Какой SetupPacket ему соответствует? Наверное подобным образом сделать следует.

Не должен. По логу это видно. Set Port Feature (3, Reset) - это видимо и есть IOCTL_INTERNAL_USB_RESET_PORT, который мы собираемся использовать. Хотя с уверенностью утверждать не могу - на сам пакет тоже не мешало бы посмотреть.

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

Драйвер Microsoft делал (но 3 сек не учел)


Вызовом Class Intstallera - вполне правильный и легальный способ и рекомендуемый Microsoft, кстати недели две назад
на форуме Microsoft спрашивали: почему IOCTL_USB_HUB_CYCLE_PORT не работает из UserMode - драйверописатель из Microsoft от ответа ушел - предложил вышеуказанный способ.

М.б. не 3, а 5? Тогда они всё по стандарту сделали, если в течении 5 секунд не удаётся ошибку исправить - всё.

Но зависать-то зачем - сделал remove device и всё.

Каюсь. Забыл увеличить. Было в планах
Неужели может повлиять?
Можно проволокой сверху потолще...



Да. Но с разъёмом я немножко напутал или не нашёл... поэтому впаял прямо кабель.



Нету его. Подвесим.



Тантал есть (снизу платы, 100 мкФ). Правда далеко стоит, ближе к DC-DC.
Нету ферритовой бусины, как на рисунке 6.1 в даташите.
Какую катушку лучше и как включить?



Там же резисторы внутри, не должно...

Просто от микрухи до оплетки линии далековато получается. Хотя в принципе это не high speed.

Тантал лучше ближе к микрухе.
Катушку у себя поставил 2,2мкГн, но думаю и без неё тоже будет работать.


Я походу не только +/-D замкнул. Видимо что то ещё.

Получается, что Clear Port Feature (3, Enable/Disable Change) это CLEAR_FEATURE + C_PORT_ENABLE. Её два раза вызывают чтобы изменить и сделать как было.
А Set Port Feature (3, Reset) это SET_FEATURE + PORT_RESET. Это видимо самое кардинальное лекарство от всех болезней, типа гильотины. Напоследок приберегли.

Добрый день.

Ну первое что лично мне не понравилось это несимметричная линия D+ и D-. Зачем нужно было ставить два переходных отверстия?? Да еще и с поворотом в 90 градусов, хотя и без прямых углов. Куда именно посажен SHELL разъема?? В какую точку земли? От этого тоже зависит устойчивость. Я бы поставил ее к общему проводу в районе источника питания. Там же поставил шунтирующих емкостей (керамику 0.1 и тантал на десяток uF). Потом что-то не помню я чтобы у FTDI были внутренние последовательные резисторы по шине D+ и D- (везде вешали внешние), но быть может уже все и изменилось. Поставил бы еще по шине D+ и D- защитные диоды. LC фильтр и варистор по USB питанию.

Попробуйте немного поиграться с переносом точки земления экрана кабеля и установкой защитного диода по питанию USB (ну варистор поставьте).
Еще хороший вариант (в качестве эксперимента) положить вашу плату в железную коробочку. Корпус объединить с общим проводом и до кучи его заземлить (в землю). Экран кабеля так же подключить к корпусу. И дальше в таком исполнении поиграться на предмет устойчивости. При этом всю схему питать уже не от USB, а от собственного источника, который будет сидеть на другой фазе по отношению к компьютеру. На мой взгляд если сбоить будет, то это уже точно помеха прикладываемая к USB хабу (неустойчивая работа хаба). Что в принципе сейчас в этой ветке и обсуждается(лось).

Вот такое мое мнение.

Следующий доклад

1. Порт закрыт. Обмена нет. Тыркаю вилкой - иногда возникает сбой. Т. е., ни ПК с портом не работает, ни МК в конверторе с FT245R не работает, а сбои возникают...
2. Ток потребления от USB левой части конвертора (по схеме) - не более 43 мА в режиме обмена.
3. Электролит по питанию переставил почти вплотную к распаянному на плату USB-кабелю.
4. Существенно утолщил цепь +5 В от USB-кабеля (пропаял приличным проводом сверху по дорожкам).
5. На вывод VCCIO FT245R повесил 0.1 мкФ (около 5 мм от вывода, ближе не получилось).
6. Сбои возникают даже при незапитанной правой части конвертора, т. е., кабель питания к разъёму питания конвертора не подключен. Вилкой источника питания дёргаем как обычно туда-сюда (напоминаю, что правая часть у меня сейчас запитана через обычный источник питания БПС 5-0.5).
7. Попробовал работать на рядом стоящем компьютере, подключенном к той же розетке, что и первый компьютер. Сбоев нет!



Для USB это критично?
Что значит "несимметричная"?
Всё объясняется просто
Плата собственного изготовления, без металлизации отверстий. Предполагал ставить USB-разъём. А разъём можно распаять только с обратной стороны платы...
Разъём не поставил, впаял в плату USB-кабель...



Распаян на общий сразу за проводами. Провода без экрана - около 8 мм.



Левая часть конвертора (смотри схему) питается от USB. Внешний источник питания используется только для правой части конвертора.



У микросхем с индексом "R" всё изменилось



Какие именно, любые? Катодами на линии, а анодами на общую цепь?
Ёмкость возле +5 В кабеля уже 100.0 стоит. Можно, индуктивность поставить. До конденсатора или после?
А варистор как выбрать? Какой, например?



Смущает то, что на рядом стоящем компьютере (более простом и старом) работает без сбоев (по крайней мере весь вечер).
А на первом компьютере - со сбоями. Я уже наловчился сбой с первого раза вызывать: выдёргиваешь вилку из удлиннителя и получаешь приличный зависон!



Где бы её ещё взять, другую фазу-то
А если неустойчивая работа хаба, то что же делать-то... не компьютер же бегать подбирать...



Спасибо всем большое за их мнения! Надеюсь, сообща разберёмся!