Screenshot of the code decompiled after these patches are applied, showing that all the register writes are nicely decompiled and appropriate register names are shown in the code

Making Ghidra Play Nice With RP2040

Developing firmware for RP2040 is undeniably fun, what’s with all these PIOs. However, sometimes you will want to switch it around and reverse-engineer some RP2040 firmware instead. If you’ve ever tried using Ghidra for that, your experience might have been seriously lackluster due to the decompiled output not making sense when it comes to addresses – thankfully, [Wejn] has now released patches for Ghidra’s companion, SVD-Loader, that turn it all around, and there’s a blog post to go with these.

SVD-Loader, while an indispensable tool for ARM work, didn’t work at all with the RP2040 due to a bug – fixed foremost. Then, [Wejn] turned to a pecularity of the RP2040 – Atomic Register Access, that changes addressing in a way where the usual decompile flow will result in nonsense addresses. Having brought a ton of memory map data into the equation, [Wejn] rewrote the decoding and got it to a point where peripheral accesses now map to nicely readable register writes in decompiled code – an entirely different picture!

You can already apply the patches yourself if you desire. As usual, there’s still things left in TODO for proper quality of life during your Ghidra dive, but the decompiled code makes way more sense now than it did before. Now, if you ever encounter a RP2040-powered water cooler or an air quality meter, you are ready to take a stab at its flash contents. Not yet familiar with the Ghidra life? Well, our own HackadayU has just the learning course for you!

A Thoroughly Modern Serial Terminal

The humble desktop serial terminal may have long disappeared from the world of corporate IT, but there are still plenty of moments when professionals and enthusiasts alike need to hook up to a serial port. Many of us use a serial port on our laptops or other mobile devices, but [Neil Crawforth] has gone one better than that with the VT2040. It’s an old-style serial terminal in a super-handy portable format, and as one might guess from the name, it has an RP2040 microcontroller at its heart.

Attached to the chip is a rather nice keyboard, and an ILI9488 480×320 LCD display. The software is modular, providing a handy set of re-usable libraries for the different functions including a PIO-based serial port. His main application seems to be talking to an ESP8266, but we’re guessing with a MAX232 or other level shifter chip it could drive a more traditional port. Everything can be found in the project’s GitHub repository, allowing anyone to join the fun.

As long-time readers will know, we’ve been partial to a few serial terminals in the past. Particularly beloved is this extremely retro model with vintage dot matrix LEDs.

Testing The Raspberry Pi Debug Probe

We mentioned the Raspberry Pi Debug Probe when it was launched, a little RP2040-based board that provides both a USB-to-UART and an ARM SWD debug interface. [Jeff Geerling] was lucky enough to snag one, and he’s put it through its paces in a handy blog post.

The first question he poses is: why buy the Pi offering when cheaper boards can be found on AliExpress and the like? It’s easily answered by pointing to the ease of setting up, good documentation and support, as well as the device’s reasonable price compared to other commercial probes. It also answered a personal question here as he hooked it up to a Pico, why it has three jumpers and not the more usual multi-way header we’ve seen on other ARM platforms. We should have looked at a Pico more closely of course, because it matched neatly to the Pi product. On the Pico they’re at the edge, while on the Pico W they’re in the center.

No doubt if the latest addition to the Pi stable has any further revelations we’ll bring them to you. But it’s worth a quick look at this piece to see a real experience with their latest. Meanwhile, take a quick look at our launch coverage.

New Product: The Raspberry Pi Debug Probe

It’s fair to say that among the new product launches we see all the time, anything new from the folks at Raspberry Pi claims our attention. It’s not that their signature Linux single-board computers (SBCs) are necessarily the best or the fastest hardware on paper, but that they’re the ones with meaningful decade-plus support. Add to that their RP2040 microcontroller and its associated Pico boards, and they’re the one to watch.

Today we’ve got news of a new Pi, not a general purpose computer, but useful nevertheless. The Raspberry Pi Debug Probe is a small RP2040-based board that provides a SWD interface for debugging any ARM microcontroller as well as a more generic USB to UART interface.

The article sums up nicely what this board does — it’s for bare metal ARM coders, and it uses ARM’s built-in debugging infrastructure. It’s something that away from Hackaday we’ve seen friends using the 2040 for as one of the few readily available chips in the shortage, and it’s thus extremely convenient to have readily available as a product.

So if you’re a high level programmer it’s not essential, but if you’re really getting down to the nuts-and-bolts of an ARM microcontroller then you’ll want one of these. Of course, it’s by no means the first SWD interface we’ve seen, here’s one using an ESP32.

Ploopy Builds Open Source RP2040-Powered Headphones And You Can Too!

We’ve seen many DIY headphones projects on these fair pages over the years, but not many that are quite as DIY as the Ploopy Headphones. What makes this project interesting is the sheer depth of the construction, with every single part being made from what we might call base materials. Materials such as 3D printer filament, foam and felt, and the usual metallic vitamins.

The electronics are fairly straightforward, with an RP2040 functioning as the USB audio interface and equalizer function. Audio samples are emitted as I2S into a PCM3050 24-bit stereo codec which generates a pair of differential output audio signals. These are then converted from differential to single-ended signals and passed on to the coil drivers. The coil drivers consist of no fewer than eight-paralleled opamps per channel. All of this is powered by the USB-C connection to the host computer. Whilst a kit of parts is available for this, you can make your own if you wish, as the full source (Altium designer needed for tweaks) is available on the Ploopy headphone GitHub.

A pretty ploopy response

Many DIY headphone builds would likely be using off-the-shelf speaker units, with large parts of the ear cups being taken from spare parts kits for commercial offerings. But not the Ploopy. The drivers are constructed from flex PCB coils with a standard TRRS jack on each side. Magnets for these coils to react against are held in a 3D-printed frame that is attached to the outer cover. The coils are aligned with a special jig and bonded to the ‘driver foam’ with some 3M VHB tape.

The ear cups are constructed with some 3D printed rings, foam pieces, and simple woven material. The resonator plates push into the inner side of the cup, and the assembly simply screws to the driver assembly. The incredibly detailed assembly wiki makes it look easy, but we reckon there are a few tricky steps in there to trip the unwary. The headband again consists of printed spring sections, some woven material, and foam with a few metallic vitamins thrown in. That makes it sounds simple, but it isn’t.

On the whole the build looks fantastic, but what does it sound like? The Ploopy team has tested them against a pair of Sennheiser HDRXX giving a broadly comparable response, but we’re no audio experts, and the proof, as always, is in the wearing. This project seems to be the ultimate in audio tweakability, with the punchy RP2040 capable of running six audio filters at the full 48 KHz, 16-bit audio, though, the PCM3050 is capable of more.

Want to build some headphones, but need a Bluetooth interface? We got you covered. Can 3D printed headphones ever compare to the big names? We’ll see.

Dumping script window, showing the bytes being dumped one by one from the STM chip

Need To Dump A Protected STM32F0x? Use Your Pico!

Sometimes, security mechanisms can be bypassed if you just do things slightly out of the ordinary. For instance, readout protection on microcontrollers is a given nowadays, to the point where it’s intentionally enabled and relied upon as a major technical measure to protect intellectual property. The gist is — when you connect to a microcontroller over its debug interface and then ask to read its flash memory, it will politely refuse. However, [Racerxdl] shows us that in practice, it’s not flawless protection – for certain chips, you just need to be a little quicker than usual.

Usually, flashing and debugging software will chat with the microcontroller for a bit, and probe parameters before going for any direct requests. However, if you skip the courtesy and bluntly get to the point immediately right after power is applied to the microcontroller, you can intimidate them just enough to give you one byte of its memory before it refuses to cooperate further. Since that can be any byte you wish, you can read the entire flash — one byte at a time.

You need to power cycle the chip before you can progress, so the hardware does involve a bit more than just an SWD interface, and it will take a fair bit more time than reading out a non-protected chip the usual way; plus, of course, the debugging interface needs to be active for this in the first place, which isn’t always the case. However, it still beats paying a few thousand dollars for a factory in China to decap your chip and read it out using a fancy machine.

[Racerxdl] didn’t just write a proof-of-concept for this attack – they implemented it for one of our favourite chips, the RP2040. As such, you no longer need an unobtainium STM32 to dump an unobtainium STM32.

To be clear, [Racerxdl] didn’t design this attack — it’s been around for some time now. Credit for that goes to Johanes Obermaier. All in all, this is a wonderful reminder that seemingly reliable security mechanisms can be foiled by the simplest tricks. For instance, if your chip erases the flash when you unlock its protection, you can just tell it not to.

Building A Fake Printer To Grab Screenshots Off The Parallel Port

[Tom Verbeure] recently found himself lamenting the need to take screen grabs from an Advantest R3273 spectrum analyzer with a phone camera, as the older gear requires you to either grab tables of data over an expensive GPIB interface card, or print them to paper. Then he realized, why not make a simple printer port add-on that looks like a printer, but sends the data over USB as a serial stream?

On the hardware side, the custom PCB (KiCAD project) is based on the Raspberry Pi Pico. Obvious form factor issues aside ([Tom] did revise the PCB to make it smaller) this is a shrewd move, as this is not a critical-path gadget so using the Pico as a USB-to-thing solution is a cost-effective way to get something working with minimal risk. One interesting design point was the use of the 74LVC161284 special function bus interface that handles the 5 V tolerance that the RP2040 lacks, whilst making the project compliant with IEEE-1284 — useful for the fussier instruments.

Using the service manual of the Sharp AP-PK11 copier/printer as a reference, [Tom] again, shows how to correctly use the chip, minimizing the design effort and scope for error. The complete project, with preliminary firmware and everything needed to build this thing, can be found on the project GitHub page. [Tom] does add a warning however that this project is still being worked on so adopters might wish to bear that in mind.

If you don’t own such fancy bench instrumentation, but grabbing screenshots from devices that don’t normally support it, is more your thing, then how about a tool to grab Game Boy screenshots?