@Dreg - do you have a BP5? That’s what I’ve been working with. I pulled the build down for BP5 from Github and it’s working for me.
I usually locally build my BP5 versions, but use Github actions to build the BP6/2350 versions. Let me post both builds here. Try the BP6 again. If you have a 5, please try that, too.
firmware-rp2040-ubuntu-latest.zip (7.4 MB)
firmware-rp2350-ubuntu-latest.zip (7.2 MB)
Anything I can do to help? Order someone a certain AVR board or anything?
I have a Bus Pirate 5 with an SD card — I’ll test it later. I’ll be back in about 3 hours, just let me know which firmware you want me to test and I’ll do it. Also, can you tell me the exact command line you’re using to read and write to small AVRs?
If this build doesn’t resolve it, I’ll order a dev board to test with.
Sorry for all the crap here; this should’ve been pretty straight forward.
No worries! I hate to see the struggle of remote debugging and if I can a****n someone a board to help Im happy to do it.
Try the 6 first; maybe it got corrupt along the way somewhere. If not, then the 5
For the smaller parts, I’m using:
$ avrdude -c buspirate -P /dev/ttyACM1 -p m328p -U flash:r:fullread.bin:r -B 125kHz
Great work on this! I reviewed the code, and (if I understood it correctly), I have some minor comments, but the overall structure is solid. And no apologies … this was complex to root cause, and more complex because it’s a cross-depot collaboration with AVRDude folk. Well done, indeed!
NOTE: There does seem to be a documentation requirement … since there’s now “hidden” state in the buspirate. Specifically, the documentation should state something like:
It is mandatory that, prior to reading or writing, the
0x30command is sent to read (at least) three bytes of data. This is to ensure proper behavior for >32k flash, without sending legacy devices new commands (which could break them).
Thanks @henrygab !
I addressed your comments in the PR, except for debug mode. I’ll get that before merge time. Please see if my updates addressed everything. 
Nice. I have a way to re-disable the extended address bytes, if someone connects a chip that doesn’t need it.
As for saying it’ll never happen … I’m not so sure. I have a bin of random AVRs, and I prefer not to power cycle my buspirate. I could see someone going through and archiving contents of a variety of parts, and thus going between <=32k and >32k parts.
At a higher level, this type of solution is a hack … it creates a “hidden variable” … and thus long term can create some difficult debugging situations, because this variable is hidden from the client and from the user, and persists between uses.
If you can re-initialize this variable to false when the interface is opened or initialized (not sure how it flows end-to-end), that would further mitigate the hidden variable, by ensuring a known starting state.
Similarly, I think the hack was done to allow existing (unmodified) AVRDude code to work. Is that correct?
If not, and AVRDude needed to be updated to work correctly, I’d have recommended having a command for the client to explicitly set whether the extended address is needed or not. Then, AVRDude would set this after it reads the signature byte (or however else it later figures out the command is needed). This avoids the hidden variable, and allows ownership of the hack to remain in a single location (AVRDude) … reducing long-term maintenance too.
This isn’t a mandatory change … just wanting to understand the reasons this hack was in buspirate code vs. in AVRDude.
I am aware of a few extensions in BBIO1 for avrdude, and this issue too of course. I’m curious why avrdude isnt generating generic code for SPI. Is it easier or less data intensive? Tradition based on manufacturers programmer designs?
Since (older) avr is basically spi shaped, why not spi transactions?
I didn’t say never, just unlikely 
I have thought of a solid way to handle resetting the flag between runs, so I’ll add that.
As far as 'dude goes; it just sends commands to the programming hardware interface - the BP in this case. Go get this many bytes starting from this address. It is up to the interface to handle the addressing properly - maybe it’s SPI/ISP, maybe it’s JTAG; the point is that 'dude is agnostic as far as those specifics go.
I think this problem goes back to the BP 3 - I’m not sure because I’ve always used an AVR Dragon with avrdude, but it seems so because there’s an old issue in their repo about it.
With all of that in mind, it’s my opinion that it’s entirely up to the Bus Pirate side to fix, and that’s what my proposal to the 'dude folks was about.
Again, I think it goes back to 'dude being more-or-less agnostic to the physical programming interface/emulator. Also, I don’t know who wrote the BP drivers for avrdude.
2232hio = 2232hio based on FT2232H with buffer and LEDs
4232h = FT4232H based generic programmer
adafruit_gemma = Adafruit Trinket Gemma bootloader disguised as USBtiny
arduino = Arduino for bootloader using STK500 v1 protocol
arduino-ft232r = Arduino: FT232R connected to ISP
arduino_gemma = Arduino Gemma bootloader disguised as USBtiny
arduinoisp = Arduino ISP Programmer
arduinoisporg = Arduino ISP Programmer
atmelice = Atmel-ICE (ARM/AVR) in JTAG mode
atmelice_dw = Atmel-ICE (ARM/AVR) in debugWIRE mode
atmelice_isp = Atmel-ICE (ARM/AVR) in ISP mode
atmelice_pdi = Atmel-ICE (ARM/AVR) in PDI mode
atmelice_tpi = Atmel-ICE (ARM/AVR) in TPI mode
atmelice_updi = Atmel-ICE (ARM/AVR) in UPDI mode
avr109 = Atmel for bootloader using AppNote AVR109
avr910 = Atmel Low Cost Serial Programmer
avr911 = Atmel for bootloader using AppNote AVR911 AVROSP
avrftdi = FT2232D based generic programmer
avrisp = Atmel AVR ISP
avrisp2 = Atmel AVR ISP mkII
avrispmkII = Atmel AVR ISP mkII
avrispv2 = Atmel AVR ISP v2
buspirate = The Bus Pirate
buspirate_bb = The Bus Pirate (bitbang interface, supports TPI)
butterfly = Atmel for bootloader (Butterfly Development Board)
butterfly_mk = Mikrokopter.de Butterfly for bootloader
bwmega = BitWizard ftdi_atmega builtin programmer
c232hm = C232HM cable from FTDI
c2n232i = serial port banging, reset=dtr sck=!rts sdo=!txd sdi=!cts
dasa = serial port banging, reset=rts sck=dtr sdo=txd sdi=cts
dasa3 = serial port banging, reset=!dtr sck=rts sdo=txd sdi=cts
diecimila = alias for arduino-ft232r
digilent-hs2 = Digilient JTAG HS2 (MPSSE)
dragon_dw = Atmel AVR Dragon in debugWire mode
dragon_hvsp = Atmel AVR Dragon in HVSP mode
dragon_isp = Atmel AVR Dragon in ISP mode
dragon_jtag = Atmel AVR Dragon in JTAG mode
dragon_pdi = Atmel AVR Dragon in PDI mode
dragon_pp = Atmel AVR Dragon in PP mode
ehajo-isp = avr-isp-programmer from eHaJo, http://www.eHaJo.de
flip1 = FLIP for bootloader using USB DFU protocol version 1 (doc7618)
flip2 = FLIP for bootloader using USB DFU protocol version 2 (AVR4023)
ft2232h = FT2232H based generic programmer
ft232h = FT232H based generic programmer
ft232r = FT232R based generic programmer
ft245r = FT245R based generic programmer
ft4232h = FT4232H based generic programmer
iseavrprog = USBtiny-based programmer, https://iascaled.com
jtag1 = Atmel JTAG ICE (mkI)
jtag1slow = Atmel JTAG ICE (mkI)
jtag2 = Atmel JTAG ICE mkII
jtag2avr32 = Atmel JTAG ICE mkII in AVR32 mode
jtag2dw = Atmel JTAG ICE mkII in debugWire mode
jtag2fast = Atmel JTAG ICE mkII
jtag2isp = Atmel JTAG ICE mkII in ISP mode
jtag2pdi = Atmel JTAG ICE mkII in PDI mode
jtag2slow = Atmel JTAG ICE mkII
jtag2updi = JTAGv2 to UPDI bridge
jtag3 = Atmel AVR JTAGICE3 in JTAG mode
jtag3dw = Atmel AVR JTAGICE3 in debugWIRE mode
jtag3isp = Atmel AVR JTAGICE3 in ISP mode
jtag3pdi = Atmel AVR JTAGICE3 in PDI mode
jtag3updi = Atmel AVR JTAGICE3 in UPDI mode
jtagkey = Amontec JTAGKey, JTAGKey-Tiny and JTAGKey2
jtagmkI = Atmel JTAG ICE (mkI)
jtagmkII = Atmel JTAG ICE mkII
jtagmkII_avr32 = Atmel JTAG ICE mkII in AVR32 mode
ktlink = KT-LINK FT2232H interface with IO switching and voltage buffers.
linuxspi = Use Linux SPI device in /dev/spidev*
lm3s811 = Luminary Micro LM3S811 Eval Board (Rev. A)
mib510 = Crossbow MIB510 programming board
micronucleus = Micronucleus for bootloader
mkbutterfly = Mikrokopter.de Butterfly for bootloader
nibobee = NIBObee
o-link = O-Link, OpenJTAG from www.100ask.net
openmoko = Openmoko debug board (v3)
pavr = Jason Kyle's pAVR Serial Programmer
pickit2 = MicroChip's PICkit2 Programmer
pickit4 = MPLAB(R) PICkit 4 in JTAG mode
pickit4_isp = MPLAB(R) PICkit 4 in ISP mode
pickit4_pdi = MPLAB(R) PICkit 4 in PDI mode
pickit4_tpi = MPLAB(R) PICkit 4 in TPI mode
pickit4_updi = MPLAB(R) PICkit 4 in UPDI mode
pkobn_updi = Curiosity nano (nEDBG) in UPDI mode
ponyser = design ponyprog serial, reset=!txd sck=rts sdo=dtr sdi=cts
powerdebugger = Atmel PowerDebugger (ARM/AVR) in JTAG mode
powerdebugger_dw = Atmel PowerDebugger (ARM/AVR) in debugWire mode
powerdebugger_isp = Atmel PowerDebugger (ARM/AVR) in ISP mode
powerdebugger_pdi = Atmel PowerDebugger (ARM/AVR) in PDI mode
powerdebugger_tpi = Atmel PowerDebugger (ARM/AVR) in TPI mode
powerdebugger_updi = Atmel PowerDebugger (ARM/AVR) in UPDI mode
serialupdi = SerialUPDI
siprog = Lancos SI-Prog <http://www.lancos.com/siprogsch.html>
snap = MPLAB(R) Snap in JTAG mode
snap_isp = MPLAB(R) SNAP in ISP mode
snap_pdi = MPLAB(R) SNAP in PDI mode
snap_tpi = MPLAB(R) SNAP in TPI mode
snap_updi = MPLAB(R) SNAP in UPDI mode
stk500 = Atmel STK500
stk500hvsp = Atmel STK500 v2 in high-voltage serial programming mode
stk500pp = Atmel STK500 v2 in parallel programming mode
stk500v1 = Atmel STK500 version 1.x firmware
stk500v2 = Atmel STK500 version 2.x firmware
stk600 = Atmel STK600
stk600hvsp = Atmel STK600 in high-voltage serial programming mode
stk600pp = Atmel STK600 in parallel programming mode
tc2030 = Tag-Connect TC2030
teensy = Teensy for bootloader
tigard = Tigard interface board
ttl232r = FTDI TTL232R-5V with ICSP adapter
tumpa = TIAO USB Multi-Protocol Adapter
um232h = UM232H module from FTDI
uncompatino = uncompatino with all pairs of pins shorted
urclock = Urclock programmer for urboot bootloaders using urprotocol
usbasp = USBasp, http://www.fischl.de/usbasp/
usbasp-clone = Any usbasp clone with correct VID/PID
usbtiny = USBtiny simple USB programmer, https://learn.adafruit.com/usbtinyisp
wiring = Wiring for bootloader using STK500 v2 protocol
xbee = XBee for Series 2 Over-The-Air (XBeeBoot) bootloader using STK500 v1 protocol
xplainedmini = Atmel AVR XplainedMini in ISP mode
xplainedmini_dw = Atmel AVR XplainedMini in debugWIRE mode
xplainedmini_tpi = Atmel AVR XplainedMini in TPI mode
xplainedmini_updi = Atmel AVR XplainedMini in UPDI mode
xplainedpro = Atmel AVR XplainedPro in JTAG mode
xplainedpro_pdi = Atmel AVR XplainedPro in PDI mode
xplainedpro_updi = Atmel AVR XplainedPro in UPDI mode
Interestingly enough, I see buspirate_bb in there - what does that do?
Either way, I guess I’m happy just making what I started with work. I’ve ordered a couple of dev boards (ATmega128 and an ATmega2560) to work with. It may be a bit before I get them and get it all worked out, but I think that’s probably OK for now.
@chickendipper - you can read your board using the BP6 version posted here: AVRDUDESS Flash dump error - #50 by Dreg
The only thing with that version is that it may fail on older AVR parts with flash size less than 64Kbytes.
As always, thanks everyone for your patience and great feedback!
Matt
Imagine the bb is the first raw pin manipulation mode (thus the name, BBIO=bit bang in out).
The whole BBIO1 was an ad-hoc hack.
I used BB01 with the 3 for “fuzzing” I2C EEPROMs when doing hardware pen tests. If I found an I2C EEPROM on the device, I’d pull all of the data out, then start writing different data to see what the product did. I had a nice Python script to work over BB01 to do it.
I got a really cool result doing that - one I can’t really still talk about, but imagine something along the lines of disabling pseudo-secure boot on an IIoT device 
firmware-rp2040-ubuntu-latest.zip (7.4 MB)
firmware-rp2350-ubuntu-latest.zip (7.2 MB)
My experience with this firm:
avrdude: Version 7.0
cmd used:
avrdude.exe -c buspirate -P COM4 -p m2560 -U flash:r:fullread.bin:r -B 125kHz
cmd used:
avrdude.exe -c buspirate -P COM12 -p m2560 -U flash:r:fullread.bin:r -B 125kHz
Cool! I’ll clean up some things as per @henrygab’s review comments when I get a chance tomorrow.
I’ll also have some “large” flash dev boards tomorrow, so I won’t need to bug you as much
I was out for a walk with some friends, thinking about this… and yeah, just as I suspected — the code from @mbrugman looked good, so I started to think the problem was elsewhere. And that was it: I nuked the flash on the RP2350, reinstalled all the software, and voilà! It works!
Something like this: raspberrypi-pico/blob/main/flash_nuke.uf2
Thanks for going the extra mile on that!
Sometimes going for a walk is the most productive thing one can do.
@mbrugman Please, When you have the final code for the PR ready, let me know — send me the final .uf2 files and I’ll test them, and then it should be ready to merge.
Yay! Got this cleaned up and working as desired - it will correctly detect flash size and apply the Extended High Byte address command appropriately. Also, it will allow a user to swap between parts with different flash size (above & below 64K) without having to reset the BP.
I swapped back and forth soooo many times, lol
@Dreg - here are the two version. I tested here with my BP5 on both a 328p and 2560 dev board (which I just got today!). Here are the BP5 and '6 versions if you’d like to confirm:
firmware-rp2040-ubuntu-latest.zip (7.3 MB)
firmware-rp2350-ubuntu-latest.zip (7.1 MB)
@henrygab - I’ve made what I hope are the final pushes to the PR; can you review the updated comments and setting/clearing of req_EHB_write one more time?
Once again, thanks everyone for the help and patience!
Matt
