Showing results for 
Search instead for 
Did you mean: 

Re: USB HOST cannot parse the last EndPoint

Associate II

Dear A.Ziru,

Apparently I'm having the same problem as you when trying to receive MIDI data from a USB device (in this case it's a guitar multi-effects pedalboard). How did you solve the problem? Where and how did you defined that MIDI class descriptor?

In my case, the USBH lig gets stuck in this while loop:

while ((ep_ix < pif->bNumEndpoints) && (ptr < cfg_desc->wTotalLength))

I seems that the function inside the while loop:

pdesc = USBH_GetNextDesc((uint8_t *)(void *)pdesc, &ptr);

never increments the pointers to the end values.

I still need to study more the descriptors and the types of intefaces to better understand what is happening.

I would appreciate if you could indicate the path you followed to solve the problem.

Best regards,



This post has been separated from this old thread started by @A.Ziru .


ST Employee

Hi @moreto and welcome to our community, 

please can you specify which STM32 target and which middleware version are you using, and how to reproduce this issue ?? 





Hello @mohamed.ayed , thanks!

The target is a STM32F401RE (from a Nucleo F401RE board) with an external circuit that I build back in 2014 (

The the middleware if from the latest firmware version (I think): V1.27.1

I would like to mention that I have already found the cause of the problem reported in my question. But I still could not make my host communicate with the device.

I verified two problems in the USB Host library regarding a device with a complex descriptor, as is my case (a NUX MG-30 guitar pedal).

1) The MIDI interface endpoint (AudioClass subclass 0x03) has 9 bytes. But the USB HOST library only does this check for subclasses 0x01 and 0x02.

I changed line 470 of the usbh_ctlreq.c file (in function USBH_ParseCfgDesc)  from:

if ((pif->bInterfaceClass == 0x01U) && (pif->bInterfaceSubClass == 0x02U))


if ((pif->bInterfaceClass == 0x01U) && ((pif->bInterfaceSubClass == 0x02U) || (pif->bInterfaceSubClass == 0x03U)))

2) The second problem has to do with the total number of interfaces on the device. In my case, the descriptor indicates 4 interfaces. But two of them are dual audio interfaces that the device counts as only one. However the USB HOST library does not take this into account, resulting in 6 interfaces in my case (from 0 to 5). The MIDI interface is number 5. Therefore the USBH_FindInterface function returns the number 5 for the MIDI interface, which generated a non-existent interface error (because in the descriptor the maximum number of interfaces is 4).

I solved this by modifying the USBH_SelectInterface function.
I changed line 300 from:

if (interface < phost->device.CfgDesc.bNumInterfaces)


if (interface < USBH_MAX_NUM_INTERFACES)

I don't know if this is the best solution, but it worked.

With these modifications and with the inclusion of the MIDI Class functions from the USB HOST library enumerated and detected the device correctly.

The problem now is that even though I periodically call the USBH_MIDI_Receive function (after the application state is APPLICATION_READY), I get nothing from the device. It seems that my device "does not understand" the host request. The state machine is continuously waiting for the device's response.
I need to dig a little deeper to better understand what is going on. I am not able to find out, through debug, exactly which bytes the host sends to be able to compare with the data packet sent by the PC (which I was able to get using a USB sniffer).

If anyone can point me in the right direction to check which bytes the host sends to the device, I would appreciate it!

Best regards!


If necessary, here is the USB descriptor of my device:

ST Employee

Hello moreto,

Just to let you know that the fix of parsing midi interface endpoints is already part of latest host library available under github stm32_mw_usb_host/Core/Src/usbh_ctlreq.c at master · STMicroelectronics/stm32_mw_usb_host · GitHub