doeslo 0 10 ноября, 2021 Опубликовано 10 ноября, 2021 (изменено) · Жалоба lpc2468. Достоверно известно, что USB работает Инициализировал USBD1 интерфейс чётко по мануалу. Использовал переработанные кейловские функции. Кстати, кейловский пример USBMem для lpc24xx не работает вообще. Картина такая (номер пункта соответствует порядковому номеру прерывания): 1. Приходит reset. Я полагаю, что ничего здесь делать пока не надо и не делаю. 2. Приходитят данные пакета "0х8006000100004000". Пытаюсь отправить первые 8 байтов дескриптора, через slave mode регистры. При опросе регистра USBDevIntSt бит ERR_INT не устанавливается. При запросе кода ошибки SIE показывает 0х19, что соответствует "send/received NAK". Обе нулевые конечные точки при запросе их статуса показывают 0х00. Далее прерывания начинают чередоваться, сначала 1, потом 2, потом снова 1, потом 2 и, наконец, я вижу, что хаб наказал моему устройству перейти в suspend mode, что говорит о том, что дескриптор отправлен не был. Так вот вопросы: "Поднимал ли кто-то USB без кейловских библиотек? Сталкивались ли с чем-то таким? С чем это может быть связано?" Из странного: биты RXENDPKT и TXENDPKT регистра USBDevIntSt не устанавливаются, что при передаче, что при приёме. Хотя в даташите написано, что должны. Если что-то забыл упомянуть - спросите Изменено 10 ноября, 2021 пользователем doeslo Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
VladislavS 29 10 ноября, 2021 Опубликовано 10 ноября, 2021 · Жалоба А почему 8 байт дескриптора, когда хост просит 64? Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
doeslo 0 10 ноября, 2021 Опубликовано 10 ноября, 2021 (изменено) · Жалоба 1 час назад, VladislavS сказал: А почему 8 байт дескриптора, когда хост просит 64? Потому что это первый обмен пакетами, хост еще не в курсе какая у нулевой конечной точки максимальная длина поля данных пакета. Надо передать минимально возможное количество данных, т. е. 8 байт, насколько я понял(да и, вроде бы, в дескрипторе устройства больше 18 байт быть не может, по протоколу). Потом от хоста должен последовать пакет SET_ADDRESS (но я не в курсе обрабатывает его SIE или программа мк) и вот уже после должен быть пакет с похожим содержанием, только с нормальной, для запроса дескриптора, длинной IN пакета - 18 байт, Таким образом пакет будет выглядел вот так "0х8006000100001200" , но я такого пакета еще не видел. Впрочем, я и 18 и 64 байт отправлял. Результат тот же Изменено 10 ноября, 2021 пользователем doeslo Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
nibelung 7 10 ноября, 2021 Опубликовано 10 ноября, 2021 (изменено) · Жалоба 48 минут назад, doeslo сказал: Потому что это первый обмен пакетами, хост еще не в курсе какая у нулевой конечной точки максимальная длина поля данных пакета. Надо передать минимально возможное количество данных, т. е. 8 байт, насколько я понял(да и, вроде бы, в дескрипторе устройства больше 18 байт быть не может, по протоколу). Потом от хоста должен последовать пакет SET_ADDRESS (но я не в курсе обрабатывает его SIE или программа мк) и вот уже после должен быть пакет с похожим содержанием, только с нормальной, для запроса дескриптора, длинной IN пакета - 18 байт, Таким образом пакет будет выглядел вот так "0х8006000100001200" , но я такого пакета еще не видел. Впрочем, я и 18 и 64 байт отправлял. Результат тот же Неправильно понимаете. Первый раз хост, действительно, не знает размер буфера ваше EP0 и просит вас передать не более 64 байт, по первым 8 байтам дескриптора он определит размер буфера вашей EP0. В ответ вы должны выбрать минимальное из трех значений (запрошенные 64 байта, размер буфера EP0, размер дескриптора 18 байт) и ровно столько отправить. К примеру если размер буфера EP0 равен 16 байтам - то и отправлять нужно 16, а если размер буфера EP0 64 байта - то отправлять нужно 18 байт. В ответ хост должен прислать RESET, затем повторно запрос дескриптора и только потом назначить адрес. Изменено 10 ноября, 2021 пользователем nibelung Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 182 10 ноября, 2021 Опубликовано 10 ноября, 2021 · Жалоба 3 часа назад, doeslo сказал: Так вот вопросы: "Поднимал ли кто-то USB без кейловских библиотек? Сталкивались ли с чем-то таким? С чем это может быть связано?" Поднимали. Давным-давно на похожем МК (LPC23xx). USB-device. За основу тогда брал примеры идущие с IAR. Всё работало нормально. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
doeslo 0 10 ноября, 2021 Опубликовано 10 ноября, 2021 (изменено) · Жалоба 19 минут назад, nibelung сказал: Неправильно понимаете. Первый раз хост, действительно, не знает размер буфера ваше EP0 и просит вас передать не более 64 байт, по первым 8 байтам дескриптора он определит размер буфера вашей EP0. В ответ вы должны выбрать минимальное из трех значений (запрошенные 64 байта, размер буфера EP0, размер дескриптора 18 байт) и ровно столько отправить. К примеру если размер буфера EP0 равен 16 байтам - то и отправлять нужно 16, а если размер буфера EP0 64 байта - то отправлять нужно 18 байт. В ответ хост должен прислать RESET, затем повторно запрос дескриптора и только потом назначить адрес. Хм. Таким образом, если у меня максимальный размер буффера 8 байт, то отсылаю я сначала 8, жду ресета и уже после этого ко мне должен прийти "0х8006000100001200", на который я отвечу 18 байтами, а потом SET_ADDRESS? 18 минут назад, jcxz сказал: Поднимали. Давным-давно на похожем МК (LPC23xx). USB-device. За основу тогда брал примеры идущие с IAR. Всё работало нормально. Спасибо за наводку. Завтра гляну Изменено 10 ноября, 2021 пользователем doeslo Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
nibelung 7 10 ноября, 2021 Опубликовано 10 ноября, 2021 · Жалоба 9 минут назад, doeslo сказал: Хм. Таким образом, если у меня максимальный размер буффера 8 байт, то отсылаю я сначала 8, жду ресета и уже после этого ко мне должен прийти "0х8006000100001200", на который я отвечу 18 байтами, а потом SET_ADDRESS? Ну да. Только отвечать нужно будет 8 байт, затем, когда хост их заберет еще 8 байт и потом еще 2 байта. Только я не уверен что на lpc24xx нужно делать именно так. Я поднимал USB на stm32f103, а там данные нужно самостоятельно на блоки в размер буфер конечной точки разбивать. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
doeslo 0 10 ноября, 2021 Опубликовано 10 ноября, 2021 · Жалоба 1 минуту назад, nibelung сказал: Ну да. Только отвечать нужно будет 8 байт, затем, когда хост их заберет еще 8 байт и потом еще 2 байта. Только я не уверен что на lpc24xx нужно делать именно так. Я поднимал USB на stm32f103, а там данные нужно самостоятельно на блоки в размер буфер конечной точки разбивать. Здесь, вроде бы, так же. Не подумал об этом, на самом деле. Может в этом была ошибка. Но почему биты RXENDPKT и TXENDPKT не устанавливаются - загадка... Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
doeslo 0 11 ноября, 2021 Опубликовано 11 ноября, 2021 · Жалоба Нет, проблема осталась. У меня вообще не идут прерывания от tx контрольной точки, которая сигнализировала бы о том, что данные переданы. Вместо этого у меня происходят описанные в шапке прерывания, а в статусе конечной точки высвечивается, что буфер полон, хотя я только что считал из него данные (я даже пробовал несколько раз данные считывать в одном прерывании, что странно, результат тот же и флаги статуса такие же), в этом же прерывании при запросе кода ошибки от SIE возвращается "send/received NAK". Что очень странно. Ничего не понимаю. Буду смотреть что там в IAR Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
doeslo 0 17 ноября, 2021 Опубликовано 17 ноября, 2021 · Жалоба Я полагаю, что проблема была в огромном количестве посылок в UART в течении USB-прерывания. Так делать нельзя Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
