I designed a fairly simple expansion card as my first. It utilizes an RP-2040 and exposes a Serial Wire Debug port as well as a simplified UART port, without the RTS, CTS or power pins. I rarely see the xTS pins used these days, and as for power, well, that’s something for the driven device to figure out.
GitHub Link
(Docs folder contains schematic and PCB detail)
Features
- SWD JST header with SWCLK, GND, and SWDIO pins
- UART JST header with with only the TX, RX, and GND pins
- Level shifters on the UART IO to accept a variety of voltages
- Neopixel LED indicators for both ports
- Inbound SWD exposed as test pads
- Three debug GPIO pins exposed as test pads
Outstanding issues
- Level shifting… doesn’t actually work
- Just now, while reading the datasheet and logic level docs, I am realizing that my naive solution won’t work. I just wired the TX and RX IO to the level-shifters like, yeah, this’ll do. What I think needs to happen is another DO switches the power supply to the level-shifters so that it can be set to 5V0 or 3V3. Then it should work, but I’m going to spice it before ordering boards. Additionally, I would like to enable 1V1 and 1V8 IO, just because, but we’ll see.
- Anyone have a better idea for how to approach this? I am really trying to avoid hardware switches; the face is taken up by the JST pins and Neopixels, and I don’t want the user to have to remove the card to make the change.
- Limited buffer capacitors on RP2040 inputs
- Due to the small card size, I removed one of the 3V3 buffer caps and two 1V1 caps. Could I have squeezed them in? Yes, but by the time I realized the space constraints, it would have required a pretty major rework.
- Plan here is to build one of my other RP-2040 based board without the roughly-analogous caps and see how well they work.
Q&A
Q. Why are you making another UART board when Josh already did that?
A. Well, first of all, there’s nothing wrong with me getting some practice in with a straightforward design. But the main point of this board is the SWD port to make it friendly for RP-2040 developers, so they can flash code directly from their PC without lugging around a bulky Pico Probe.
The UART port is just a bonus, since there is the space for it. I think it could be very useful to RP-2040 developers to have both in one compact package.
Q: Why not use a pass-through UART chip?
A: This is a great question and one area where Josh’s board will definitely outshine mine. If you want to communicate with electronics directly from your computer, this may not be the best option. (It may be possible with a pass-through executed in software? Not sure.) The UART port will likely be used more as a unit tester or logger than a full communication port.
Q. Why NeoPixels?
A. Because NeoPixels are cool and I’ve wanted to incorporate them into a project for a while. Considering each board will likely be hand-made by me, the true cost is in labor, not materials. So it doesn’t make a huge difference to spend 70c instead of 7c on the indicator lights. NeoPixel will give greater flexibility; instead of a single color communicating information from the blinking frequency, a variety of status can be indicated from diverse color patterns.
The statuses will relate to the SWD and UART bridges as well as status of the card.
That’s what I have for now. Not ready to order boards due to the level shifting issue. But while I am tackling that, I’d like to run a poll and determine which of the above features folks actually find useful. Please answer if you could envision an RP-2040 based SWD port expansion card as a useful part of Frame.Work toolkit!
What features would you like to see in an RP-2040 SWDebugger Dev Card?
- SWD, UART, and NeoPixels!
- SWD and UART!
- SWD and NeoPixels!
- SWD and… (please elaborate in a reply)
0 voters
Cheers,
Kris K