[Solved] Having Trouble getting USB to work (custom PCB, STM32 / USB3300 PHY) - Page 1
Forum section: electronics / projects

author: Kinsi
author_rank: Contributor
timestamp: August 19, 2020, 10:52:38 pm
content: Hello,I've designed a custom PCB which I ordered from / got assembled by JLCPCB - luckily it seems like I made no major issues on the first attempt, however no matter what I try, I just cant get the USB link to work properly. My MCU is the STM32F407 and the usb PHY is the USB3300, attached is a picture of my (simplified, all parts that are unrelated and inactive while testing are removed) board. If some line seems to be routed in a weird fashion its probably because some other trace prevented it from being done in a better fashion.Considerations: The USB3300 exists as a breakout board (https://www.waveshare.com/usb3300-usb-hs-board.htm), thus I've assumed signal integrity is basically not going to be an issue for me to a point where it is going to make things break.My issue is basically that, when configuring the PHY as Full Speed the device will be detected but basically "crashes" once I actually try to use it, suggesting that something corrupts. Trying High Speed I cannot get the device to be detected at all.As mentioned in this STM doc on Page 173, I've used the MCO of the STM to clock the PHY:https://datasheet.lcsc.com/szlcsc/STMicroelectronics-STM32F407VGT6_C12345.pdfAfter having initially ordered my board with a 25MHz crystal I spotted that the page mentioned above explicitly states the STM's input crystal should be 24 or 26 MHz, so I swapped it for a 24MHz one and passed trough the HSE clock instead of going trough the PLL, which made no difference.Thinking that maybe somehow crosstalk of the 60MHz clockout line causes issues I've cut that trace and connected it with a jumper wire which made no difference. Additonally I did the same with the ULPI7 dataline which also made no difference (Why they decided to have one of the 8 lines be on the complete opposite side of the chip, I dont know).The last thing I've tried is disabling the MCO of the STM and instead directly soldering on a Crystal with its caps and resistor onto the PHY which lead to the exact same result.I am using STM32CubeMX with the latest libs and generate a pretty much bog standard empty project with nothing else configured other than the USB interface - The USB3300 has to be compatible with my MCU as one of the demo code packages of the breakout boards is for my exact chip model, however I cannot give that example code a try as I have no idea what tooling I need to try to compile it.At this point I am pretty much out of ideas to try, so if somebody has any experience in this field / experienced a similar issue before and can suggest something to try that would be much appreciated. Thank you in advance!

author: TK
author_rank: Super Contributor
timestamp: August 19, 2020, 11:43:28 pm
content: you need to get a USB 2.0 protocol analyzer like the ITIC 1480A, Beagle 480 or LeCroy 10K with US006MA module. Any of these analyzers will give you a hint of what is happening. I got the LeCroy for around $300 on eBay, it is old but software works in Win 10. The ITIC 1480A is around $700 but also can be purchased used for around $400. The Beagle 480 is $1100 new and I saw one for $600 on eBay but it sold.You need any of these hardware low level analyzers, not a higher level sniffer like wireshark.I think it is impossible to test signal integrity with hobby level scopes, you need at least 1GHz with active probes.

author: Kinsi
author_rank: Contributor
timestamp: August 20, 2020, 12:46:26 am
content: While I am not surprised by the cost of such equipment it is certainly way beyond what I can spend on this as it will probably never be anything more than a personal project.That being said, I have a logic16 compatible device(100M sample rate), and since I am already experiencing issues with just Full Speed that is something I can analyze.Attached is a resulting capture of me plugging in my board, getting an error from Windows (Failed to get device descriptor), replugging, it being recognized as a HID device with the correct name etc but there still being an exclamation mark on the device. I guess the thing that pops out the most are the unexpected packets.The txt is the summary and the csv is the raw list of control transfers. Hopefully that is of use to be able to spot something, unfortunately my knowledge of how USB works under the hood is pretty much non existent.Edit:Actually I just tried to capture another STM ("Blue Pill") board that I have around where the onboard PHY is used, there I also get some unexpected packets, so I guess that doesnt really mean anything.

author: ataradov
author_rank: Super Contributor
timestamp: August 20, 2020, 02:43:21 am
content: Can you share the schematic of the USB3300 part?USB3300 is very easy to use in my experience. I've made a board with USB3300 and FPGA and I had it working with my own USB device IP without any issues. I did not even need USB analyzer to design make that IP.

author: Kinsi
author_rank: Contributor
timestamp: August 20, 2020, 02:57:53 am
content: Sure, "USB_STM_CLK" is the MCO output from the STM32, the rest is self explanatory and connected to the corresponding pins of the STM MCUBased off the fact that itsomewhatworks makes me strongly believe that my basic setup has to be correct and its either down to some bug in the Middleware / Driver implementation of the ST Boilerplate code, or some signal integrity issues, hence me sharing my pcb layout in the entry post.

author: ataradov
author_rank: Super Contributor
timestamp: August 20, 2020, 03:05:21 am
content: C14 is 4.7 nF. It must be 4.7 uF.Other than this, I would double check that 24 MHz clock is actually 24 MHz and has no excessive jitter and generally looks clean.

author: Kinsi
author_rank: Contributor
timestamp: August 20, 2020, 03:15:38 am
content: As mentioned above, thinking that clock stability might be my issue, I have had attempted cutting the MCO trace and instead directly botching on a Crystal onto the PHY which gave me the exact same behaviour, unfortunately I dont have a scope so I cannot really check the stability of it beyond that.Regarding the cap, you're right, seems like I missed that. I'll try to replace it. If that should actually be the reason for all my problems I'll lose my mind.

author: Kinsi
author_rank: Contributor
timestamp: August 20, 2020, 03:45:02 am
content: Well... This was harder than it needed to be. Added a 47uF cap in parallel as a test (As thats the best I have around) and guess what, the device is detected in HS mode and doesnt crash. Out of anything this was the last thing I would've expected. Much thanks!I'll do some more tests to see if the communication actually works but for now this is for the first time a different result than anything I've seen before.Edit:Done some basic tests, everything seems to work fine. What an unfortunate mistake. Thank you again.