cancel
Showing results for 
Search instead for 
Did you mean: 

H750 USB Host enumeration after reset

Peaga
Senior

Hello!

I'm facing an odd problem with STM32H750VB MCU and the USB Host routine on a custom board. I'm working with the latest HAL (v1.11.2) at 400 MHz and USB using the 48 MHz internal RC, "host only" mode + FatFs "read-only". The software is quite simple: it detects a flash drive, mounts it and try to open a text file. If so, the file is closed, the flash drive is unmonted and then, the board is reset by "HAL_NVIC_SystemReset".

 

The issue lies on this: after the board reboot with the flash drive still connected to the USB, the software detects it but doesn't enumerate it. It waits up to 30 seconds for the enumeration and then, a new reset is triggered, After that, it works! Keeping it cycling, the 1st reset works, the 2nd reset don't, the 3rd reset works, the 4th don't, and so on... Within this 30 seconds waiting, if I remove the flash drive from USB and plug it again, works flawless.

 

Do you guys have any ideia about this behavior? I also tried to "DeInit" the USB host and disabled USB voltage detector before the reset, without success.

 

Thanks a lot!

9 REPLIES 9
FBL
ST Employee

Hi @Peaga 

Would you share a minimum of your code ? You may miss proper de-initialization of the USB host before resetting the board.

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Hello @FBL, thanks for your response.

 

Sure, I can share the code but just to let you know, before calling "HAL_NVIC_SystemReset", I tried to call "MX_FATFS_DeInit", then "MX_USB_HOST_DeInit" and finally "HAL_PWREx_DisableUSBVoltageDetector". Even add a 100 ms delay before the reset...

Hi @Peaga 

Possibly it is because VBUS is not turned off. Instead of MX_USB_HOST_DeInit() I suggest using USBH_ReEnumerate() You can get inspired with the example provided here STM32CubeH7/Projects/STM32H743I-EVAL/Applications/USB_Host/DynamicSwitch_Standalone at d76ccdf6165bdf31d3718ae4722aa23bd15cc582 · STMicroelectronics/STM32CubeH7 (github.com) 

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Hello, @FBL 

 

Thanks, but still, no success. In fact, debbuging the board, the "USBH_Process" state machine is in "HOST_ENUMERATION" step on the first reboot, with "USBH_HandleEnum" function only returning "USBH_BUSY". Going further, the function "USBH_LL_GetURBState" goes from "USBH_URB_IDLE" to "USBH_URB_NOTREADY" (on "CTRL_DATA_IN_WAIT" state). After reboot, the same function goes to "USBH_URB_DONE" at the first shot. Very odd...

Peaga
Senior

Well, I think the problem is solved!

 

On "usbh_ctlreq.c" file, from STM32 USB Host Library, I added an "or" condition for "USBH_URB_NOTREADY" at line 941. So the stack state goes to CTRL_ERROR, not getting stuck on "CTRL_DATA_IN_WAIT" point.

 

I'll keep my eyes on it, hope it doesn't affect anything!

 

Thanks!

Hi @Peaga 

It can mask underlying issues that need to be properly addressed. Since you didn't share your implementation, I could not investigate further and report an issue linked to the MW neither help you to solve your issue properly!

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

@FBL, I will send you the code by private message, ok?

 

Thanks!

Hello again, @FBL 

 

I couldn't attach the file on PM, so I removed some confidential parts and added here. Please note that "toutBoot_1s" variable decreases in a 1 second TIM.

 

Thanks again!

Peaga
Senior

Hello @FBL 

 

Did the code help you to simulate the issue? Do you need anything else?

 

Thanks!