Проводя тесты со статическим электричеством столкнулись с проблемой, что USB на контроллере вылетает и не восстанавливается, помогает только RESET контроллера. После удара статикой стабильной приходит SUSPEND и мы пытались зацепиться за него, чтобы перезагружать USB, таким образом соединение восстанавливается только через 5-15 с. Возникает вопрос есть ли какие-нибудь еще способы вылечить контроллер? Используем стандартную библиотеку USB от StellarisWare с перехватом прерываний. Работаем в режиме USB -> serial.

Интересно, если взять тысячу брендовых устройств, хоть одно из них переживет без описанного вами или любого другого сбоя подобный эксперимент ? Сомневаюсь, и очень.Не стоит, наверное, использовать USB в критических применениях, и все.
А от необходимости корректной разводки платы никто никого не освобождает в любом случае. Как минимум, прочтите вот это:

http://caxapa.ru/lib/emc_immunity.html

5-15 секунд
у меня есть коммерческий оптически развязанный рс485-усб, так он когда рядом с ним запускают частотный регулятор двигателя виснет насмерть вместе с системой...

так что 5-15 секунд это не плохо, особенно если вы их детектите и можете все починить.

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

ocv997, а статика наводится от чего, и в какой ситуации? При подключении USB девайса к компу, или при подключении дополнительных устройств к УЖЕ подключенному USB девайсу?

Для USB такая работа является нормальной. Спецификация USB не предусматривает работу в условиях помех. Если ваше изделие должно функционировать в условиях помех применяйте индустриальные интерфейсы.

Вы делаете девайс, я так понимаю? Вам пришел suspend от хоста? От компьютера? Это было бы странно. Скорее всего вам пришло только прерывание, потому что ваш контроллер заглючил. Я бы настоятельно порекомендовал посмотреть логическим анализатором что происходит на шине непосредственно после разряда.

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

У меня именно так и проявлялось. Контроллер - LPC176x, хост - WinXP, Win7.
Как сделать remote wakeup, не разобрался, при попытках сделать от хоста тут же приходил повторный suspend.



Собственно, так и лечил. Перезагружать ничего не надо было, только коннект - дисконнект. Только вполне хватало задержки в долю секунды.

А что на шине происходило? Настоящий саспенд? Скорее всего никакого саспенда там не было, прерывание было левое и вызвано разрядом. Вообще мне думается вы самостоятельно не можете на компе активировать wakeup. эти режимы операционка контролирует.



Возможно, я уже не помню точную величину, просто запомнил что при быстром отключении-включении хост этого не замечал.

Зачем? Чем не устраивает обычный SOF (start-of-frame) событие, которое приходит с частотой 1 или 8 кГц без всяких доп. усилий?

Точно утверждать не буду, т.к. нормального аппаратного анализатора нет. Осциллографом я в шине разобраться не смог...

Но повторяемость 100%: разряд -> suspend ->попытка wakeup -> suspend -> ...

В итоге остановились на описанном выше методе, но "полезными" считаются только прерывания от endpoint-тов. А время между перезагрузками в случае не удачной перезагрузки(usb так и не получил прерываний) экспоненциально растет, начиная от 400мс. В итоге usb стабильно перезапускается через 1- 10 секунд