Народ - тоже пытаюсь разобраться с USB - но в голове каша

У меня аппаратный контролер USBN9604 на внешней шине AVR.

Грубо говоря - доходит процесс инициализации до отправки дескриптора устройства - приходит запрос на обслуживание приемника конечной точки 0 - принимается

80 06 00 01 00 00 40 00 HEX

Это вроде как запрос на передачу дескриптора (06h) , устройства (01h)

Начинаю - гружу первые 8 байт в FIFO - запускаю передачу. По прерыванию о подтверждении приема - гружу следующие, а подтверждения нет

Вместо этого мне приходит :

00 00 05 01 00 00 00 00 HEX

Типа запрос статуса электропитания - но первый байт-то 80 должен быть ?

Иногда даже после первого блока нет подтверждения. Главное нестабильная работа - под отладчиком походу глупо работать, слишком медленно или что ? Даже не знаю куда копать.

В общем - как вообще правильно передавать дескриптор. Или банально ждать, читая бит состояния об освобождении части FIFO и допихивать ?

Копаюсь, понятно, в кусках чужой программы (для другого процессора) и там сделано так, что ожидается получение подтверждения о приеме от хоста и только потом перезагружается FIFO

00 00 Если не ошибаюсь- это ZLP. Наверное хост принял что хотел, т.е. подтвердил. Попробуйте после него принять следующие данные от хоста.
Я в МК выделял память под лог и уже потом анализировал. И еще что-то сохранял перед точкой останова. Поройтесь по этому топику. Я где-то там лог выкладывал как у меня обмен шел.

Как выяснилось хост трижды запрашивает дескриптор устройства, но каждый раз после второй передачи (буфер конечной точки 0 всего 8 байт) никак не реагирует, где-то через 0,5 сек снова запрос, ответ ASK=1 (в аппаратном регистре контролера) посыл второго блока - в ответ тишина. Потом третья попытка запроса.

Сейчас дам лог запросов по первым 3 байтам еще раз.

80 06 00
00 05 01

80 06 00
00 05 01

80 06 00
00 05 01

80 06 00
00 05 01

То есть не приняв до конца дескриптор устройства ему хост пытается задать адрес, но почему-то тоже не может.

Причем адрес "01h" принимается и вписывается в соответствующий регистр, ответом идет пустой пакет.

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

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

Это назначение адреса. Нужно ответить ZLP как от безадресного устройства, а затем уже работать с назначенным адресом.

Хост запросит 18 байт дескриптора устройства уже от устройства с адресом. Получив их, запросит весь дескриптор и т.д.

Организация питания на основе надежных литиевых аккумуляторов EVE и микросхем азиатского производства

Качественное и безопасное устройство, работающее от аккумулятора, должно учитывать его физические и химические свойства, профили заряда и разряда, их изменение во времени и под влиянием различных условий, таких как температура и ток нагрузки. Мы расскажем о литий-ионных аккумуляторных батареях EVE и нескольких решениях от различных китайских компаний, рекомендуемых для разработок приложений с использованием этих АКБ. Представленные в статье китайские аналоги помогут заменить продукцию западных брендов с оптимизацией цены без потери качества.

Подробнее>>

ZLP - это пустой пакет ?

Ответить надо еще с нулевым адресом или с принятым, я отвечаю с принятым.

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

А вот и нет как получается:

В описании контролера, а именно бита управления в регистре конечной точки 0

Default Address. When set, the device responds to the default address regardless of the contents of FAR6-0/EP03-0 fields.
When an IN packet is transmitted for the endpoint, the DEF bit is automatically cleared.
This bit aids in the transition from default address to assigned address. The transition from the default address
00000000000b to an address assigned during bus enumeration may not occur in the middle of the SET_ADDRESS control
sequence. This is necessary to complete the control sequence. However, the address must change immediately after this
sequence finishes in order to avoid errors when another control sequence immediately follows the SET_ADDRESS command.
On USB reset, the firmware has 10 mS for set-up, and should write 0x80 to the FAR register and 0x00 to the EPC0 register.
On receipt of a SET_ADDRESS command, the firmware must write 0x40 to the EPC0 register and 0x80
<assigned_function_address> to the FAR register. It must then queue a zero length IN packet to complete the status phase
of the SET_ADDRESS control sequence.

Регистр с именем FAR - это регистр адреса в младших 7 битах и бит разрешения использования адреса в старшем 8 бите.

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

По факту - после установки адреса идет действительно повторный запрос дескриптора устройства и его дают передать теперь весь, но затем никаких запросов вообще нет. Что должно запрашиваться далее ?

Да первый раз просит 40 байт дескриптора, а второй - ранее переданную длину в 18 байт.

Но далее ступор и причем хаб подвисает, явно чего-то еще ожидая. Потому как устройство, как неопознанное не появляется.

Такое ощущение, что хаб сменил адрес моему устройству, а сам продолжает долбиться по 0000000b - если отключить проверку адреса - видно что он еще непостоянное (1-3 раза) посылает - то запрос дескриптора, то установку адреса. Причем может по два раз подряд давать одно и тоже. Что-то ему не нравиться. А вот посмотреть с каким адресом ко мне идет очередное обращение я не могу / не знаю как.

Интересно- есть-ли какие-то программные логгеры со стороны компьютера, которые способны вести лог на уровне установочных (SETUP) пакетов ? Все что я до сей поры встречал работают с уже определенными в системе устройствами.

Лог. анализатор может помочь.

Добавлено after 13 minutes 19 seconds:

Я какой-то программой пользовался. Вроде триальная была. Какие то данные давала, до конца не разобрался. Порылся на компе, нашел какой то дистриб. Наверное она. Выложил в облако.

С логическим анализатором тянущим обмен по USB плохо - скорости там немалые.

За программу спасибо - попробую разобраться

У Вас HS чтоли?

Формально HS по спецификации используемого контролера, но нигде нет переключения в другой режим потому не знаю.

Как я понимаю я должен о том хосту заявить для начала - а что происходит мне пока непонятно. Программа не видит устройства и все время срывается на другие USB устройства, если выбрать пункт "Next connected device"

Сейчас выяснил свежее. После активации приемника хост около 4 раза генеряться события альтернативной функции RESUME, SD3, WKUP, затем около 40 раз RESET + WKUP - ну типа нас сбрасывают.

Затем запрос дескриптора, опять 18 раз RESET + WKUP, затем задача адреса, второй запрос дескриптора устройства и тишина.


Еще генеряться события NAK, которые я вообще не в курсе, что такое ??? После первого запроса по FIFI0 перед установкой адреса токен OUT но с какой-то вероятностью одновременно и IN и OUT - как на это реагировать мне неведомо, но согласно имеющегося примера ставлю для OUT - включаю приемник конечно точки 0

LS или FS/HS задается подтягивающим резистором. Между FS и HS как-то хост узнает программно, может шину слушает. Ваш контроллер я не знаю, но может задается тактовым генератором?

Почитать Вам надо про USB. Агурова чтоли... Не помню как расшифровывается NAK. Это ответный пакет типа данные не готовы. Это штатная ситуация/ Можно бесконечно отвечать наком. Собственно перефирия МК сам формирует этот нак на каждый запрос хоста, пока контроллеру не скажешь что можно что-то ответить.

Кстати. Любая ошибка в дискрипторе и хост пошлет подальше подключенный девайс.

Передаю 12 (длина HEX) 01 10 01 00 00 00 08 (для данной оконечной точки 8 емкость FIFO) B4 04 (VID) 1F 0F (PID) 10 00 01 02 03 01 HEX

Резистор стоит как HS

По последним данным есть 3 попытки запрос дескриптора, после 16 байт установка адреса, затем сброс и заново. То есть не нравиться дескриптор.

На старте так :

1) Запрос дескриптора
2) Отправка первых 8 байтов
3) Запрос на передачу
4) Отправка еще 8 байт
5) Запрос установки адреса
6) Сразу же-за ним запрос на передачу.

Должен ли я при запросе смены адреса допередать дескриптор и только потом менять адрес или бросить все и менять адрес или как ?

После передачи пследнего байта дескриптора приходит еще запрос на обслуживание передачи - как на него отвечать - видимо в этом кроется засада. Может отправлять пакет нулевой длины ?

Чуток продвинулся - оказывается при передаче дескриптора нужно первый блок передавать с DATA PID 1 а только второй с DATA PID 0 и далее чередуя.

Соответственно удалось пропихнуть в хост корректно дескриптор устройства, после чего был запрошен дескриптор конфигурации, а вот следующий запрос более чем странный

80 06 03 03 09 04 FF 00 - вроде как 3я часть строчного описания устройства. Но поля со значениями 09 04 - напрягают - там по логике 00 00 быть должно.

После отправки строки номер 3 идет повторный запрос дескриптора конфигурации 80 00 06 02 00 00 09 00 (причем длину хост уже знает).

Сделал сквозное "мигание" с установки в "1" в процедуре сброса - теперь странный запрос не приходит а приходит запрос языка

04 03 09 04 передаю, потом опять требует дескриптор конфигурации, но с длиной FF - значит предыдущего не принял

Отправляемый дескриптор конфигурации : 09 02 28 00 (пока от балды - если считать что МЛ, СТ - то 40 байт на последующие описания) 01 01 00 80 (питаемся от USB) AF (350 мА)

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

Основной вопрос с DATA PID - как и когда ставить его в какое состояние ? А как для пустых пакетов ?

Люююдиии - тут хоть кто-нибудь есть разбирающийся с USB на уровне обмена конкретными данными через приемо-передатчики - есть вопросы:

1) Можно-ли в Win XP определить причину отказа USB устройству в опознании. HDD Device monitor видит только подключенные и определенные устройства.

2) Поле DATA PID в регистрах управления передатчиками конечных точек - когда и какое значение ставить, всегда-ли переворачивать для следующей передачи или только в рамках обмена одним пакетом (передачи 1 дескриптора) ? Для пакетов 0 длины ?

3) Что значат 5 и 6 (1-8) байты с начала пакета SETUP ?

4) После запроса дескриптора конфигурации (с запросом длины 9 байт) запрашивает дескриптор языка, но после него снова конфигурацию но уже 256 байт - потом дает устройству отлуп.

В STM они сами переключаются как надо, хотя я пробовал и в ручную (на этапе ХЗ что происходит). Быть может это связано с тем что я данные и принимал и передавал за раз. Буфер у STM 512 байт вроде и под мои задачи более чем, как говорится.

Абсолютно тот же самый запрос мне приходил. Я Вам уже говорил, что я лог запрос вел и что он есть в этом топике, Вы нашли его? В этом логе только то что приходило от хоста, что отправлял не логировал. Обратите внимание. Хост запрашивает что-то, если получает то что хочет, отправляет ZLP. Лог вроде как не весь.
По ZLP. Если Хост Вас сказал что то сделать, но в ответ данных не требуется, надо ответить zlp.

От балды надо повнимательнее, что-нибудь не сойдется и хост пошлет. Например в дескрипторе одна длина, а Вы шлете другую. Книга не ахти, согласен. Но особых вариантов нет. У него две книги кстати, название не помню их, они похожие, но есть и разная инфа.

Добавлено after 15 minutes 46 seconds:
Вот еще что вспомнил.
Если передать VID/PID такой, который винда еще не видела. То на каком-то этапе обмена, хост присылал "странный" запрос. Он вроде был толи похож на запрос строки, то ли как запрос строки. Активное гуление показало , что это связано с протоколом MTP (это вроде виндовский протокол для обмена с гаджетами или что-то в этом роде). На этот запрос отвечал stall.

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

Мне ручками переключать приходится и как правильно я пока не нашел нигде.

Ссылку на лог видел - но открыть нечем. Какой-то архив с *.xml внутри. Смотреть такой нечем.

Если ответить нечего - отвечаю пустой посылкой - только опять-же вопрос о значении DATA PID - его крутить внутри каждой передачи или это сквозное кручение с момента инициализации контролера ?

Просто с дурной (видимо) головы передача идет из очень разных мест кода.

Согласно найденному в сети в 3 и 4 (счет с 1го) байтах дескриптора устройства указывается суммарная длина дескриптора интерфейса + дескрипторов всех конечных точек. Но ради интереса ставил и 9 и 0 - толк тот-же - что-то не нравиться.

Стал читать в эту сторону выяснил что этот дескриптор тоже должен запрашиваться дважды - сначала с длиной 9 а потом с длиной из 3 и 4 байта, но у меня почему-то с FFh - по второму запросу отправил в сумме 5 дескрипторов

Конфигурации (повторно)
Интерфейса
HID устройства (ничего умнее не придумал - думаю не HIS будет еще сложнее
и для 2х конечных точек одну для чтения, вторую для записи. (всего 41 байт вышло)

А в ответ пошли запросы с этим неидентифицируемым 80 06 02 03 09 04 FF 00 причем непрерывно где-то раз в 2-3 секунды.

Возможно идут какие-то запросы уже к самим конечным точкам - я их еще не обслуживаю. То есть нет реакции на запросы к ним.

ЗЫЖ не идут. идут попеременно запрос языка и запрос странный.

xlsx - это excel .

Про DATA и PID я сам уже подзабыл , но у того же Агурова про них вроде все расписано. Но наверняка Ваш МК должен это все сам генерить, иначе USB в какой-то программный превращается.


По поводу дискрипторов. Я же выкладывал исходник, тему перенесли, поищите там где начали писать. Исходник не очень, но рабочий. Понятно что МК не тот, но дискрипторы то можно оттуда взять.

Изначально у меня тоже было две конечные точки и работали с прерываниями. А они работали, только как то у меня не очень получалось данные с компом обменивать. Заменил репорт на фьючи и получилось проще как-то. Хотя я точно и не понял для чего они предназначены, но через них обмен тоже нормально идет. Но обмен получился и я успокоился и добрую (злую тоже) часть чего дела успешно забыл.

У Агурова не нашел внятно. Может искал плохо - но не нашел. Экспериментально , кстати, установил, что передача квитанции после установки адреса возможна только для DATA PID ="1"

В моем случае выставляются руками вместе с разрешением передачи.

Просмотрьщих документов exel не открывает.

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

Я написал по небольшому отработчику для 1 ой и 2ой конечных точек - нет - запросов к ним нет.

Вчера мучался - в какой-то момент у меня вдруг прошла длинная цепочка запросов - я видел в логе и корректный запрос дескриптора конфигурации с указанной длиной в 3-4 байтах. Далее были запросы, отработчиков которых я пока не написал. Но повторить не смог. Какой-то видимо глюк хаба.

На данный момент факт в том, что дескриптор конфигурации корректно хабом не принимается. Причины непонятны. Проблемы в какой-то мелочи, а не в общей логике.

Есть еще одно явление - это остановка обмена после 12 запросов от хаба - то есть полный ступор и даже нет повторных запросов - где-то видать какой-то счетчик.

Просто не знаю куда далее двигаться, у кого спросить....

Кстати странный запрос - не странный - я выяснил - в 4-5 байте при запросе строковых дескрипторов содержится ранее принятая хабом кодовая страница языка.

80 06 02 03 09 04 FF 00 - запрос 2 текстового дескриптора для случая английского языка 0409

Работаю полностью по прерываниям, но физически оно одно, а далее разбор на возможные 2 десятка по состоянию битов в 3х регистрах. Зато удобно с приоритетами. А то когда генеряться сразу несколько прерываний - приходилось сильно изворачиваться что-б обслужить в нужном порядке.