Здравствуйте. Есть ли тут гуру, у кого есть успехи в USB на регистрах на stm32?
Конкретно чип stm32g474ceu6
Необходимо реализовать CDC (Serial Com)
В качестве базиса взял Middleware библитеку от ST, хоть там и крайне сложно разобраться из-за многочисленных переходов между разными модулями (HAL, LL, PCD и т.д.). Так же долго курил Reference Manual от ST и Документацию по USB протоколу в разных нарезках.
Первая проблема, с которой столкнулся: нигде нет рекомендованного процесса обработки запросов от хоста к устройству. С дебагом тоже сложно, т.к. таймауты на ответы очень маленькие.
Чего добился в своих изысканиях - полностью проходит инициализация:
- все дескрипторы пересылаются
- в списке USB устройств на хосте устройство появляется с нужными описаниями
- serial-порт в системе есть
- при подключении к serial-порту проходят стадии CDC_SET_CONTROL_LINE_STATE и CDC_SET_LINE_CODING, параметры передачи получаю
Т.к. я делал на базе Middleware от ST, двойную буферизацию не использовал, применены две доп точки:
- ID=1 - Data = Bulk-type, in/out, размер буфера 64 байта
- ID=2 - Notify = interrupt, 8 байт, передача только в сторону хоста.
Но вот при попытке передачи данных начались проблемы. Отправку в сторону хоста вообще не понял, как отладить.
При отправке с хоста на устройство возникли две проблемы, пояснения по которым и прошу от гуру:
1. Прерывание USB_ISTR_CTR возникает, но получается ситуация, когда указанная в ISTR конечная точка точка в своём регистре не имеет битов RX/TX/SETUP, а напрямую бит CTR в регистре ISTR не снимается. Это делается только через снятие битов RX/TX/SETUP у конечной точки. Если игнорировать ситуацию, обработчик прерываний постоянно вызывается, пока есть флаг USB_ISTR_CTR.
В цикле проверил другие точки, там есть те, у которых данные биты установлены. Обработка таких точек со снятием RX/TX/SETUP решило проблему с флагом USB_ISTR_CTR, однако уткнулся во вторую проблему.
2. Решив костыльно проблему-1, получил запуск обработки RX (от хоста к устройству) для Data-точки (ID=1), однако, читаю RX-регистр этой точки и вижу там значение: 0x84c4.
Согласно документации:
- 0x84 относится к размеру буфера и соответствует 64 байт (это то, что я сам указал).
- 0xc4 - это размер данных = 196 байт, т.е. получается исходно некорректное значение.
Пробовал уменьшать размер буфера до 32 байт, верхний байт RX-буфера меняется корректно, а нижний остаётся 0xc4.
Подозреваю, что это всё ещё следствие первой проблемы. А первая проблема - следствие ещё более ранне ошибки. Только вот уже перестал понимать, в какую сторону копать. ИИ вообще на серьёзных щах утверждает, что проблема-1 - это вообще стандартная ситуация и её именно так надо решать, и что мол об этом даже ST говорит. Но таких утверждений от ST я не нашёл в интернетах, а в Middleware никаких подобных костылей тоже нет.
Конкретно чип stm32g474ceu6
Необходимо реализовать CDC (Serial Com)
В качестве базиса взял Middleware библитеку от ST, хоть там и крайне сложно разобраться из-за многочисленных переходов между разными модулями (HAL, LL, PCD и т.д.). Так же долго курил Reference Manual от ST и Документацию по USB протоколу в разных нарезках.
Первая проблема, с которой столкнулся: нигде нет рекомендованного процесса обработки запросов от хоста к устройству. С дебагом тоже сложно, т.к. таймауты на ответы очень маленькие.
Чего добился в своих изысканиях - полностью проходит инициализация:
- все дескрипторы пересылаются
- в списке USB устройств на хосте устройство появляется с нужными описаниями
- serial-порт в системе есть
- при подключении к serial-порту проходят стадии CDC_SET_CONTROL_LINE_STATE и CDC_SET_LINE_CODING, параметры передачи получаю
Т.к. я делал на базе Middleware от ST, двойную буферизацию не использовал, применены две доп точки:
- ID=1 - Data = Bulk-type, in/out, размер буфера 64 байта
- ID=2 - Notify = interrupt, 8 байт, передача только в сторону хоста.
Но вот при попытке передачи данных начались проблемы. Отправку в сторону хоста вообще не понял, как отладить.
При отправке с хоста на устройство возникли две проблемы, пояснения по которым и прошу от гуру:
1. Прерывание USB_ISTR_CTR возникает, но получается ситуация, когда указанная в ISTR конечная точка точка в своём регистре не имеет битов RX/TX/SETUP, а напрямую бит CTR в регистре ISTR не снимается. Это делается только через снятие битов RX/TX/SETUP у конечной точки. Если игнорировать ситуацию, обработчик прерываний постоянно вызывается, пока есть флаг USB_ISTR_CTR.
В цикле проверил другие точки, там есть те, у которых данные биты установлены. Обработка таких точек со снятием RX/TX/SETUP решило проблему с флагом USB_ISTR_CTR, однако уткнулся во вторую проблему.
2. Решив костыльно проблему-1, получил запуск обработки RX (от хоста к устройству) для Data-точки (ID=1), однако, читаю RX-регистр этой точки и вижу там значение: 0x84c4.
Согласно документации:
- 0x84 относится к размеру буфера и соответствует 64 байт (это то, что я сам указал).
- 0xc4 - это размер данных = 196 байт, т.е. получается исходно некорректное значение.
Пробовал уменьшать размер буфера до 32 байт, верхний байт RX-буфера меняется корректно, а нижний остаётся 0xc4.
Подозреваю, что это всё ещё следствие первой проблемы. А первая проблема - следствие ещё более ранне ошибки. Только вот уже перестал понимать, в какую сторону копать. ИИ вообще на серьёзных щах утверждает, что проблема-1 - это вообще стандартная ситуация и её именно так надо решать, и что мол об этом даже ST говорит. Но таких утверждений от ST я не нашёл в интернетах, а в Middleware никаких подобных костылей тоже нет.
Аппаратный сниффер есть и у меня. Но если бы он помогал в отладке своего USB-стека - я бы свой сниффер не писал бы.
Далеко не каждую болезнь можно победить не заглядывая внутрь больного. Чаще всего необходимо на внутренние 