The STM32H7RS series includes a USB HS PHY with a special PLL that generates the 480MHz clock required as well as a 60MHz clock for the OTG HS peripheral and optionally a 48MHz clock for the separate OTG FS peripheral. The PLL for the USB PHY has several configuration bitfields in the RCC->CCIPR1 register that are used to set the source of the PLL reference clock, as well as its frequency:
Bits 13:12 USBPHYCSEL[1:0]: USBPHYC kernel clock source selection. Set and reset by software.
00: hse_ker_ck (default after reset)
01: hse_ker_ck / 2
10: pll3_q_ck
11: reserved, the kernel clock is disabled
Bits 11:8 USBREFCKSEL[3:0]: USBPHYC kernel clock frequency selection .Set and reset by software.
This field is used to indicate to the USBPHYC, the frequency of the reference kernel clock provided
to the USBPHYC.
0011: The kernel clock frequency provided to the USBPHYC is 16 MHz
1000: The kernel clock frequency provided to the USBPHYC is 19.2 MHz
1001: The kernel clock frequency provided to the USBPHYC is 20MHz
1010: The kernel clock frequency provided to the USBPHYC is 24 MHz (default after reset)
1110: The kernel clock frequency provided to the USBPHYC is 26 MHz
1011: The kernel clock frequency provided to the USBPHYC is 32 MHz
Within the STM32CubeMX GUI the USBPHYCSEL bits are controlled by a mux selection on the clock configuration tab and the USBREFCKSEL bits are determined by a drop-down menu in the USB OTG HS configuration menu. When generating source code the USBPHYCSEL setting is reflected in the HAL_PCD_MspInit() function, properly setting the PeriphClkInit.UsbPhycClockSelection value.
The problem is that the USBREFCKSEL bits are never changed from the default 24MHz setting even if the drop-down menu in the CubeMX GUI has been correctly set. There is a function for setting them - LL_RCC_SetUSBREFClockSource(uint32_t ClkSource) but it is never called from within either HAL RCC or from within the generated source.
Ideally STM32CubeMX would generate a call to LL_RCC_SetUSBREFClockSource() with the proper argument based on the user setting in the GUI (and the clock configuration tab would include appropriate error checking on this value), or else some warning commentary that the user is responsible for handling this themselves.
