Showing results for 
Search instead for 
Did you mean: 

Getting stuck with USBH_BUSY in the USBH_Process() function for USB Host MSC Project

Associate II


I have been working with an STM32F429ZI Nucleo, trying to connect a USB thumb drive, to update the user application firmware. I have started with the MSC_Standalone project as it exists as an example for the F429ZI and I have been integrating relevant files from a firmware upgrade project (FWupgrade_Standalone) available for other controllers. I have not been using the Adafruit TFT shield, which the example relies on, and have removed/modified code related to it.


From my while(1) loop in main.c I'm calling the USBH_Process() function in the usbh_core.c file, and I am getting stuck with USBH_BUSY in the HOST_CLASS_REQUEST case. I followed the function calls down through the layers, and have found while debugging in the USBH_HandleControl() function (in file usbh_ctlreq.c) that the condition required (URB_Status == USBH_URB_DONE) to set the status to USBH_OK is true, yet it never enters the conditional code to set the status to USBH_OK.

URB_Status = USBH_LL_GetURBState(phost , phost->Control.pipe_out);

  if (URB_Status == USBH_URB_DONE)


   status = USBH_OK;

   phost->Control.state = CTRL_COMPLETE;


And so my usb host never reaches the HOST_CLASS case which I need to start any downloading function.

Does anyone know something I could try, or what I might be doing wrong?


> the condition required (URB_Status == USBH_URB_DONE) to set the status to USBH_OK is true, yet it never enters the conditional code to set the status to USBH_OK.

There's something rotten then. Try to single-step in disasm and observe registers/variables. Make the relevant variables volatile, recompile and observe.


Associate II


I`m also stuck in the same USBH_Process() function, but for USB host HID. I am trying to connect a USB keyboard to my own designed stm32f407zgt6 board, code generated with STM32CubeMX v5.2.1 with package software v1.24.2 and I work with IAR IDE v8. I`ve made a project just same as (, but with different pins pack, every time I connect the keyboard the mcu gets the descriptors, but it never gets data from keyboard. I only used one keyboard model, also searched a lot about the problem. I`ve tried what pavel.a said in (, nothing changed, when I printf() the logs on uart, at first I get:

0693W00000BZsMjQAL.pngafter some "HOST_ENUMERATION"s it recognizes keyboard:

0693W00000BZsMGQA1.pngand at last the process goes on like the:

0693W00000BZsNhQAL.pngfor ever "HOST_CLASS..." from USBH_Process() fuction in usbh_core.c and then "HID_GET_DATA" from USBH_HID_Process() function in usbh_hid.c.

Some place in USBH_HID_Process() function in the "HID_GET_DATA:" part of the switch_case, there is a line "HID_Handle->state = HID_POLL;", but right after this line the "HID_Handle->state" equals to "HID_GET_DATA" (see the forth picture) again very automatically.

0693W00000BZsSYQA1.pngSomebody please tell me whats going on here? I`ve also seen from my searchs that there would be a problem with boot type and request type of keyboards.


By HKrnr

Hi, a solution that worked in my case has been found on a similar topic. It appears the issue occurs on the row 561 of usb_ctrlreq.c, which you can replace with the following :

ep_descriptor->wMaxPacketSize |= MIN((uint16_t)(LE16(buf + 4) & 0x7FFU), (uint16_t)USBH_MAX_DATA_BUFFER);

As a new member I cannot share links, so the original topic is : FatFs_USBDisk example with USB_FS does not work. When an USB Stick is connected the USBH_MSC_Process never gets further then MSC_READ_INQUIRY. Any hints? , created by MMenz.1 on the 6th of July 2022, 2:36 AM



I had this problem and solved it by setting the USB clock frequency to 48MHz. In application note AN4879, section 2.4 Clock, it mentions that the USB needs a precise 48MHz clock. I looked at the clock section of the ioc interface of STM32CubeIDE and noticed the USB clock was set to 24MHz. I changed to clock settings to get 48MHz and the USB started working fine.

This might not be your problem, but it is worth taking a look at.