STM32f407 & USB HOST работа через хаб, Отключается USB порт при запросах через хаб LS устройств Опции

[alecsvg]

Я использую плату 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

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

[alecsvg]

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"

[Alechek]

Мда, печаль... Значит и у 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.