Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: USB flash не принимает адрес
Форум разработчиков электроники ELECTRONIX.ru > Интерфейсы > Форумы по интерфейсам > RS232/LPT/USB/PCMCIA/FireWire
PAB
При отправке запроса SetAddress USB флэшке она не подтверждает приём адреса, т.е. должно быть так:
отправка запроса SetAddress устройству
setup token packet (от хоста): 0x2d 0x00 0x10
data packet (от хоста): 0xc3 0x00 0x05 0x02 0x00 0x00 0x00 0x00 0x00 0xeb 0x16
handshake packet (от устройства): 0xd2 (ACK)

подтверждение того, что устройство приняло адрес
token packet (от хоста): 0x69 0x00 0x10
data packet (от устройства): 0x4b 0x00 0x00 (пакет нулевой длины)
handshake packet (от хоста): 0xd2 (ACK)


а в реальности происходит так:
отправка запроса SetAddress устройству
setup token packet (от хоста): 0x2d 0x00 0x10
data packet (от хоста): 0xc3 0x00 0x05 0x02 0x00 0x00 0x00 0x00 0x00 0xeb 0x16
handshake packet (от устройства): 0xd2 (ACK)

подтверждение того, что устройство приняло адрес
token packet (от хоста): 0x69 0x00 0x10
handshake packet (от устройства): 0x5a (NACK)

то есть устройство говорит, что оно не приняло адрес (0x02).

Используется хост-контроллер USB1.1 OHCI. Может кто-нибудь сталкивался с подобной ситуацией? В чём может быть причина?
galjoen
token packet (от хоста): 0x69 0x00 0x10 - это, как я понимаю, запрос IN(1) по адресу 0. На это запрос устройство должно ответить пакетом данных DATA1 0й длины. Но если устройство не готово (не успело установить свой адрес =2), оно и должно слать NAKи в ответ на запросы IN(1) до тех пор пока адрес=2 не будет установлен. После этого устройство должно получить ACK от ХОСТа (по адресу=0) и перестать вообще отвечать на адрес=0 и начать отвечать на адрес=2. Т.е. вам нужно повторять попытки, посылая IN(1). (По правилам USB таймаут наступает через 5 секунд).
PAB
Цитата(galjoen @ Jul 3 2007, 18:43) *
token packet (от хоста): 0x69 0x00 0x10 - это, как я понимаю, запрос IN(1) по адресу 0. На это запрос устройство должно ответить пакетом данных DATA1 0й длины. Но если устройство не готово (не успело установить свой адрес =2), оно и должно слать NAKи в ответ на запросы IN(1) до тех пор пока адрес=2 не будет установлен. После этого устройство должно получить ACK от ХОСТа (по адресу=0) и перестать вообще отвечать на адрес=0 и начать отвечать на адрес=2. Т.е. вам нужно повторять попытки, посылая IN(1). (По правилам USB таймаут наступает через 5 секунд).



Именно это и происходит - посылка token in пакетов, чтобы получить долгожданный пакет нулевой длины от устройства. Но устройство его так и не присылает, происходит таймаут. Может ли быть так, что драйвер устанавливает время таймаута меньше положенных 50мс (по-моему именно столько даётся на получение пакета нулевой длины от устройства при запросе SetAddress)? Используется стандартный драйвер usb, который есть в линуксе.
vmp
Может быть это поможет.
Два лога подключения одной и той же флешки, в одном случае к компу с W98SE+драйвера на full speed, в другом - XP SP1, high speed. Снимались аппаратным анализатором.
PAB
Цитата(vmp @ Jul 4 2007, 17:32) *
Может быть это поможет.
Два лога подключения одной и той же флешки, в одном случае к компу с W98SE+драйвера на full speed, в другом - XP SP1, high speed. Снимались аппаратным анализатором.


спасибо за лог,
в компе какой хост-контроллер был: OHCI, UHCI, EHCI?


Цитата(PAB @ Jul 4 2007, 18:09) *
в компе какой хост-контроллер был: OHCI, UHCI, EHCI?


вопрос снят, из лога всё видно


если не секрет, каким аппаратным анализатором пользовались?

и ещё вопрос - по формату времени, показываемому анализатором:

time<2.106 500 150> - time<2.107 500 017> сколько времени прошло?
vmp
Цитата(PAB @ Jul 4 2007, 18:26) *
если не секрет, каким аппаратным анализатором пользовались?

Ellisys USB Explorer 200

Цитата(PAB @ Jul 4 2007, 18:26) *
и ещё вопрос - по формату времени, показываемому анализатором:
time<2.106 500 150> - time<2.107 500 017> сколько времени прошло?

Насколько я понимаю, время в секундах, т.е. 2.107500017-2.106500150=0.000999867 секунды или около 1 миллисекунды.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.