Remotely handling bus pirate v5

General
1

Hello! I’m using bus pirate v5. I have upgraded FW to the version (791a21a (Jan 21 2025 14:12:21):

Bus Pirate 5 REV10
https://BusPirate.com/
Firmware main branch @ 791a21a (Jan 21 2025 14:12:21)
RP2040 with 264KB RAM, 128Mbit FLASH

I intend to use the BP remotely so I won’t have physical access to it once I have all the connections are set up.

Now I’m connected to the serial console and somehow I enter into self test mode which is stuck unless I press the button. This is not so strange as ~ character seldom appears on the console on arrow or other non-printable keys.

The thing is that when button is expected, there is no way, at least that I know of, for recovering control on console and on BP.

I wonder if sending special command on the binary port or mounting/unmounting the associated mass storage device could help here.

Hints are appreciated. Thanks!

2

It’s not going to be a bus pirate solution, but we’ve used switchable USB ports in the past to ensure we cut power with these types of devices for a hard reset. The reason being that it the best way to ensure you’re really able to reset the power for a duration of time as opposed to relying on the target test hardware (the BP) to have the ability in the event of the same sort of thing you’re hitting.

I’m not sure if there’s a watchdog that’s accessible where you could trip based on lack of input to the serial interface after some amount of time. The issue you’d run into is that now whatever you’re testing need to keep petting the watchdog.

4 Likes
3

image
image657×244 3.73 KB

Both Press and Release button steps can now be skipped with any key. The firmware should post shortly.

4 Likes
4

Thank you everybody.

@ian thank you for the (really) quick fix. I have upgraded FW to the latest master and the autotest exits properly.

@wyattearp I also use a “(de)powerable” usb hub, whose ports I can control via uhubctl tool. In my experience not always a proper power cycle is possible.

Besides this, the workaround already in git possibly addresses the most frequent BP control problem, anyway when I opened this thread I was thinking in some kind of out-of-band mechanism for managing the BP. I admit the proposal is not specific enough. I may bump-in in case I have something more practical.

Regards!

1 Like