Я использую плату stm32f4discovery в режиме FS_HOST из библиотеки HAL V1.4.3 11-12-2015
Через FS хаб к хосту присоединена LS мышь. (Все FS мыши работают)
Проблема возникает при чтении дескриптора мыши, когда начинают использоваться PREamble пакеты. Иногда после запроса процедуры USB_OTG_HC_StartXfer () к мыши происходит запрет порта usb. Попытка привязать отправку сразу после SOF была неудачной, подача внешнего питания 5V на плату также не дало результата.
Для дальнейшей работы требуется повторная инициализация ядра USB .
Это происходит не всегда, но достаточно часто.
Нашел схожую проблему в интернете.
Состояние регистра OTG_FS_HPRT:
PENCHNG:0 -Port enable/disable change
PENA: 0 -: Port disabled
PCSTS: 1 -device is attached to the port,
PSPD- port speed full speed)
Состояние 4 канала по которому происходила транзакция в регистре OTG_FS_HCCHAR0:
CHENA: 1 сhannel enable,
CHDIS: 1 Channel disable,
EPTYP: 0 Endpoint type Control,
LSDEV: -1 Low-speed device.
Регистр OTG_FS_HCINT0 : FRMOR: 0 frame overrun,
BBERR: 0 no babble error,
TXERR: 1 - Transaction error ( CRC check failure,Timeout, bit stuff error, false EOP)

Удачное чтение
https://drive.google.com/file/d/0B9XPN6lpRZ...iew?usp=sharing

Неудачное чтение
https://drive.google.com/file/d/0B9XPN6lpRZ...iew?usp=sharing

Состояние регистров
https://drive.google.com/file/d/0B9XPN6lpRZ...iew?usp=sharing

Пока не знаю как побороть эту проблему.

Но все же! А как рассмотреть/увеличить вложенные изображения подобные тем, что в данной теме? До сих пор не понял. ТС вложил изображения здесь, а толк какой если ничего не видно?

К сожалению, при загрузке сжалось.
Исправил.
Но вкратце на этих картинках анализатор показывает нормальное прохождение пакетов чтения дескриптора LS устройства, с preamble пакетами перед каждой транзакцией, а при новом чтении дескриптора появляется пакет preamble и на этом всё заканчивается.
Ну а проце возникает прерывание от изменения статуса порта. Порт запрещен и установлен бит TXERR по тому каналу, где шла передача. Почему возник запрет порта мне непонятно. Ошибка TXERR иногда бывает, но она не должно приводит к запрету usb порта. Питание в норме, анализатор показывает, что дисконнекта не было. В какое-то неудачное время попадает пакет preamble(0x3С).

Не работал через ХАБ, но имею версию: а не такая же ли это проблема, как и на LPC:
https://www.lpcware.com/content/blog/soluti...ble-bit-problem
Этот самый бит, насколько я помню, может возникнуть только если работа через хаб.

Хорошая мысль. Я уже смотрел в сторону lpc1768/69, errdata огорчила. В моем случае, наверное, не из-за этого. Так как запрет usb порта присходит на стадии начала отправки данных. В lpc, имхо, при приеме данных от хаба. Но всё равно спасибо за предположение,
с lpc хоть немного познакомился.

STM support answer about my problem with the USB stack:

"SOLUTION PROPOSED BY SUPPORTER - 10/5/2016 13:21:20 : ---------------------------------------------------------------------------------
There is an issue in our OTG implementation, there should be published an errata on this point long ago, but so far it is not.
The problem is present on your device.
Problem description: When you connect low-speed device to full-speed HUB there is a problem in switching between full-speed / low-speed communication on OTG side and from time to time the communication is stuck. The only current solution is to reset OTG peripheral.
Sorry I don't have a better resolution.
Best of luck with your design,
ST Online MCU Support"

Мда, печаль... Значит и у STM не все так гладко.
Особенно "порадовала" строчка:
>> There is an issue in our OTG implementation, there should be published an errata on this point long ago, but so far it is not.

Проверил STM32F446 и STM32F746 на NUCLEO, те же проблемы.
Если забыть о производительности и причесать стек, то вроде ( пока на тестировании) работать можно.
Знаю, что у китайцев выпущен рабочий usb extender на stm.