Есть следующая проблема:
Контроллер (AT89C5131) передает данные в комп по HID USB 2.0. Иногда происходит сбой в передаче и комп перестает принимать посыки. Вроде этот сбой происходит, когда комп чем-то занят (много приложений открыть и т.д.). Устройство продолжает оставаться в списке конфигурации и ре-инициализации не происходит. Интересно, что устройство продолжает получать посылки с компа, отправлять ответ, но комп со своей стороны не получает (или вернее моя прога на VC6 не получает). Пока я решил эту проблему очень топорным способом. Как только комп перестает получать сообщения с устройства, комп посылает посылку с кодом, по которому устройство делает detach. Но хочется понять причину и исправить не так радикально, как detach.

Посылка InterruptIn?
Пропадают одиночные посылки или вообще перестают приходить?

HID, на сколько я знаю, Interrupt. Вообще комп перестает принимать.

Под win?
Если так, то скорее всего дело в вашем девайсе. Он в этой ситуации на IN от хоста NAK шлёт. Один раз у вас ACK от хоста потерялся и всё...
На всякий проверьте не запрещается-ли соотв-я EP (ну это навряд-ли, тогда бы вас хост перенумеровал). И повесьте обработчик на посылку NAK хосту. Если у вас его ещё нет. Но если вы хотите получить надёжную связь - посылку NAK-ов обрабатывать нужно ОБЯЗАТЕЛЬНО. Без этого в некоторых ситуациях невозможно понять что хочет от вас хост.

Мы тут тоже боремся с аналогичной проблемой. Засада, похоже, в драйвере USB-COM. При неудачном стечении обстоятельств он перестает посылать IN на устройство, в результате оно ответить не может. Данные на устройство проходят. У нас это происходит, если в системе сначала было два устройства, а затем одно выдернули. Второе оказывается в таком состоянии.

Т.е. другие, не InterruptIn, пересылки работают?
С драйвером HID я такого не наблюдал. По моему мнению майкрософт хорошо над ним поработал - надо отдать должное.
А ещё проблемма м.б. в readfile - ведь с помощью его InterruptIn из HID читается. Там не так просто оверлаппед сделать. Т.е. чтобы не ждать если ничего ещё из устройства не пришло.

Так оверлаппед сделан, а что толку, все равно ничего не принимается.
NAK обработчик тоже есть. Может быть устройство занято обработкой других прерываний и не успевает иногда ответить на запрос хоста, но это вряд ли. Довольно тяжело отлаживать, когда ошибка выскакивает раз в час, а то и реже.
Я так понял, что Interrupt имеет фиксированное время доставки. Возможно ли загрузить комп так, что он не успеет обработать InterruptIn.

А устройство в таких ситуациях не пропадает?

Так выведите вызов обработчика по NAK от InterruptIn EP на светодиод или неиспользуемый контакт (см. осциллографом). А когда устр-во занято и не успевает ответить - NAK автоматически посылается.
А вообще нужно выяснить идут-ли в той ситуации IN от хоста (тогда дело в устройстве - оно на них NAK посылает) или нет (тогда комп). IN можно даже осциллографом увидеть.
А Get(Set)Feature вы не используете? Они продолжают при этом слаться?
А кстати, SOF-то идут? Хотя конечно идут, иначе как вы ту посылку с кодом detach устройству отправляете.

Мне так загрузить комп не удалось.

А кстати, почему вы не пользуетесь к.л. USB-сниффером (программым)?