I2C Sniffing Comes To The Bus Pirate 5

While the Bus Pirate 5 is an impressive piece of hardware, the software is arguably where the project really shines. Creator [Ian Lesnet] and several members of the community are constantly working to add new features and capabilities to the hardware hacking multi-tool, to the point that if your firmware is more than a few days old there’s an excellent chance there’s a fresher build available for you to try out.

One of the biggest additions from the last week or so of development has been the I2C sniffer — a valuable tool for troubleshooting or reverse engineering devices using the popular communications protocol. [Ian] has posted a brief demo video of it in action.

It’s actually a capability that was available in the “classic” versions of the Bus Pirate, but rather than porting the feature over from the old firmware, [Ian] decided to fold the MIT licensed pico_i2c_sniffer from [Juan Schiavoni] into the new codebase. Thanks to the RP2040’s PIO, the sniffer works at up to 500 kHz, significantly outperforming its predecessor.

Admittedly, I2C sniffing isn’t anything you couldn’t do with a cheap logic analyzer. But that means dealing with captures and making sure the protocol decoder is setup properly, among other bits of software tedium. In comparison, once you start the sniffer program on the Bus Pirate 5, I2C data will be dumped out to the terminal in real-time for as long as you care to see it. For reverse engineering, it’s also very easy to move quickly from sniffing I2C packets to replaying or modifying them within the Bus Pirate’s interface.

If you already have a Bus Pirate 5, all you need to do is flash the latest firmware from the automated build system, and get sniffing. On the fence about picking one up? Perhaps our hands-on review will help change your mind.

Hacker Tactic: Building Blocks

The software and hardware worlds have overlaps, and it’s worth looking over the fence to see if there’s anything you missed. You might’ve already noticed that we hackers use PCB modules and devboards in the same way that programmers might use libraries and frameworks. You’ll find way more parallels if you think about it.

Building blocks are about belonging to a community, being able to draw from it. Sometimes it’s a community of one, but you might just find that building blocks help you reach other people easily, touching upon common elements between projects that both you and some other hacker might be planning out. With every building block, you make your or someone else’s next project quicker, and maybe you make it possible.

Sometimes, however, building blocks are about being lazy.

Continue reading “Hacker Tactic: Building Blocks”

Experimenting With MicroPython On The Bus Pirate 5

I recently got one of the new RP2040-based Bus Pirate 5 (BP5), a multi-purpose interface debugging and testing tool. Scanning the various such tools in my toolbox already: an Analog Discovery 2, a new Glasgow Interface Explorer, and a couple of pyboards, I realized they all had a Python or MicroPython user interface. A few people on the BP5 forums had tossed around the idea of MicroPython, and it just so happened that I was experimenting with building beta versions of MicroPython for a RP2350 board at the time. Naturally, I started wondering, “just how hard can it be to get MicroPython running on the BP5?”

The Lazy Approach

Rather than duplicating the BP5 firmware functionality, I decided to ignore it completely and go with existing MicroPython capabilities. I planned to just make a simple set of board definition files — perhaps Board Support Package (BSP) is a better term? I’ve done this a dozen times before for development and custom boards. Then write a collection of MicroPython modules to conform to the unique aspects in the BP5 hardware. As user [torwag] over on the Bus Pirate forums said back in March:

Micropython comes already with some modules and enough functions to get some stuff out-of-the-box working. E.g. the infamous version of “hello world” for microcontrollers aka led-blinking.

Continue reading “Experimenting With MicroPython On The Bus Pirate 5”

The Worsening Raspberry Pi RP2350 E9 Erratum Situation

There’s currently a significant amount of confusion around the full extent of the GPIO hardware issue in the Raspberry Pi RP2350 microcontroller, with [Ian] over at [Dangerous Prototypes] of Bus Pirate fame mentioning that deliveries of the RP2350-based Bus Pirate 5XL and 6 have been put on hold while the issue is further being investigated. Recorded in the MCU’s datasheet as erratum RP2350-E9, it was originally reported as only being related to the use of internal pull-downs, but [Ian] has since demonstrated in the primary issue ticket on GitHub that the same soft latching behavior on GPIO pins occurs also without pull-downs enabled.

Ian from Dangerous Prototypes demonstrating the RP2350-E9 issue in a Bus Pirate prototype without pull-ups.
Ian from Dangerous Prototypes demonstrating the RP2350-E9 issue in a Bus Pirate prototype without pull-ups.

When we first reported on this hardware bug in the RP2350’s A2 (and likely preceding) stepping there was still a lot of confusion about what this issue meant, but so far we have seen the Bus Pirate delay and projects like [Agustín Gimenez Bernad]’s LogicAnalyzer have opted for taking the RP2350 port out back. There are also indications that the ADC and PIO peripherals are affected by this issue, with workarounds only partially able to circumvent the hardware issue.

In the case of the Bus Pirate a potential workaround is the addition of 4.7 kOhm external pull-downs, but at the cost of 0.7 mA continuous load on the GPIO when pulled high and part of that when pulled low. It’s an ugly hack, but at the very least it might save existing boards. It also shows how serious a bug this is.

Meanwhile there are lively discussions about the issue on the Raspberry Pi forums, both on the E9 erratum as well as the question of when there will be a new stepping. The official statement by Raspberry Pi is still that ‘they are investigating’. Presumably there will be a Bx stepping at some point, but for now it is clear that the RP2350’s A2 stepping is probably best avoided.

Walking The Plank: Add-Ons For The Bus Pirate

The Bus Pirate multi-tool has held a place of honor in many a hardware hacker’s toolbox for years, and the latest generation of the gadget powered by the Raspberry Pi RP2040/RP2350 offers significantly enhanced capabilities over the original PIC versions. We took a look at the new Bus Pirate when it started shipping back in February, and while the firmware was still in the early stages back then, it was already clear that creator [Ian Lesnet] and his team had put together a compelling product.

Over the last several months, the Bus Pirate software has improved dramatically. New features have started showing off the hardware’s capabilities, and the user experience is far improved over where it was at release. Following the firmware development is a roller coaster ride, with [Ian] sometimes pushing out several updates a day. Luckily, like the Pi Pico itself, updating the new Bus Pirate only takes a second.

But as impressive and important as those software updates have been, that’s not what we’re talking about today. In this post, we’ll take a look at one of the most exciting aspects of the new Bus Pirate — the ability to easily develop add-on modules for it.

Continue reading “Walking The Plank: Add-Ons For The Bus Pirate”

Hardware Bug In Raspberry Pi’s RP2350 Causes Faulty Pull-Down Behavior

Erratum RP2350-E9 in the RP2350 datasheet, detailing the issue.
Erratum RP2350-E9 in the RP2350 datasheet, detailing the issue.

The newly released RP2350 microcontroller has a confirmed new bug in the current A2 stepping, affecting GPIO pull-down behavior. Listed in the Raspberry Pi RP2350 datasheet (page 1340) as erratum RP2350-E9, it involves a situation where a GPIO pin is configured as a pull-down with input buffer enabled. After this pin is then driven to Vdd (e.g. 3.3V) and then disconnected, it will stay at around 2.1 – 2.2 V for a Vdd of 3.3V. This issue was discovered by [Ian Lesnet] of [Dangerous Prototypes] while working on an early hardware design using this MCU.

The suggested workaround by Raspberry Pi is to enable the input buffer before a read, and disable it again immediately afterwards. Naturally, this is far from ideal workaround, and the solution that [Ian] picked was to add external pull-down resistors. Although this negates the benefits of internal pull-down resistors, it does fix the issue, albeit with a slightly increased board size and BOM part count.

As for the cause of the issue, Raspberry Pi engineer [Luke Wren] puts the blame on an external IP block vendor. With hindsight perhaps running some GPIO validation tests involving pull-up and pull-down configurations with and without input buffer set could have been useful, but we’re guessing they may be performed on future Pi chips. Maybe treating the RP2350 A0 stepping as an ‘engineering sample’ is a good idea for the time being, with A3 (or B0) being the one you may want to use in actual production.

In some ways this feels like déjà vu, as the Raspberry Pi 4 and previous SBCs had their own share of issues that perhaps might have been caught before production.

(Note: original text listed A0 as current stepping, which is incorrect. Text has been updated correspondingly)

Hands On: Bus Pirate 5

If you’ve been involved with electronics and hardware hacking for awhile, there’s an excellent chance you’ve heard of the Bus Pirate. First introduced on the pages of Hackaday back in 2008 by creator Ian Lesnet, the open hardware multi-tool was designed not only as away to easily tap into a wide array of communication protocols, but to provide various functions that would be useful during hardware development or reverse engineering. The Bus Pirate could talk to your I2C and SPI devices, while also being able to measure frequencies, check voltages, program chips, and even function as a logic analyzer or oscilloscope.

Bus Pirate 3, circa 2012

The Bus Pirate provided an incredible number of tools at a hobbyist-friendly price, and it wasn’t long before the device became so popular that it achieved a milestone which only a few hardware hacking gadgets can boast: its sales started to get undercut by cheap overseas clones. Of course, as an open hardware device, this wasn’t really a problem. If other companies wanted to crank out cheap Bus Pirates, that’s fine. It freed Ian up to research a next-generation version of the device.

But it turns out that was easier said than done. It’s around this point that the Bus Pirate enters what might be considered its Duke Nukem Forever phase. It took 15 years to release the sequel to 1996’s Duke Nukem 3D because the state-of-the-art in video games kept changing, and the developers didn’t want to be behind the curve. Similarly, Ian and his team spent years developing and redeveloping versions of the Bus Pirate that utilized different hardware platforms, such as the STM32 and ICE40 FPGA. But each time, there would be problems sourcing components, or something newer and more interesting would be released.

But then in 2021 the Raspberry Pi Pico hit the scene, and soon after, the bare RP2040 chip. Not only were the vast I/O capabilities of the new microcontroller a perfect fit for the Bus Pirate, but the chip was cheap and widely available. Finally, after years of false starts, the Bus Pirate 5 was born.

I was able to grab one of the first all-new Bus Pirates off the production line in January, and have been spending the last week or so playing around with it. While there’s definitely room for improvement on the software side of things, the hardware is extremely promising, and I’m very excited to be see how this new chapter in the Bus Pirate story plays out.

Continue reading “Hands On: Bus Pirate 5”