STM32F4 Use HSI for USB Clock

[JBret.1]

I want to use STM32F413 for my PCB design. I need USB data lines for communicating with a computer. Ideally, I would not have any oscillator on the PCB to save space. I noticed that's it's not possible to use HSI for the USB clock on CubeMX. Can I use pin PA8 as MCO to output HSI and route it to PH0 ? This way HSI and HSE are connected though the PCB. On CubeMX it seems possible, however, I don't know if it can work in reality. Are there some consideration hat I need to take to ensure this will work? Here are some screenshots of the CubeMX configuration and PCB schematic. Thanks

 

[TDK]

If you want to use HSI, you can do so without re-routing it to PH0, and doing so isn't going to increase accuracy even if the chip is technically in "HSE bypass" mode.

HSI won't meet the accuracy requirements of USB and may or may not work, depending on your specific chip, ambient temperature, trimming values, etc. There are some chips that can use HSI along with the clock recovery system (CRS) to manage crystal-less USB, but the STM32F4 is not one of them.

[Tesla DeLorean]

The limitation here is one enforced by CubeMX, you can just EDIT THE CODE

The real world consequence however is that you probably won't be able to meet USB compliance testing as you're using a clock whose accuracy doesn't meet requirements, and you might encounter systems/conditions where your device will not function properly.

For a commercial product, you should discuss the ramifications with your front-line support staff, so they don't come lynch you later.

[JBret.1]

When I select HSI as PLL clock source on "Clock Configuration" it gives me an error, so I assume it is not possible to route HSI to the PLL internally, that's why I'm trying to do it externally.

[TDK]

> When I select HSI as PLL clock source on "Clock Configuration" it gives me an error,

I don't see any errors shown in your screenshot. I do see that the system clock is using HSI and not PLLCLK. You'll need to select PLLCLK to use the PLL for the system clock.

[JBret.1]

What accuracy problems and malfunction should I expect to encounter? I'm routing my USB lines with width and spacing the ensure I have 90 ohms differential impedance. The device will only be used at room temperature. The USB baud rate will be 115200. Thanks!

[JBret.1]

The pink square around HSI on PLL Source MUX is an error and the code cannot be generated. Even when I select PLLCLK from the System Clock Mux the error is still there. As @Community member​  said, it's probably a CubeMX limitation and it can be modified by code.

[TDK]

I recreated this. In this case, the error is "PLL Mux should have HSE as an input". Which is because you're trying to use USB. Disable USB and the error message disappears. Not sure I'd call an intentional feature a software limitation. There are many limitations of CubeMX, but this is not one of them.

Your workaround might remove the error message from within CubeMX, but it won't solve the underlying problem that HSI is not accurate enough for USB.

[Pavel A.]

If STM32 is in device role, some models can use the host (PC) SOF signals to synchronise.

These models can run on the internal oscillator. But this won't help with other interfaces such as UARTs.

-- pa

[Tesla DeLorean · Accepted solution]

Well the data you're sending might be at 115200, but the bus data is working at 12 MHz, and the clocks at each end need to be reasonably synchronized so the packets are recognized and remain intact across the link. The USB specification dictates that the host controller must send a SOF packet at a rate of 12 MHz ±500 ppm (parts per million), that is, 12 MHz ±0.05%

The HSI is hugely unstable, both in the short and long terms, and has a wide range. Figure packet loss, random disconnection, failure to connect, general link reliability issue. Can't put USB logos on product, on meet certification requirements. Maker applications, perhaps who cares, commercial applications, likely to increase support calls and costs, as well as reputational cost.