Народ, вы что то грузитесь. По-моему проблемму не там ищите. У меня 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 обратно и включают.

Сообщение отредактировал AndreyS - Feb 18 2009, 15:51

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

Сообщение отредактировал _3m - Feb 18 2009, 15:26

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

Причем (как нам показалось, а может это так и есть) такое наблюдается практически всегда на машинах с 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

Сообщение отредактировал Седой - Feb 18 2009, 18:29

Попробуем.



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



Проверим.



Схему привёл.
Левая часть устройства питается от 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.
[attachment=29876:hid_tst.html]
Оно таки само развесилось, в логе видно что реакция на сбой сильно отличается от ftdi и действия гораздо более осмысленные. Впрочем замыкания более 2-3 секунд HID тоже не переносит - виснет без каких либо сообщений об ошибках также как и ftdi.


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


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

Сообщение отредактировал _3m - Feb 18 2009, 19:37

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