For whatever it’s worth @Dreg - I got my BP6 today and was able to test with my dev boards. Still funky on the 32u4 boards - one needed to be USB powered and the others didn’t. 
1 Like
@mbrugman What do you think it could be? 
I’m about to hook up the oscilloscope — I’ve got a Z0 probe and a FET probe lying around here…
I really have no idea what is happening with this. Kind of crazy, but I’m guessing it’s just some characteristic of the u4 family.
1 Like
Firmware in last two weeks could lockup the USB CDC queues.
I have a PR that fixes that (very small change). Might be worth integrating that fix for your tests…
3 Likes
I did see a CDC lockup when I was testing with my 6, but I don’t think it’s related to the specific xxu4 avrdude issue.
I’ll retest later, but the symptom here is that a specific target for binmode/avrdude behaves differently than other target avrs.
1 Like
The fix is in main now and it seems to fix the freezing I’ve seen.
2 Likes
I pulled from main and rebuilt both BP 5 & 6. Still have the same goofiness with the xxu4 chips, but no freezing.
3 Likes
Hi everyone! I’m one of the Avrdude maintainers, and recently received a Bus Pirate 6 donated to me for Avrdude testing purposes.
I have practically no experience with the Bus Pirate, so these thoughts are from a mostly spotless mind.
First, I’m very pleased with the hardware and packaging! It feels like a very solid product. The next step for me was to try to figure out what the difference was between the Bus Pirate 5, 5XL, and 6. Google took me to this page, with a highlighted message saying that this page is no longer maintained, but the new page doesn’t mention the hardware differences at all. And despite the different RP chips, the real question is, what difference does it actually make? Is the v6 so much better that it’s worth replacing your RP2040-based v5? I, as a new user, don’t know this, and it took more time than expected to find this information.
Following the Bus Pirate Avrdude guide was pretty straightforward, but it’s a bit annoying that it’s not possible to make this mode “stick” after I unplug it. If this should be a convenient AVR programmer, it should “just work” with Avrdude, without any special setup sequence to work, just like the v3 and v4. I understand that you would have to manually enter “Avrdude mode”, but couldn’t it stay in this mode after a power cycle? You could instead exit “Avrdude mode” by pressing the button multiple times.
Apeaking of Avrdude, I’ve done some tests.
I’m able to read and write to the ATmega1284P’s flash memory without any issues, and the speed is acceptable if I tweak the spifreq setting.
Read the entire ATmega1284P flash memory
$ avrdude -cbuspirate -P /dev/cu.usbmodem6buspirate3 -patmega1284p -Uflash:r:-:I -xspifreq=2
attempting to initiate BusPirate binary mode ...
Paged flash write enabled
Reading flash memory ...
Reading | ################################################## | 100% 29.86 s
Writing 131072 bytes to output file <stdout>
:200000007FCF7572FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC7 // 00000> .Our............................ flash
:20002000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE0 // 00020> ................................
[...]
:20FE6000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFA2 // 1fe60> ................................
:20FE8000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF82 // 1fe80> ................................
:20FEA000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF62 // 1fea0> ................................
:20FEC000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF42 // 1fec0> ................................
:20FEE000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF22 // 1fee0> ................................
:20FF0000112424B614BE80E04AD021FEAFC08EE046D0E0ECF0E0AFE7BFEF4899FECF9096C0 // 1ff00> .$$6.>.`JP!~/@.`FP`lp`/g?oH.~O..
:20FF2000489BFDCFB4831197F1F7B2E0B083B8E1B18324D0823069F42BD0A0E0B1E01ED0BC // 1ff20> H.}O4...qw2`0.8a1.$P.0it+P `1`.P
:20FF40008D93A030E1F7B15030D03AD08EE80FD0F0CF833041F41CD0C82F27D0879107D009 // 1ff40> .. 0aw1P0P:P.h.PpO.0At.PH/'P...P
:20FF6000C150E1F7F3CF8230F0F31FD0EFCF9091C00095FFFCCF8093C60008958091C0000D // 1ff60> APawsO.0ps.PoO..@...|O..F.....@.
:20FF800087FFFCCF84FD14C0A8958091C6000895F5DFE82FF3DFF82FF1DF8BBFEFCF98E1D5 // 1ff80> ..|O.}.@(...F...u_h/s_x/q_.?oO.a
:20FFA00090936000809360000895E8DF803219F088E0F5DFFFCF80E2DACF6BBFFA01DC0115 // 1ffa0> ..`...`...h_.2.p.`u_.O.bZOk?z.\.
:20FFC000E0707A2F6BB7FF3F81E0680790F483E00BD081E00D901D9007D03296A713FACF69 // 1ffc0> `pz/k7.?.`h..t.`.P.`.....P2.'.zO
:20FFE000F15085E001D081E187BFE89517B610FCFDCF11240895FFFFFFFF011BDECF844065 // 1ffe0> qP.`.P.a.?h..6.|}O.$........^O.@
:00000001FF
Avrdude done. Thank you.
Write urboot bootloader to the last part of the ATmega1284P
$ avrdude -cbuspirate -P /dev/cu.usbmodem6buspirate3 -patmega1284p -Uurboot:autobaud
attempting to initiate BusPirate binary mode ...
Paged flash write enabled
Reading 256 bytes for flash from input file urboot:autobaud
Writing 256 bytes to flash
Writing | ################################################## | 100% 1.56 s
Reading | ################################################## | 100% 0.93 s
256 bytes of flash verified
Setting fuses for bootloader urboot:autobaud
Avrdude done. Thank you.
All in all, the programmer works well with Avrdude (8.1), but it would be neat if it could stay in Avrdude mode after a power cycle.
2 Likes
Thank you for your testing and confirmation of our fixes!
As far as 5 versus 6, the 6 has more flash and is a bit faster, but at the moment they both have the same basic functionality.
The documentation is always improving, but thanks for the feedback.
It’s kind of a Swiss army knife or multi tool; it always powers up in high impedance mode, so it won’t affect anything it might be connected to until specifically set to another mode.
Again, I’m in a long time avrdude user, and have been really happy with it. I appreciate the help with this issue, and everything the team does 
2 Likes
Thanks so much for the tests and the quick feedback @MCUdude! It’s been less than 24 hours since we emailed!
To add to what @mbrugman already mentioned — the legacy binary mode comes from the older Bus Pirate versions like the v3, which were PIC-based and completely different…
What we’ve implemented feels more like an “emulation mode,” which was initially meant as a temporary workaround while @ian and the dev community work on designing a new binary interface for the modern Bus Pirates (and they’ve actually made a lot of progress — but it’s still a work in progress).
I totally get where you’re coming from and why you’d suggest it, but that COM port is used for other things too — to other modes, etc.
And I see flashrom and avrdude as occasional use cases, so I don’t really see it as a priority to have all of that active by default after a reboot… Because then what do we do about the other use cases? We’d be creating “second-class citizens,” so to speak
If you do any more tests or have any suggestions for improvements, please let us know in this post — we’ll definitely take it into account.
2 Likes
those that need it often can use the button macro to quickly switch into the binmode
2 Likes
@MCUdude - thank you so much for trying out the Bus Pirate and taking your time to give feedback.
I’ll push an updated comparison to the new docs this week. We just finished the first volume production of 6 (what you received) and I’m a bit behind on the docs.
I can make the mode sticky, that’s no issue. Some modes are already sticky, it’s just an option configured for the mode. I believe one issue is that @dreg allows you to configure the power supply before entering the mode, so we’ll address that. The other is a way to exit the mode because it locks the terminal side serial port - I have a few schemes to address this as well.
As dreg noted, currently avrdude is supported through an emulation layer that pretends to be the old v3.x hardware. A much nicer flatbuffer interface for controlling most aspects of the Bus Pirate is already in place, but not yet finalized. It’s fairly trivial to control most of the hardware: 1-5v supply, LEDs as indicators, pin manipulation and of course SPI transactions.
Looking over AVRDUDESS project it seems like you use the avrdude.exe directly. So I need to have a look at AVRDude to add support for the new interface. AVRDude is C, and I already have working C tooling so implementation should be fairly easy assuming I can get the project setup and compiling. I’ll have a look at this after I push the “final draft” specs and python library later this week.
2 Likes
Thanks for donating the Bus Pirate! I have lots and lots of various AVR hardware, and I’ll keep it in my “test cycle” when we release new Avrdude versions.
I can only speak for Linux and MacOS users, but it’s very easy to compile Avrdude yourself. There is a wiki that can help you get started.
I have no experience with AVRDUDESS, but Avrdude is under active development mode, and we’ll accept new programmer protocols if you’re planning to start from scratch. The current BP implementation only supports ISP (and TPI?) targets, while all new AVRs use UPDI, which is just a half-duplex UART-based protocol (8E1 I think) over a single wire.
It would, of course, be amazing if the new Bus Pirate v5/6 supported “modern” AVRs with UPDI, and perhaps old AVRs with JTAG as well, but, like everything else, this requires a lot of time and effort.
2 Likes
So once the new binary mode is ready and we see that everything is stable, we’ll take the opportunity to add support in the new AVRDUDE driver for as much as we can — not just SPI programming. It’d be great to support ISP, UPDI, JTAG, PDI, and TPI too…
I’m so sorry, I misunderstood. I don’t know why I thought that. It’s not even consistent with the testing you posted… I must have been a bit out of it.
I’ve been using WSL (Ubuntu on Windows) to compile with amazing success, I’ll try out AVRdude now.
ETA: Build worked out the the box! Nice!