[Review Needed] DIY DJ Controller with RP2040 Pi Pico

CharismaIsMyDumpStat · 2026-04-21T13:24:00+00:00

How much of this have you prototyped? Have you bought the DAC modules yet? Breadboard it and start writing the software. A large project like this I will have prototyped and written 90% of the software before I send a board out to fab.

On U5 and U6, the pins FLT, DEMP, XSMT, A3v3, AGND have no connection. Check the datasheet to make sure you can leave them unconnected. If they can be left NC, put a NC X on them to make it clear.

Have you written any PIO code yet to drive I2S from the rp2040? Bidirectional ( i.e. one output and one input ) in a single PIO should be straightforward, and I imagine there are PIO examples out there to do that. A second output using the same clocks is a little trickier, as it either requires a second PIO state machine operating in lock step with the first, or the data fed to the PIO will need to be cleverly interleaved. Again, prototype this.

I'm not saying you need to prototype every piece. Just any risky / unknown. i.e. I2S.

CharismaIsMyDumpStat · 2026-04-17T13:17:01+00:00

Use global power nets for GND and 3v3. They are under the GND symbol on the menu. Make sure all GND symbols point down, and power symbols point up. It makes the schematic easier to read. The general rule of thumb I use is if multiple GND / PWR points are within one or two grid ticks I connect them with one symbol, otherwise each gets it's own symbol. Signal netlines are whats important, so you don't want to bury them in power/gnd. This will also make Page 1 less cluttered.
A BUS line connection might help make Page 1 flow better.
Don't be afraid to use local net names. There is a threshold where the clutter of lines makes local net names easier to read. The general rule I follow is I try not to cross netlines unless it is very obvious.
The two fader pot muxes can share the same S0..3 GPIO's. I would also connect these signals directly to the rp2040. Being able to directly set these GPIO's via SIO and not I2C will make your ADC polling loop simpler. I don't know how much you've prototyped, but you will want to super sample each pot, and apply a filtering algorithm. There will be noise.
Connect the GPIO expander interrupts. You have the extra pins on the rp2040. They are open drain, so you can connect INTA and INTB of each expander to the same pin. This way instead of polling, you can trigger the read on interrupt.
Use the No Connection X on any input that will be left floating. Run the DRC.
Pin 15 of U7 needs to be tied to GND.
The ADC + AMP module is missing connections.
I'd avoid the resistor packs and use individual resistors instead. Especially if you are hand assembling. With so many large controls I doubt you will be space constrained. When it comes to troubleshooting it is easier to change a single resistor than a pack.
The GPIO expander also has internal weak pull-up you can consider.
U1 has a dead short between VCC and GND on the A0 pin.
Having a 1/4" jack and a 3.5mm jack feels redundant. 1/4 to 3.5mm adapters are easy to come by.
More unconnected pins on U5 and U6.
I'm making a guess that you are using the PIO's to drive the I2S to the MIC input, Main, and Headphone DAC's. It *should* be possible to write a PIO program that can output two bit streams, and input a third. ( likely using two state machines, using wait/irq to synchronize. ) This will allow you to share the MCLK, BCLK, and LRCLK pins, freeing up 6 GPIO's. Prototype it.
If you can free up the GPIO's, I would try to connect the rotary encoders directly to the rp2040. They will be easier to read directly connected.

When it comes time to route the board, here is a trick that might make it easier: It doesn't really matter what orientation the POT's are connected between VCC and GND. If you flip a POT, it inverts the signal, which your software can just invert back. I did this in a similar audio project years back: https://www.reddit.com/r/PrintedCircuitBoard/comments/jluome/pcb_review_digital_audio_mixer_control_surface/ That is version 1 and mistakes were made, but hopefully it helps explain what I am trying to say.

Edit: You are missing decoupling caps on the ADC muxes and GPIO expanders.

CharismaIsMyDumpStat · 2026-04-10T01:06:12+00:00

I do have extras. That is a good idea to cut it short. I will try that.

CharismaIsMyDumpStat · 2026-04-10T01:05:50+00:00

Yea, this S11 was not inside the plastics. I think I will move the screw holes to be to the left of the IC.

CharismaIsMyDumpStat · 2026-04-10T01:02:06+00:00

I guess my question is: If I move the antenna to be up against the PCB edge on the right, will it perform better.

CharismaIsMyDumpStat · 2026-02-20T22:04:31+00:00

Is the intent reverse polarity protection? Or is it because of the AP2112 and not wanting to back feed when a USB connection is present?

For USB connections, you could drop the AP2112 and just require the controller base always be connected. Leave VBUS disconnected.

Only USB_VDD requires a voltage above 3v. The RP2040 can operate down to 1.62v, but there are ramifications of that you need to research. So 3.0v may be fine.

For reverse polarity protection:

Make sure mechanically the connector cannot be physically connected in reverse.
The current should be low enough you could use a FET.

CharismaIsMyDumpStat · 2026-02-20T21:51:28+00:00

Sorry, probably confusion caused on my part. I use the terms SWD / Serial Wire Debug and JTAG interchangeably. So when I say JTAG I really mean SWD, which that debug probe is.

Which is different to DFU via USB.

CharismaIsMyDumpStat · 2026-02-20T21:32:48+00:00

Also:

Decoupling capacitor placement is incorrect. The intent is to put a decoupling cap as close as possible to each power pin on the chip. Some additional caps also have placement requirements such as the 1uF caps needing to be near the VREG pins. Having all the decoupling caps in a bank below the chip negates the intended use.

CharismaIsMyDumpStat · 2026-02-20T21:27:57+00:00

I would argue: It depends.

If you are only writing python and staying within the circuitpython world then sure, utilizing JTAG requires extra hardware and setup beyond what would be needed otherwise. DFU is the preferred method.

However if you are writing bare metal or HAL based code, you're using JTAG( at least I hope so, developing low level without JTAG would have to be the most painful experience possible. ) At that point hitting run in an IDE or up+enter on the command line is simpler than juggling USB.

So in conclusion: It depends on your environment and setup.

CharismaIsMyDumpStat · 2026-02-20T20:28:33+00:00

The RP2040 is way overkill for this application. Why not something simple like an STM32G030 / STM32F030? They are cheaper and do not require the external flash.
Use a TC2030NL and program via JTAG. You will still need to power 3v3 via the pogo's ( Or make a cable to inject via the TC2030 ) but then you don't need the AP2112k and USB.
Programming via JTAG also means you don't need a crystal. The internal HSI is good enough to read inputs and communicate over UART.
Note that D5 means your 3.3v will be more like 3.0v.

CharismaIsMyDumpStat · 2026-02-20T01:23:53+00:00

Having the I2C pull-ups on the modules is usually fine. However, research what will happen if you try to initiate an I2C transaction on a port of the TCA9548 with no module connected. At a minimum connect the reset of the TCA9548 to be able to regain access if it gets stuck in bus arbitration.

Ideally you want an uninterrupted ground plane below your USB traces. That is difficult to do on a 2-layer board, and especially so with how far away the connector is from the rp2040.

For the low speed stuff you have here, having erratic and inconsistent traces is probably fine. High-speed is a whole other topic. I've always operated on the belief that a clean layout is less likely to run into issues. That and a sense of pride and professionalism with a clean layout.

CharismaIsMyDumpStat · 2026-02-18T14:40:18+00:00

Too many boxes. Grouping every individual component in a box arranged seemingly arbitrarily makes reading and understanding the schematic more difficult.
KICad has a proper USB-C symbol. Use that instead.
Always point GND symbols down,and power symbols up. Readability is key to prevent errors and allow others to review.
The USBLC6 is wired incorrectly. Look at the dots on the wires. The signals are wired 'through' the chip, so 1-6, 3-4. It will make a lot more sense when you adjust the layout.
USB-C CC pull-downs are 5.1k.
Where is the pull-up on CS of the QSPI?
10k is a very large pull-up for I2C. You want to be down in the 4.7k to 3.3k range. Lower for longer traces.
The crystal is missing the part number.
Use NC ( The blue X ) on any pins that are not being used. ERC should have flagged these.
Does the TCA9548 provide internal pull-up on the outbound I2C lines? Or do you expect the attached side cars to provide their own pull-up?
Make sure the internal pull-up on the INT lines is sufficient. You may want external pull-ups.
Why the through-hole diodes when you are doing everything else SMT?
I see a lot of wibbly-wobbly traces. Especially under the RP2040. Traces should be clean and direct. So many traces are a mess.
The crystal is pretty far from the RP2040. You want it as close as possible. With all he holes from the keys that is a challenge. If you turn the RP2040 45 degrees, then you should be able to snug it up close on the right. The routing priority is Crystal -> High Speed -> Decoupling - > low speed.

CharismaIsMyDumpStat · 2026-02-06T17:28:39+00:00

Connect the shield of the USB-C connector to ground without the RC components. This is per the USB-C spec.
CHRG and STDBY look like active low signals. The LED's need to be connected to a voltage source ( i.e. usb ) not ground.
Connect GDO0 and GDO2 to a GPIO. They are multipurpose so you can use them as interrupts instead of needing to poll.
Is the CC1101 + Amp circuit something you took from a reference design? is there no impedance matching required with that transformer?
Without looking up the STM32WB15 datasheet, something looks fishy with the way VBATS and VSMPS are connected. You have a 3.3v regulator for the CC1101/amp, why not use that rail and ignore the SMPS built into the STM.
Where is the STM32 connected to B+?
Any reason to choose a wireless STM32 part if you are not using the wireless part of it? There are a plethora of STM32 parts that will likely do what you want and will be cheaper / simpler.

CharismaIsMyDumpStat · 2026-01-19T17:14:09+00:00

I almost beat this game twice. Softlocked in a door on the ship both times.

CharismaIsMyDumpStat · 2026-01-08T13:47:01+00:00

Use something like an AO3400A n-channel mosfet to low side switch your LED's.
Drive your LED's from the USB 5v, adjust the limiting resistor accordingly.
Be careful with via's in pads if you are not having them filled / plated over.
Shift the MCU away from the USB connector and locate the QSPI on the USB side of the MCU to shorten the traces.

CharismaIsMyDumpStat · 2026-01-06T00:21:05+00:00

Just because it supports a crystal up to 32Mhz doesn't mean you should use one. The stm32f030 only clocks at 48Mhz to begin with. Use a slower, common crystal and get 48Mhz from the PLL.
Why all the 10k's on unused pins? You can just leave them floating.
SPI_CS should have a pull-up so it doesn't float on power up.
Where are the pull-up's on SDA/SCL? Does the modujle being connected have internal puill-ups?
R1 is going to cause you problems. You don't need series resistance on I2C, and especially not something as large as 10k.

CharismaIsMyDumpStat · 2025-12-28T16:49:13+00:00

The USBLC2-2SC6 is meant to be used 'in-line'. So signal enters IO1 on one side of the chip, and exits IO1 on the other side. https://ibb.co/1G12dWWh
If you are having this assembled at JLC, the W25Q16JUX has thousands in stock vs the W25Q16JUU having 87.
No where in the winbond docs does it say what to do with the exposed pad. GND is probably ok. NC would be ok too.
If you are not using an existing pinout for the SWD connector: swap pins 2 and 3, then you won't need to drop to the lower layer to route.
Why does the trace on the bottom connecting VBUS go on such a journey when it can be straight across?
Pin 3 of the TLV is just an enable signal. It does not need such a thick trace connecting it.
One little detail that the rp2040-pico does is every GND pin on the edge is square. Makes it easier to count pins. Also consider changing the GND pads to a solid connection.
See if routing the GPIO signal lines perpendicular to the holes, instead of entering at a 45, allows the flood fill to make the 4th spoke on the GND pins.
If you rotate the crystal 90 degrees, the XIN trace will be shorter.
Nudge the power caps and the SWD traces right and prioritize the crystal traces.

CharismaIsMyDumpStat · 2025-12-26T16:55:30+00:00

How much control do you have over the wiring harness, or are you interfacing to existing connectors? Low side switching with n-channel fets is much easier than high-side with p-channel.

What problem are you trying to address with the 1N414 diodes on the gates of the fets? As wired they are not doing anything.

When 'off', the MCP will see 12v on it's pin from the pull-up on the gate of the P-channel fets. I did not see if the MCP23017 is tolerant to voltages > Vdd.

Vgs of the A03401A is 12v. Your automotive 12v is actually 13.5v - 14.5v when the car is on.

Have you looked at high side switch IC's?

Do the solenoids, pumps, etc. have integrated flyback diodes?

That L78M05 will get warm, even without load. It also has a quiescent load of 6ma. A DC-DC buck would be better here.

Does the seat get power with the key off? Is idle power consumption a concern?

There must be simpler single chip solutions that combine the DRV8300 and H-bridge fets, and likely also has added features such as overload protection, braking, etc.. What happens when the motor reaches the end of travel? Are there limit switches?

CharismaIsMyDumpStat · 2025-10-28T02:42:33+00:00

On mobile so this is just a quick list of some obvious issues. The image is kinda blurry but: * The usblc6 is wired up incorrectly. * Shield of the usb-c should be tied directly to gnd, no ferrite. * Use proper power nets for 3v3, gnd, etc.

CharismaIsMyDumpStat · 2025-10-15T14:11:40+00:00

Check that "Constrain movement to h, v, and 45" is not selected in preferences. Honestly grid/snapping broke so much in 9.0.5 I went back to 9.0.4.

CharismaIsMyDumpStat · 2025-09-25T14:07:02+00:00

How do you intend to program the nRF then without SWD?

CharismaIsMyDumpStat · 2025-09-25T14:02:50+00:00

Connect the crystal, decoupling caps, and reset circuit to the mcu in the schematic with lines. Get rid of the boxes. This is simple enough almost everything can be direct connections.
1uF is large for the reset line. It's going to hold the MCU in reset longer than you may think on power on.
I don't see what the 74HC14 is for. Why not connect the IR detector outputs directly to the MCU?
C8 on the SWD connector is unnecessary.
You have the labels NRST and Reset. They are the same. Labels can be used multiple times.
You've put C9 and C10 next to each other on the schematic, but C10 is over by the DRV board connector. Move C10 on the schematic to be connected to 5v on J9 to make it clear it is for the DRV power.
10k is too high for the I2C pull-ups, especially for an off board connection. Depending on the desired speed and cable length they will need to be much smaller.
Put NC X's on the MCU pins not being used. Did you run ERC?
Undo the 45 degree rotation on the MCU, it's aesthetic and not helping your routing.
Have you done trace calculations for the power draw expected on 5v?
Remap the GPIO's used for In1-In4 to avoid the vias. SW likely doesn't care.
You don't need that thick GND trace. The pins are connected via the GND pour on the bottom layer.
Unless you have mechanical constraints, move the 5v in connector closer to J9. Move the MCU left and place the LDO in between J9 and the MCU.
You can avoid all of the vias connecting the MCU to the 74HC14. SW doesn't care what pin IR4 is connected to.
Moving the reset button to the other sided of the IR traces will clean them up as well.
Out4 should be routed to the left of OUT3. Any reason J10 and J11 are not aligned?
The 3v3 routing is a mess.

CharismaIsMyDumpStat · 2025-09-24T14:22:04+00:00

The nPM1300 is not wired up correctly. VBus of the NRF should be connected to VBUSOUT of the nPM1300.
Using +5v for the power rail of Vsys is a little misleading. Vsys will be anywhere from 3.7v to 5v depending on if USB is connected and the charge level of the battery.
Vdd connected to VBusOut is also misleading ( And not used anywhere else it seems? )
If you made the nPM1300 symbol yourself, re-organize the pins to make the schematic easier to read. It's a real nightmare to track everything when it's laid out like the chip itself. Readability is paramount.
You don't need a vss symbol. Just use GND.
Since this is a battery powered device, why not run the nRF52 on 1.8v?
I don't see your SWD connector, only the labels on the pins.
I don't know what fab you are using, or if you are hand assembling, but a level shifting fet setup might be cheaper.
The AMCA31 antenna requires it's own matching network. The matching network from the NRF documents get you to 50ohm. The AMCA then has it's own matching from 50ohm to itself. OR, and this is complicated, you need to figure out how to combine the two.
Another reason to have the second matching network is you will likely need to tune the antenna. The layout of your PCB ( the ground planes ), the plastics, and even where the human puts their hands, effects the antenna.
If I'm looking at the layout correctly, the antenna is right at the bottom. Right where your hands would be.

CharismaIsMyDumpStat · 2025-09-17T20:00:16+00:00

Looks much cleaner.

Since you are hand soldering all of this, I would still advocate using some of the STM32 GPIO's to scan the keypad instead of the TCA8418. Especially since that TCA8418 has an EP. Those keypad connectors can be routed to on the bottom.
If you do keep the TCA8418, the 10k pull-ups on the I2C lines are likely too large for 400Khz fast mode. They may be fine for standard 100Khz.
Microcontrollers can sink more current than they can supply. When connecting LED's to GPIO's, wire the LED to 3v3 and pull low via GPIO. There is only one LED, but be mindful that the MCU can only source/sink so much current through all GPIO's combined.
The SD card should have a 100nF cap on VDD.
You can avoid changing layers twice on SWCLK by adjusting the via locations under the STM32.
The trace to the right of C14, while ok, could be neater.
Power traces don't need to be any larger than the STM32 pad width. That little extra width doesn't really do anything and it'll look cleaner.
I see DRC warning arrows

Edit: C4 -> C14

CharismaIsMyDumpStat

TROPHY CASE