2023-07-13 04:20 PM
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,
Moreto
Solved! Go to Solution.
2023-08-18 01:55 AM
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
Regards,
2023-07-14 02:06 AM - edited 2023-07-14 02:08 AM
2023-07-21 03:46 AM
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 ??
Regards.
2023-07-24 07:25 AM
Hello @mohamed.ayed , thanks!
The target is a STM32F401RE (from a Nucleo F401RE board) with an external circuit that I build back in 2014 (http://moretosprojects.blogspot.com/2014/12/stm32f4-usb-host-and-device.html)
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))
to:
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)
to:
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 https://github.com/rogerallen/stm32disc_midisynth1 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!
Moreto
2023-07-24 06:52 PM
If necessary, here is the USB descriptor of my device: https://gist.github.com/miguelmoreto/d1ffd3b25cc04b69ac2a0120e4fc3e24
2023-08-18 01:55 AM
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
Regards,
2024-06-16 02:01 PM
Just to give you an update: with these changes I've made to the code, the STM32 USB HOST is able to communicate with the MIDI device. I just tested it with a simpler MIDI device: I used my smartphone with an app that emulates a MIDI keyboard. The STM32 USB HOST correctly recognized my smartphone as a MIDI device. The communication problem occurs when I connect my guitar pedalboard (NUX MG30). This is a much more complex USB device, with several audio interfaces in addition to MIDI. So I think the problem is something more specific to this device.
But since I ended up making changes to my project, I'm no longer using USB HOST, so I'm no longer looking for a solution to get my STM32 to communicate with the pedalboard via MIDI.
Best regards,
Moreto