Skip to main content
Visitor II
August 7, 2020
Question

Having trouble getting USB3300 to work with STM32F407

  • August 7, 2020
  • 12 replies
  • 5204 views

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.

    This topic has been closed for replies.

    12 replies

    KK.2Author
    Visitor II
    August 19, 2020

    Got a 24M crystal, swapped out the 25M one, changed the clocks so the HSE is passed trough aaand... Now I cant even get it to detect on Full Speed. Back to square one I guess.

    Edit: Actually that was my fault, its the same behaviour as before now.

    KK.2Author
    Visitor II
    August 19, 2020

    I'm slowly running out of things to try. Connected the 60MHz clkout line from the PHY to the STM with a jumper and cut the trace to prevent any possible crosstalk from that line, same result

    I cut the only trace which goes across the board pretty much (ULPI data 7, because for whatever reason 0-6 are on the same side of the STM chip while 7 is on the complete opposite) and connected it with a jumper instead, same result

    I painstakingly botched on a 24MHz crystal onto the PHY with its caps and resistor, same result.

    Starting to wonder if all this time I've looked for a hardware bug while its just STM's implementation thats faulty. I also have a second board which confirmed that its not down to some broken component (Same problem)