H750 USB Host enumeration after reset

[Peaga]

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!

[FBL]

Hi @Peaga 

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

[Peaga]

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...

[FBL]

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) 

[Peaga]

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!

[FBL]

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!

[Peaga]

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

 

Thanks!

[Peaga]

Hello @FBL 

 

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

 

Thanks!