STM32H5 USB PHY not working (no interrupts) using PLL2Q as clock source

[GCRev]

I'm working on a project with the STM32H503CBU7 which requires USB. I have a 32MHz external crystal on my board that appears to be stable. The chip works and can be programmed and such. I also troubleshot out other physical issues like cold joints and shorts because that has burned me before when the USB device fails to enumerate.

My intent was to use the PLL2Q source with the USB peripheral so I could also specify a 200MHz sys clock for everything else via PLL1. When I use the PLL2Q source however,  I get no interrupts from the `USB_DRD_FS_IRQHandler` handler and so my USB stack does not operate.

To make things more confusing, it also does not work even when both PLL's have the same values set for all parameters, as shown in the image below.

It is important to note that this works with the PLL1Q source, as it is shown in the image, and I'm currently compromising a little on the sys clock speed. It will work for my purposes, but I'm more interested to know whether there's some "magic bullet" setting I'm missing, or if this could be a known configuration limitation.

The generated code in my `main.c` file that configures the peripheral clocks seemed to be okay, so I don't think it is a code auto-gen issue, but I could also be wrong about that.

I have already tried this on two chips because I thought there could be something wrong with the first, but they both exhibit this behavior.

[TDK]

For clarity, you said the configuration in the screenshot works, yes?

But if you change the radio button from PLL1Q to PLL2Q without changing anything else, it no longer works?

Shouldn't be a magic setting anywhere. Does it fail to enumerate? If you debug your code, does it make it past initialization and through MX_USB_Init okay?

[gbm]

Check what happens if you set the USB clock to HSI48 synchronized to USB SOF - this configuration must work regardless of main oscillator failure/malfunction. Once this works, verify the HSE. It may oscillate at some sub-harmonic of its nominal frequency.

[GCRev]

Yes, that's the confusing part: both PLLs based off the HSE with the same MHz configured, but with PLL2Q no interrupts are triggered whereas PLL1Q they are.

By "fails to enumerate" are you referring to the USB device on the host machine, or -- pardon my lack of knowledge, I'm pretty green in embedded dev -- some other type of internal enumeration like a register that contains information about whether that PLL is operating correctly?

To answer the first case if so: the host can enumerate it with PLL1Q selected, and not with PLL2Q selected. To also answer part of @gbm's question, it also enumerates on the host with the HSI48 source.

I've ordered some different caps to try tuning my oscillator, which is a 9pf. I've assumed a 4 pf stray capacitance so I've used 10pf load caps. But I'll check with 9pf load caps and 8pf load caps as well.

[TDK]

By "fails to enumerate" I mean does the host system register an unknown device in the Device Manager when you connect it? This is what happens when the USB pullup is enabled but the device doesn't respond correctly.

If not, it may not even be getting to the USB initialization code. You should debug your code and find out where execution stops.