Требует ли класс запоминающих устройств USB повторного перечисления после тайм-аута?

это может быть глупый вопрос,

Я отлаживал USB-накопитель на платформе ARM-CortexM4 (серия STM32F4), на которой работает встроенный Linux. ARM работает как USB-хост и пытается обмениваться данными с флэш-накопителем на полной скорости USB (12 Мбит / с).

Теперь вот в чем проблема. После успешного перечисления и нескольких команд SCSI через BULK передачи, емкость и все данные могут быть прочитаны правильно. Однако примерно через 15 секунд, когда я снова пытаюсь отправить эти SCSI-команды (при тех же условиях), хост-контроллер USB просто возвращает «Transaction Error», что выглядит так, будто устройство больше не отвечает на BULK-передачи (не ACKing), и время ожидания хост-контроллера истекло. Вопрос в том, существует ли какой-либо механизм тайм-аута для класса запоминающих устройств USB или системы SCSI, такой, что после тайм-аута система должна быть повторно перечислена или повторно проверена, иначе она больше не будет отвечать?

Я понимаю, что это может быть из-за глупой ошибки в моей программе или из-за некоторых ограничений на конкретное оборудование. Однако, когда я использовал модуль usbmon в Linux на ПК для захвата передач на одном и том же флэш-накопителе, я вижу, что операционная система фактически отправляет команду проверки последовательности (Read-max-Lun, а затем Test-unit-ready) каждые 5 сек, что может быть причиной того, что флешка не выходит из строя на моем ПК.

Спасибо! Я с нетерпением жду ответов.


embedded-linux arm usb linux-device-driver usb-mass-storage
person caoyuan9642    schedule 21.01.2015    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Я думаю, что вы на правильном пути с командами Test Unit Ready. Я занимаюсь написанием драйвера запоминающего устройства для встроенного устройства, и при тестировании на OS X после начальных запросов SCSI мое устройство получает Test Команда Unit Ready примерно раз в секунду, когда не происходит никаких других действий. Поскольку ваш пост довольно старый, я рекомендую вам опубликовать собственное решение, если вы с тех пор решили свою проблему.

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

person bazz    schedule 28.03.2015
comment
Я ценю твой ответ. К сожалению, эта проблема какое-то время не решалась, и я пока от нее отказался. Однажды я попытался вернуться к прошивке USB Host, предоставленной STMicro, и, похоже, она работала, однако я попытался скопировать все в свой драйвер устройства Linux, и он зависает через несколько секунд, как и раньше. - person caoyuan9642; 30.03.2015
comment
Моя проблема может отличаться от вашей, поскольку я отлаживаю хост, а вы разрабатываете устройство. Я не знаю, кому следует отправлять периодические Test Unit Ready. Очевидно, что он не отправляется никуда внутри самих драйверов ядра Linux автоматически, поэтому я подозреваю, что он отправляется некоторыми демонами пользовательского пространства, такими как udev? Я не очень знаком с программами пользовательского пространства, это только предположение. Надеюсь, что любой эксперт в этом мне поможет. Спасибо! - person caoyuan9642; 30.03.2015