Add TRRS jack short protection / backpower protection

[JellyTitan]

Adding a DMG2305UX PFET to the left-hand side by the TRRS jack seems like a low-cost / low effort option for folks who want added backpower protection. Its a bog-standard SOT23 package, pretty easy for anyone comfortable with surface mount soldering, and the bypass option is just another simple solder-bridge.

Originally posted by @TheWerle in #11 (comment)

Adding TRRS short protection would be really helpful! I don't have the bandwidth for this improvement right now, but I'd love to see this implemented. A through-hole alternative component would also be really nice, since this board may be the first/only soldering experience that many users have.

[JellyTitan]

To clarify requirements for adding backpower protection

• Add a SOT23 footprint for the DMG2305UX PFET Diode
• The diode should be on the left hand only
• There should be a bypass option that can be bridged with a jumper
• A through hole component alternative is desired, but not required.

@TheWerle can you confirm that I understood that correctly?

[TheWerle]

To be clear, the DMG2305UX addition is only a solution for backpower across the cables. It won't protect against short-circuits in the "TRRS cable gets yanked while powered" scenario, it only prevents accidental dual-power failures.

I'm still looking into whether there's a equivalent "simple enough to be worth doing" option for the short-circuit problem, but I don't know if there will be while using TRRS jacks. Typical over-current protection solutions are a degree of complexity more than we'd want, and the risk is under-diagnosed and under-defined. I'm putting up a Reddit post to see if anyone has first-hand experience with a pulled-cable failure and actually diagnosed the specifics, it really seems to me that the PC standard USB 2.0/3.0 overcurrent detection should prevent any damage and that everything in our RP2040-Pico based power circuit has sufficient power-ratings to survive.

https://www.reddit.com/r/ErgoMechKeyboards/comments/1aupzz3/split_keyboard_best_practices_for_protection/

[JellyTitan]

Oh! I thought it was a cable-yank fix. Thank you for clarifying.
I came across that reddit thread earlier today - I gotta admit - i didn't understand most of that. It was interesting though - plenty of folks are aware of the issue and the common approaches.
I think somebody mentioned, the cable-yank can burnout one of the TX/RX pins. The Pico has a patch bay for rewiring if that happens, but I feel like most folks would never take it so far as to rewire/recompile for a new pin set. I suspect that's one of the reason that socketing MCU's is often recommended.

[JellyTitan]

I updated the BOM socket section to include a note about the merits of socketing & the potential for input pin burnout.
https://soflepico.com/bom#optional---mcu-sockets

[TheWerle]

Tested the TRRS cable dual-supply PFET circuit and it works as expected. With the right-hand "primary" PFET jumper bypassed and the left-hand "secondary"" blocked by the PFET power flows unidirectionally as expected, and the dual-power voltage waveforms don't seem to include any troubling spikes/noise.

As I noted above, using the Tenstar clone won't work for the "secondary" if this protection is desired because the VBUS/VSYS voltages are going to be identical, so if those modules remain preferred for both halves both halves should be bypassed. Same thing goes if a user desires the ability to switch between either half as the primary due to the unidirectional power flow.

Pri+Sec with USB-C Pico clones

Tenstar Pico primary with jumpered Pins 39/40, USB-C Clone secondary

[JellyTitan]

Thank you for your work on this! I'm looking forward to incorporating this from the Chico into the pico. I connected two cables again today while i was debugging firmware builds - i got lucky this time - no magic smoke escaped.