Hardware is here!

A project log for RetroMedleyCard

A retro emulation system on a <=2mm thick business card, using ideas borrowed from other projects and a sprinkling of insanity...

eontronicsEontronics 06/12/2024 at 01:510 Comments

First set of boards are finally here, so soon I should be able to start testing software!

Assembled board front view

Assembled board rear view

The boards were ordered with PCBA for most of the surface mount components, largely due to the use of DFN/QFN packages which would be difficult to solder without reflow. The flexible connector “prongs” had to be separated from the edge of the PCB (shown below) and soldered onto the front of the card, forming the contacts for the SD card and 3.5mm Audio Jack. Additionally, a handful of passive components forming the crystal oscillator and RF filter still needed to be assembled, as the specific component values required additional fees for SMT assembly. (Shoutout to my dad for helping assemble these while I’ve been trying to write firmware!)

Board as shipped. Note the prong structures attached to the bottom of the board which are removed and soldered to the front of the PCB to act as flexible contacts.

The unusual connector designs actually appear to work better than I expected, though I’m not entirely convinced the SD card and 3.5mm jack are making good contact. Nevertheless, It looks good for a first version and should be bodge-able if they prove problematic. Due to the small profile, I chose to omit the cutouts in the sides of the USB-C plate, which would normally provide a latching action, so that they would be easier to mill. Fortunately there still seems to be enough friction to provide a decent retaining force, and the (H)DMI connector also stays seated without too much fuss.

Assembled board demonstrating the use of the many silly connectors it incorporates. Much to my surprise, the PCB prongs seem to hold up quite well to being flexed when inserting/removing the SD card and Audio plug.

In the meantime, I’ve been focusing on trying to get an initial firmware to a state where it can be uploaded to test that the board is actually functional. In particular I’ve been trying to understand how the Serial Wire Debug (SWD) interface of the RP2040 works such that I can upload a program into RAM from the ESP32. 

As it turns out, the SWD interface is actually quite simple, while the documentation (in my opinion) makes trying to understand it seem like a chore. Eventually, I stumbled across this application note by Silabs, which gives a fairly concise explanation. To keep things brief, each transaction essentially consists of an 8-bit request followed by an acknowledgment and 32-bits of data read/write. The request can read or write to one of four registers on the debug port to control it, such as to select an access port to the system’s resources. The access port is then controlled using the same request format to manipulate registers to access system memory, etc. 

Aside from a few nuances (inserting an extra clock cycle to change data direction, clocking an extra 8 bits after the last transaction  to ensure it is fully cooked through the debug port) this forms 99% of transactions over SWD. Initialisation of the debug port seems to be an exception, which requires specific sequences of bytes to be transferred to reset and enable the interface.

The RP2040 specifically implements a multi-drop bus, allowing multiple targets to be connected, This seems to be a feature of “SWDv2”, which also implements some additional registers that were reserved in v1. This also requires a different initialisation sequence compared to v1, so documentation that does not refer specifically to multi-drop/SWDv2 is likely for the older v1 interface, and probably won’t work the the RP2040! 

What would be nice now would be an easy-to-use, high level library to bit-bang either version of the SWD protocol, to make using the RP2040 as a flash-less coprocessor easier, for applications acting as an IO expander, to provide additional interfaces, or even to allow other architectures to use the RP2040 PIOs? This could also support more capable successors to the RP2040, should Raspberry Pi ever release more microcontrollers. Maybe someday I will try to write such a library, should I have the time and can resist the urge to procrastinate!