Earlier quoted context omitted.
If you made the PCB then you should be well placed to fix issues with it. You don't need years of experience , you have the schematic. A microscope (if you need it) is 40 USD. A logic analyser is 10 USD. Solder paste and hot air is only for specific parts and that is 30 usd. I am assuming 2 layer - 6 layer PCBs are very specialised (e.g. drones) The reason I'm being snarky is because it feels like you don't know what…
As tomhow points out, you are likely going to need more than just a multimeter. However, the hard part isn't whipping up a board that's 90% of the way there; it's the last 10%. I'm currently on revision ~11 of a hobby project which is far less complex than anything tomhow is talking about (4 layer PCB, 8-bit microcontroller, one analogue sensor circuit). Even the first revision of the board 'worked' for the most part…
[Sorry, dear reader. This post turned into a rubber duck session at your expense.]
The main peripheral and reason for the PCB is a USB MIDI device with a bit of custom sysex. Modifying an Adafruit was out of the question; the MIDI peripheral powers itself and the microcontroller/host, and the other USB peripheral. (Basically always, the host shall provide power. This USB connector, however, was designed for a proprietary, discontinued, expensive accessory.) I chose STM32 over 8051 or AVR or RP2040 because it's the cheapest dual-USB chip stocked by LCSC with good vendor tool support. I'm writing my own code because there's no ST middleware for MIDI.
The second LED should blink until both devices are plugged in and then remain steady, on. In testing, the LED visibly changes its timing after the second USB attach but doesn't stay on (rather, it blinks at a shorter and shorter period until simply shutting off, at which point the MIDI communication stops; the timing of the shutoff is not consistent) and the USB input events only register 40% of the time until the MIDI shutdown.
The LED is misconfigured intentionally; it's open drain and GPIO while I try to fix the MIDI nonsense. Later, I'll change it to push-pull on TIM2 to support PWM brightness (e.g. to monitor audio levels when not in text entry mode). Changing GPIO to PWM is its own minor pain because the USER CODE lines in the ST USB code are separate from the USB_Init/USB_RegisterClass/USB_Start sequence, so I have to reinsert my MIDI class every time I change something in CubeMX even if I don't change the USB configuration. (The USER CODE sections persist so that you can change the chip configuration and keep your code.)
Open-drain could explain weird LED behavior but not the communication shutoff. The MCU and LDO don't get noticeably warm, so I doubt it's an overcurrent situation.
I suspect D+/D- could be at the wrong level. As most STM32s, the microcontroller runs at 3.3 rather than 5 volts. (I would've loved an atmega32u4 for its 8-bit simplicity and native 5V operation but then the PCB will be double the cost and size as I'd need a pair of MCUs talking to each other with each one having a single USB port or else an off-chip USB host IC etc.) Sure, I can use a cheap multimeter to test the USB data lines, but this tells me the average level and not if the waveform is being clipped on the positive side (which is usually only a problem under 3 volts). Even if it's an electrical issue, an oscilloscope will reveal the cause but still won't provide a solution. It'll be up to me to cobble together more circuitry.
More probable is at least one code mistake, like a stack overflow or buffer overrun or peripheral misconfiguration/failure. I'm registering any expected USB class on both ports: HID and CDC and MIDI. The whole idea of the board is converting arbitrary USB input (PC keyboard, MIDI controller, joystick, etc.) into specific MIDI messages at standard USB data rates e.g. 12 Mbit/s at both ports with a fairly large buffer. The main MIDI device (supplying the power) will drop the connection after a few seconds of inactivity. I'm using an ST-Link V3 MINIE to step through, which is the cheapest I'd go on a debugger. Luckily I added SWO to my debug port and can still get useful debug info without stopping the processor. I also have to snip the power line of an OTG USB cable if I want the second USB peripheral to be a PC, which is a nifty hack you usually don't learn in the one month PCB design crash course.
I have zero visibility into what the commercial USB MIDI device expects (bus speed, signal characteristics) from the discontinued accessory and only knew its connection handshake from a random, otherwise-inactive Github user's single commit.
In any case, the USB algorithms I wrote work when the host is a PC and the code is ported to Python.
I could reroute pins to ADC and roll my own built-in oscilloscope (it's QFP and not BGA chosen specifically that I can solder in a hotfix, because I've done board design before and know it NEVER, EVER, NOT ONCE EVER goes right on the first attempt) but I'd rather spend time with my kids than a choose-your-own-adventure debug hackathon in my disorganized home office, although I did fall into the IDE trap. Every few years, IDEs and toolchains and build systems change, and this project was no different. Rather than STM32CubeIDE, I took a few hours to teach myself to use the STM32Cube Core and marus25 Cortex-Debug extensions in VS Code, as that seems to be the current trend at ST, and I do favor a vendor-agnostic, Eclipse-free workflow.
If this were my first project and I had to buy all of the tools for debugging, it would probably cost 200 euros or more even if I only buy cheap knockoffs. The other commenter suggesting a $10 logic analyzer?? I mean... I do own one of those, but it's barely tee-ball compared to the major leagues of Lauterbach or Rohde & Schwarz or even Saleae.
In any case, I fear I'll need a new revision with its two-week turnaround or at least a manual rewire of this design. It's frustrating... such a simple design, and I've already sunk over 100 euros and at least 10 hours into it and have a bug with odd symptoms. And, as a PCB design tradition, I'll be humbled and humiliated when I discover it's something like a missing switch case or a wrong clock setting or otherwise relatively basic mistake.
I'm not the first to state: There's a reason it's not called easyware.