AVRDUDESS Flash dump error

chickendipper · July 6, 2025, 1:56pm

I get the following error when trying to dump the flash of an atmega128 chip:

attempting to initiate BusPirate binary mode …
Paged flash write enabled
Reading flash memory …
Reading | #################################################- | 99% 158.54s
Error: paged read command returned zero.

Dumping the EEPROM works fine, I’ve tried on another chip and managed to dump both flash and EEPROM. Has anyone run into this issue before? I’ve only found a handful of threads on it and I can’t seem to find a difinitive answer to what this issue is other then maybe there’s an issue with the buspirate firmware. Any help would be great

Thanks

ian · July 6, 2025, 2:08pm

It seems like it’s getting to the end and the final transaction is aborted. Does it actually save anything even though it aborts? If so, how big is the dump file? Maybe one page shorter than expected?

chickendipper · July 6, 2025, 2:12pm

No it doesn’t save anything unfortunately. The dump file is 0kb with nothing inside. Still waiting on another board with the same chip to see if I get the same error.

chickendipper · July 6, 2025, 2:40pm

There’s mention of the error here: [bug #51614] BusPirate: Paged Read command returned zero. With m1284p flash. · Issue #459 · avrdudes/avrdude · GitHub

He also gets to 99% and then gets the same error

They claim that the bus pirate has issues dumping flash data over 128kb (the atmega is 128) and suggest moving to STK500v2 firmware, that firmware is 16 years old though and I’m using the Bus pirate 6

ian · July 6, 2025, 3:51pm

Interesting. The bug report is about the old hardware and firmware. @dreg wrote the legacy support binmode, so maybe the big was copied over as well lol.

Are you able to get the verbose output mentioned in the bug report and paste it here?

chickendipper · July 6, 2025, 5:09pm

Avrdude version 8.0
Copyright see avrdude/AUTHORS at main · avrdudes/avrdude · GitHub

System wide configuration file is C:\Program Files (x86)\AVRDUDESS\avrdude.conf

Using port : COM13
Using programmer : buspirate
Setting baud rate : 115200
AVR part : ATmega128
Programming modes : SPM, ISP, HVPP, JTAG, JTAGmkI

Memory Size Pg size

eeprom 4096 8
flash 131072 256
lfuse 1 1
hfuse 1 1
efuse 1 1
lock 1 1
prodsig/sigrow 24 1
sernum 10 1
io 224 1
sram 4096 1
calibration 4 1
signature 3 1

Variants Package F max T range V range

ATmega128-16AN TQFP64 16 MHz [-40 C, 105 C] [4.5 V, 5.5 V]
ATmega128-16ANR TQFP64 16 MHz [-40 C, 105 C] [4.5 V, 5.5 V]
ATmega128-16AU TQFP64 16 MHz [-40 C, 85 C] [4.5 V, 5.5 V]
ATmega128-16AUR TQFP64 16 MHz [-40 C, 85 C] [4.5 V, 5.5 V]
ATmega128-16MN MLF64 16 MHz [-40 C, 105 C] [4.5 V, 5.5 V]
ATmega128-16MNR MLF64 16 MHz [N/A, N/A] [4.5 V, 5.5 V]
ATmega128-16MU MLF64 16 MHz [-40 C, 85 C] [4.5 V, 5.5 V]
ATmega128-16MUR MLF64 16 MHz [-40 C, 85 C] [4.5 V, 5.5 V]
ATmega128L-8AN TQFP64 8 MHz [-40 C, 105 C] [3 V, 5.5 V]
ATmega128L-8ANR TQFP64 8 MHz [-40 C, 105 C] [3 V, 5.5 V]
ATmega128L-8AU TQFP64 8 MHz [-40 C, 85 C] [2.7 V, 5.5 V]
ATmega128L-8AUR TQFP64 8 MHz [-40 C, 85 C] [2.7 V, 5.5 V]
ATmega128L-8MN MLF64 8 MHz [-40 C, 105 C] [3 V, 5.5 V]
ATmega128L-8MNR MLF64 8 MHz [N/A, N/A] [2.7 V, 5.5 V]
ATmega128L-8MU MLF64 8 MHz [-40 C, 85 C] [2.7 V, 5.5 V]
ATmega128L-8MUR MLF64 8 MHz [-40 C, 85 C] [2.7 V, 5.5 V]

Programmer type : BusPirate
Description : The Bus Pirate in AVR programming mode
attempting to initiate BusPirate binary mode …
BusPirate binmode version: 1
BusPirate SPI version: 1
Paged flash write enabled
AVR Extended Commands version 1

AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.01s
Device signature = 1E 97 02 (ATmega128, ATmega128A)
Reading flash memory …
Reading | #################################################- | 99% 158.59s
Error buspirate_paged_load() buspirate.c 952: paged read command returned zero

Dreg · July 7, 2025, 3:40am

I’m going to take advantage of this moment and talk to the AVRDude devs to see how we can support more families in the simplest way possible for both sides.

Dreg · July 7, 2025, 8:52pm

Issue opened—let’s see what we can do. Fingers crossed!

github.com/avrdudes/avrdude

Add support to the Bus Pirate for larger flash chips

opened 08:48PM - 07 Jul 25 UTC

therealdreg

Hi! I want to add support for larger flash chips to the modern Bus Pirate. I’ve …opened this issue to coordinate with you on the best way to do it #459 https://github.com/avrdudes/avrdude/blob/main/src/buspirate.c#L989 btw, this is the modern bus pirate <img width="488" height="433" alt="Image" src="https://github.com/user-attachments/assets/3b09290a-e925-48a5-9584-45a92f812dd5" /> https://docs.buspirate.com/docs/software/avrdude/ I’ve added support by porting all the code from Bus Pirate v3 and it’s already working! But now I want it to work with AVRDude for larger flash chips—what would be the best way to do that? Let me know what you’d like me to change in the firmware and I’ll update it. Maybe the simplest solution is for me to send you a new version number here, for example: `CDC_SEND_STR(1, "\x02\x00\x01");` — and when that happens, you can send me new commands to read larger flash chips. Please let me know what you want me to modify in that file so everything is as simple as possible. https://github.com/DangerousPrototypes/BusPirate5-firmware/blob/main/src/binmode/legacy4third.c#L657 ---- <img width="833" height="803" alt="Image" src="https://github.com/user-attachments/assets/1c1dd341-a956-4db5-b70d-50eaca9bb034" /> ------ @mcuee @MCUdude Do you want me to send you a modern Bus Pirate as a gift so you can test the new releases, like we did in issue #1616 ?

chickendipper · July 7, 2025, 9:24pm

Thankyou very much for the quick reply. Happy to help in anyway I can going further in terms of dumping flash/eeprom memory from atmega chips as well as testing both the buspirate and avrdude software.

Dreg · July 9, 2025, 11:49am

Good news @chickendipper ! I’m already working on this with the AVRDude developers to see if we can get it fixed. I’m going to buy an AVR like the one you have and see how it goes… (see the GitHub issue)

Dreg · July 9, 2025, 11:54am

Purchased! I should have the board at home in about a month.

ian · July 9, 2025, 12:06pm

Given 32K vs 128K of flash, I would look for a uint16_t is being used where a uin32_t is needed. Just a wild guess without knowing anything going on under the hood.

chickendipper · July 9, 2025, 2:25pm

Sweet, It’s the same board I ordered. Should be coming in the next couple of days

mbrugman · July 9, 2025, 2:34pm

Just jumping in here… I’ve done a lot of AVR c and assembly, but I’ve never looked under the hood of AVRDude (just used it )

The AVR uses word addressing for flash, so a uint16_t will address all flash, regardless of variant or flash size. For the larger flash variants, it is still 16-bit word addressing, but there is a register called rampz used to select the bank. I remember using it when writing a custom bootloader on the ATMega256 device.

I also used the Z pointer with the SPM/LPM when using the flash to store large fixed data structures. I think avr-gcc has PROGMEM or something to do this for you.

From the ATMega datasheet:

This all applies to “self programming” - programming “main” flash area from “bootloader” flash area. According to the datasheet, JTAG/ISP programming uses the same thing - select the write address sending the extended byte (rampz register), then the high byte (ZH/R31), then the low byte (ZL/R30). The only thing I’m not sure of is what DUDE is doing? Does it send a 32-bit address and leave it up to the programming device to break that into the 3 registers?

Anyway, I don’t mean to confuse the issue; just refreshing my brain on this and maybe helping

Dreg · July 9, 2025, 2:37pm

@mbrugman take a look!

github.com/DangerousPrototypes/BusPirate5-firmware

src/binmode/legacy4third.c

main


      
          }
          switch (op_byte) {
              case 0x00:
                  if (binmode_debug) {
                      printf("\r\nAVR NOOP");
                  }
                  CDC_SEND_STR(1, "\x01");
                  break;
          
              case 0x01:
                  if (binmode_debug) {
                      printf("\r\nAVR VERSION");
                  }
                  CDC_SEND_STR(1, "\x01\x00\x01");
                  break;
          
              case 0x02:
                  if (binmode_debug) {
                      printf("\r\nAVR BULK READ");
                  }

github.com/avrdudes/avrdude

src/buspirate.c

main


      
            // Return if we are not in binary mode
            return -1;
          }
          
          if(my.flag & BP_FLAG_NOPAGEDWRITE) {
            // Return if we've nominated not to use paged writes
            return -1;
          }
          
          if(page_size > 1024) {
            // Page sizes greater than 1kB not yet supported
            return -1;
          }
          
          if(!str_eq(m->desc, "flash")) {
            // Only flash memory currently supported
            return -1;
          }
          
          // Pre-check opcodes
          if(m->op[AVR_OP_LOADPAGE_LO] == NULL) {

github.com/avrdudes/avrdude

[bug #51614] BusPirate: Paged Read command returned zero. With m1284p flash.

opened 12:22AM - 11 Dec 21 UTC

closed 05:03AM - 03 Jun 23 UTC

avrs-admin

enhancement

Aaron <avrdude@fgthou.se> Sat 29 Jul 2017 01:35:58 PM UTC Programmer hardware: B…usPirate Verbose output: [https://gist.github.com/mcd1992/c9bb57071a8db5bf77d07c8a2e60c8df](https://savannah.nongnu.orghttps://gist.github.com/mcd1992/c9bb57071a8db5bf77d07c8a2e60c8df) Let me know if anymore information is needed, thanks. This issue was migrated from https://savannah.nongnu.org/bugs/?51614

ian · July 9, 2025, 2:40pm

From a quick glance, the code does not seem to deal with load extended address byte command which is needed by m1284p and it should have the same problem for ATmega2560 and similar parts.

Comment on that thread seems to be what mbrugman writes about above. Internally AVR dude has a uint32_t or larger address counter, which the Bus Pirate code then needs to send the lower 16 bits + the 2 Z selection bits.

Dreg · July 9, 2025, 2:58pm

@mbrugman So the issue could be coming from not handling the RAMPZ register?

mbrugman · July 9, 2025, 2:59pm

That would make sense…. Still looking at the code you mentioned me in

mbrugman · July 9, 2025, 3:09pm

@Dreg - take a look at line 684 of legacy4third.c

Do you want to compare to 0x2ffff instead of 0xffff?

Ugh, just stepped away from computer; trying to review code on a mobile device sucks for an old man

Dreg · July 9, 2025, 3:11pm

That code you’re seeing is a quick-and-dirty port I did from the original Bus Pirate v3 code… I’m not really sure why they added so many things in there, haha.

Anyway… if one extra byte per operation is needed, AVRDude should have no problem—it can just send 3 bytes by tricking the len, right?