Допиливаю проект в Cube, возникла необходимость в двух IN Endpoint. В исходном проекте CDC было по одной IN и Out Endpoint и некая Command. В общем добавил я в дескрипторы еще одну IN Endpoint (0x83), прописал ее в USBD_CDC_Init и для проверки изменил USBD_CDC_TransmitPacket (при вызове USBD_LL_Transmit вместо CDC_IN_EP - 0x83). Данные от новой EP не приходят. Подскажите, в какую сторону копать?

может в сторону того что CDC предполагает
одну контрольную и две интерапт (передающую и опционно приемную) конечные точки и все?

я поле класса изменил в дескрипторе

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

странно что такое устройство вообще не выкинуло из системы...

так он есть

То есть вы сделали железо со своим VID&PID?
Написали сами драйвер, который поддерживает инициализацию вашего устройства
и обмен со всеми конечными точками?
А в железо запросы на транзакцию по USB для вашей EP приходят?
USB-device сам ничего не передаёт - только по запросу от хоста.

драйвер не я написал, в остальном все верно
приложил скрин неудачной передачи (сверху) и удачной из USBTrace. 0x81 - сгенерированная кубом ЕР, 0х83 - мною созданная

а тот кто писал драйвер в курсе новой конечной точки то, может он чего накосячил?

программу верхнего уровня правлю я, как мне нужно. а что, судя по скрину что-то не так на верхнем уровне?

что то не понимаю как на верхнем уровне заставить хост опрашивать еще одну конечную точку?

хостом управляет драйвер, вроде как....

не еще одну, а другую (вместо 0x81 - 0x83).

А!!!! то есть сменили номер.
А контроллер USB это позволяет? У STM какие-то корявые самодельные контроллеры USB, может это он не может?

что значит позволяет? в доке написано 5 IN и 5 OUT Endpoints

могут ли они идти не подряд?
то есть можно ли использовать 83 точку, если 81 не используется?