Can someone explain me how USB HS is clocked, when using embedded PHY?
From the same 48MHz clock than USB_FS.
Hi,Thanks for the reply.Strange, currently I'm run stm32f437 at 180MHz and 48MHz clock is actually 51.2MHz, but USB is working, probably out of the specifications.
Strange, currently I'm run stm32f437 at 180MHz
Are you sure? Did you measure it?
Some of the F4 parts have an RCC_DCKCFGR2 (F410,412,413,423,446) which can do some alternate clock/pll routing including the "PLL48" source and SDIO
I didn't measure it with oscilloscope, but I'm sure what values set for the PLL.Actually communication have some problems and strange behaviour. Just for my curiosity, I tested and with 45MHz clock,it still enumerate, but not every time. With lower clock, device recognition fails.
Just for my curiosity, I tested and with 45MHz clock, it still enumerate, but not every time.
Drilling down the USB standard might reveal the calculation behind the required clock precision. It surely assumes worst cases such as both parties imprecise in the opposing direction and longest possible packets, indicated also by the severely relaxed clock precision requirement for low-speed devices (1.5% for LS as compared to 0.25% for FS and 0.05% for HS) allowing to run them from ceramic oscillators rather than crystals (the former being cheaper significantly enough, by the end of past century), and enumeration is an example of such short-packets. So, working against a precise counterpart through almost perfect hardware connection, the marginal working with cca 6-7% is not shocking, but somewhat surprising nonetheless.
Unfortunately, in the 'F437 there's no practical option to decouple the 48MHz clock from the system clock (unless you want to run the latter painfully slow). Least common multiple of 180 and 48 is 720 and he PLL can't go that high; so there's no way you can use USB and run the SYSCLK at 180MHz.
Thanks for your help waclawek.jan, I will stick to 168MHz for sure.
Retrieving data ...