[StasK 0]

Есть следующая проблема:

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

[galjoen 0]

Посылка InterruptIn?

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

[StasK 0]

Посылка InterruptIn?

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

 

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

[galjoen 0]

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

Под win?

Если так, то скорее всего дело в вашем девайсе. Он в этой ситуации на IN от хоста NAK шлёт. Один раз у вас ACK от хоста потерялся и всё...

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

[Alex11 3]

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

[galjoen 0]

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

Т.е. другие, не InterruptIn, пересылки работают?

С драйвером HID я такого не наблюдал. По моему мнению майкрософт хорошо над ним поработал - надо отдать должное.

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

[StasK 0]

Т.е. другие, не InterruptIn, пересылки работают?

С драйвером HID я такого не наблюдал. По моему мнению майкрософт хорошо над ним поработал - надо отдать должное.

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

 

Так оверлаппед сделан, а что толку, все равно ничего не принимается.

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

Я так понял, что Interrupt имеет фиксированное время доставки. Возможно ли загрузить комп так, что он не успеет обработать InterruptIn.

[galjoen 0]

Так оверлаппед сделан, а что толку, все равно ничего не принимается.

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

NAK обработчик тоже есть. Может быть устройство занято обработкой других прерываний и не успевает иногда ответить на запрос хоста, но это вряд ли.

Так выведите вызов обработчика по NAK от InterruptIn EP на светодиод или неиспользуемый контакт (см. осциллографом). А когда устр-во занято и не успевает ответить - NAK автоматически посылается.

А вообще нужно выяснить идут-ли в той ситуации IN от хоста (тогда дело в устройстве - оно на них NAK посылает) или нет (тогда комп). IN можно даже осциллографом увидеть.

А Get(Set)Feature вы не используете? Они продолжают при этом слаться?

А кстати, SOF-то идут? Хотя конечно идут, иначе как вы ту посылку с кодом detach устройству отправляете.

Довольно тяжело отлаживать, когда ошибка выскакивает раз в час, а то и реже.

Я так понял, что Interrupt имеет фиксированное время доставки. Возможно ли загрузить комп так, что он не успеет обработать InterruptIn.

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

 

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