Having trouble getting USB3300 to work with STM32F407

[KK.2]

Hello there,

I've prototyped a custom PCB, but I'm having issues getting USB to work, Windows is unable to read the Device Descriptor.

The IO, from what I understand, is connected correctly and the generated code is (seemingly) successfully able to initialize the PHY, and the PC will only detect it as plugged in once the `USBD_Start` method within `MX_USB_DEVICE_Init` was executed thats generated by CubeMX.

Apart from having configured the Clocks and USB HS / Device (Com port example) it is a blank project

As the 3300 needs a 24MHz clock I've decided to configure it as shown here by using MCO2. My clock configuration looks like this: https://i.imgur.com/lAhx1jD.png

I've tried to simplify it by setting PLLI2S to x120 / 5 and thus have the MCO2 be /1 with no difference.

I've tried to switch to Full Speed over High Speed with no difference.

Any help would be appreciated, thank you.

[TDK]

I don't think there's anything wrong with the clock configuration. Try using USB Monitor Pro and see what is happening on the line.

There are bugs in the USB library that were mitigated by building/running in Debug mode.

[KK.2]

I've downloaded said software now, this is what I get when I unplug and replug the board

Seems like the PHY just doesnt send out the descriptor etc as, after plugging in, theres a delay of a couple seconds before hearing the plugged sound and seeing those messages pop up.

[Pavel A.]

> after plugging in, theres a delay of a couple seconds before hearing the plugged sound and seeing those messages pop up.

IMHO this is not obvious from the log (looking at the START_DEVICE and down). The sound may be delayed.

Try to get a real hardware analyzer.

-- pa

[KK.2]

I can gurantee that the sound isnt just delayed, I've encountered this same behaviour before with USB devices that broke where it takes a couple seconds after pluggin in before something happens. The Device also wont pop up in Windows' Devices and Printers view before hearing that sound / seeing the START_DEVICE event.

I've ordered a Logic analyzer, hopefully that will help me in finding the root cause.

Edit: I have no idea what just happened but somehow while trying to set "USE_HAL_PCD_REGISTER_CALLBACKS" to 1 to see if that makes any difference my device was detected... somewhat... It still was unable to initialize it it seems but at least the Descriptor seemed to have been transferred as it showed up as a COM port called STM32 Virtual ComPort, so I guess this should at least confirm that the electrical connections are correct? I am however unable to repeat this right now.

Edit2: I've also just tried to monitor any hotplugged device instead of specifically selecting the device and that results in a couple more events happening

Edit3: I'm starting to worry that it may or may not be down to me using the clock output by the MCO to drive the PHY like mentioned in the entry post. After reflashing the same binary like 20 times, eventually the device was properly detected and I was able to capture it:

But if the internal crystal of the STM is enough for a stable Full Speed link surely this setup isnt going to be worse than that to a point where Full Speed is unstable.... Right? My Input crystal on the STM is +-10ppm and the PHY requires 500, surely the PLL doesnt add that much noise does it?

[KK.2]

It would seem like the PLL is actually the problem. With the clock configuration of the entry post this is the signal I get out of the MCO pin, captured at 100m. It jumps around between 20 and 25MHz, and that would be the reason why nothing works.

Upon closer inspection, it might make sense. The Datasheet linked in the entry post states that the crystal of the STM should be 24 OR 26 MHz, I wrongly assumed 25 Would be fine, which it clearly is not as the PLL is unable to generate a 24MHz signal from it.

[TDK]

Ehh.... Seems more likely to me that what you're seeing is an artifact of your logic analyzer sampling rate. This is what you'd get with 100 MHz sampling frequency, or 10ns resolution.

The MCO output is divided down from the system clock. Doubt the PLL is that bad.

[KK.2]

I guess my best bet is trying it out. There has to be a reason why the datasheet specifically says 24 or 26 MHz crystal, and with Full Speed being detected somewhat consistently and High Speed being detected almost never, given their different Tolerances, this is the thing that makes the most sense to me.

[Pavel A.]

>  if the internal crystal of the STM is enough for a stable Full Speed link

No, AFAIK it is not stable enough. Better use external crystal, or synchronization from the USB host, if your STM32 model supports this.

-- pa

[KK.2]

I Am using a crystal right now (25M, 10ppm) and trough the PLL output a 24MHz clock to the USB chip, which is listed as a possible configuration in the STM32F4 documentation, however the documentation states that the input crystal should be 24 or 26 MHz, which I had wrongly assumed (I guess) would be flexible to the point where a 25MHz crystal would be fine - so what I would do next is test a 24MHz crystal on the STM and just pass trough the HSE instead of converting it trough the PLL.

[TDK]

What doc says it should be 24 or 26 MHz? That is news to me. Can you cite it more specifically?

[KK.2]

My configuration is equal to the one from the page 173 here where it says 24 or 26 MHz

[TDK]

> How would using the system clock help me?

I don't think I've implied that it would. I'm suggesting that the errors in your program are not due to the PLL and are from something else. You're free to have you own opinions. Best of luck.

[KK.2]

I was just curious, maybe you knew something that I didnt. Thank you regardless. I'll pursue trying to solder on a 24MHz crystal as I honestly dont have any better idea for something that I could try out.