STM32F722: USB_OTG_HS interface used in FS Mode doesn't work.

[Mateusz Mróz]

Hi!

I'm trying to get STM32F722RE USB_OTG_HS to work with internal phy as Full Speed device. No matter what I'm doing, configuring it through CubeMX, I can't get anything to show up in OS device manager. Already struggled with same problem ~1 year ago and gave up on it until today.

I've been using similar configuration with F429 on Discovery board and it worked fine, so I tried to move it to F722, saving important pins needed for OTG_FS.

Hardware is fine & triple checked, PB14 (Pin 35), D- wired to Micro-B Pin 2 and PB15 (Pin 36), D+ wired to Micro-B Pin 3 and VBUS on PB13.

Nothing found in Errata, nothing special in USB application note.

Do anyone got HS interface to work in FS mode on this MCU? Is anyone aware of some simple bug fix?

I'm close to give up on this thing totally... as i also found that there is no bootloader mode with HS using BOOT0 ( I'd probably implement my own bootloader If i didn't loose all the hope on HS), but I'm affraid that this is some obvious bug, as it USB always worked fine for me "out-of-the-box" with CubeMX and it is the first time it didn't, and after so much time after releasing F7s, there is no coverage on it?

[STOne-32]

@Imen DAHMEN​ 

[Imen.D]

Hello @Mateusz​ ,

We will check this issue and come back to you soon with update.

Best Regards,

Imen

[waclawek.jan]

> I can't get anything to show up in OS device manager.

Debug as usually. Start with clocks, move to the basic OTG registers.

https://community.st.com/s/question/0D50X0000Beaan4SQA/trying-to-get-usb-device-working

JW

[Mateusz Mróz]

Found a solution!

I've already tried basic debugging before, but JW motivated me to at least dig and find the function which maybe stucks (thanks!).

So, no matter what configuration and combination, Host, Device, any class or no-class, I wouldn't go past the USB_CoreReset() funtion in CoreInit().

The CSRST bit in GRSTCTL register was set, but didn't clear by itself and the function always timed out.

As register operations before the core reset seemed fine, i was fighting a little with init structure fields, but then I figured out, that none of them matter, until the core is reset.

Then in HAL_PCD_MspInit() function, generated by MX, i've found that there are 2 clocks enabled instead of 1:

(...)
HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);
 
/* Peripheral clock enable */
 __HAL_RCC_USB_OTG_HS_CLK_ENABLE();
 __HAL_RCC_USB_OTG_HS_ULPI_CLK_ENABLE(); <--- ????
 /* USER CODE BEGIN USB_OTG_HS_MspInit 1 */
(...)

At first, i've left it default as i thought it's needed or doesn't matter, but when i commented 6. line above, everything started to work fine.

That's the fix, just remove: __HAL_RCC_USB_OTG_HS_ULPI_CLK_ENABLE();

I feel a fool right now, cause i have no idea, why i didn't dig a little deeper to find it earlier (laziness?) ... seems so easy and obvious now.

Anyway, I hope to get it fixed in next MX releases, so no one get stucked on this anymore =)

[Imen.D]

Hello @Mateusz​ 

Thanks for highlighting this issue.

After check, we confirm this issue and it will be fixed on the next release of STM32CubeMX.

Best Regards,

Imen