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



Могу только посоветовать начинать учить его. Без этого ничего серьезного не сделать. В частности, по USB я не встречал публикаций лучше USB made simple и USB in a nutshell. Впрочем, вторую публикацию вроде бы даже перевели, но к переводам я всегда призываю относиться осторожно.

Точно не менять адрес до сброса ? Все дело в том что в имеющемся примере (для другого процессора но с тем-же контролером) при команде сброса от хоста адрес тоже сбрасывается. В документации на контролер этот момент описан мутновато. Но если послать пустой пакет с адресом 000000, то далее запросов нет вообще, а если с принятым адресом - то следуют запросы дескриптора и только потом ступор. Грешу все-ж на некоррекную генерацию DATA PID - "переворачивать" это бит надо когда, а когда не надо не нашел вообще нигде.

Заголовок ДШ говорит что FS, да и генератор на 48МГц только для FS. Так что китайский анализатор Вам поможет.

Очень поверхностно глянул ДШ. Такое впечатление, что при генерации хостом сброса USBN сам не сбрасывает свои регистры. Если конечно под firmware понимается прошива внешнего МК.



С точки зрения протокола. После сброса все запросы идут на адрес ноль. После прихода пакета установки адерса, отвечаешь ZLP как от безадресного устройства (я это уже писал). Дело в том, что подчиненное устройство само никогда не начнет передачу, только после запроса IN. А хост после установки адреса, будет слать IN к безадресному устройству (адр. 0). Получив от такого адреса ZLP, далее хост будет слать пакеты уже на установленный адрес. Другой вопрос, как это реализовать на Вашем контроллере, надо разбираться, может какие-то вещи сам на себя берет.

Сброс от хоста (SE0) - это работа с чистого листа. Хост работает с функцией, что-то не понравилось - послал SE0 на линию и пробует все сначала. Пытаться он будет так максимум три раза. По факту с STM у меня проходило 4 сброса (на кривой прошивке), по всей видимости первый SE0 был ложный, в момент подключения к USB.

Насколько я помню, если ваши данные не входят в один пакет, а передаются частями, надо чередовать Data0, DATA1. Некий контроль целостности порядка передачи данных. Начинать с DATA0. Судя по размеру буфера 8 байт, Вам почти всегда надо разбивать данные на пакеты.
Еще вспомнил нюанс. Вроде где-то в каком-то дискрепоторе устанавливается максимальный размер передаваемых данных в пакете. Например установлено 8 байт. Вам нужно передать 15 байт. В первом пакете ушло 8 байт, во втором 7. Хост увидел что пакет не полный и знает что данные все отправлены.
Второй случай. Отправляете данные кратные размеру пакета. Например 24 байта. Для хоста идут полные пакеты и он не может определить что данные все. Поэтому после 24 байт, надо отправить еще zlp не забывая переключать data0/1.
После получения данных хост ответит zlp.

Это я все из памяти своей ненадежной, так что могу безбожно врать, уж извините. Кроме того, я работал STM. Там буфер 512 байт за вычетом небольшого. Наверное я устанавливал размер предела пакета 1024 байта, а слал всегда значительно меньше и все в одном пакете. Кроме того возможно STM сам чередует data0/1, но скорее всего ничего не чередовал, т.к. нет необходимости.

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

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

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