Bad EEPROM dump with avrdude from ATmega328p using Adafruit 'Arduino as ISP' programmer

Go To Last Post
11 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am trying to get some feedback to verify this bad EEPROM dump from ATmega328p with avrdude 6.3 and 6.3-20171130. I'll be compiling the latest branch and update my observation later.

 

Test code as follows:

#include <avr/io.h>
#include <avr/eeprom.h>

int main(void) {
    uint16_t data=0;

    for (uint16_t i=0; i<1024; i++) { 
        eeprom_write_word((uint16_t *) i, 0xff);
    }

    for (uint16_t i=0; i<512; i+=0x20) {
        eeprom_write_word((uint16_t *) i, data);
        data += 0x11;
    }

    for (uint16_t i=0; i<512; i+=0x20) {
        data = eeprom_read_word((uint16_t *) i);
    }

    return(0);
}
 

The content of EEPROM is GOOD when

  1. Serial printing from the code
  2. Use avrdude terminal (-t) mode to dump i.e. dump eeprom 0x100 10

The content is BAD when I dump the EEPROM content to a file, the data seems to repeat itself at the 256 boundary i.e. 0x100, 0x200, 0x300. The EEPROM dump file is attached.

 avrdude -c stk500v1 -p m328p -P /dev/ttyUSB0 -b 19200 -U eeprom:r:dump.hex:i

I have only seen a similar report bug #61169 for mega2560 using an unspecified custom programmer 

 

UPDATE: 1. Change ArduinoISP to 'Arduino as ISP'

Attachment(s): 

This topic has a solution.

-xource-

Last Edited: Tue. Jun 14, 2022 - 05:34 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Still facing the same bad EEPROM problem when using avrdude Version 7.0-20220610 (cb11423) from upstream/main 

-xource-

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Go on.  You are mixing up uint8_t and uint16_t.

 

#include <avr/io.h>
#include <avr/eeprom.h>

int main(void) {
    uint16_t data=0;

    for (uint16_t i=0; i<1024; i++) { // erase all 1024 bytes
        eeprom_write_byte((uint16_t *) i, 0xff);
    }

    for (uint16_t i=0; i<512; i+=0x20) { // 0x0000, 0x0011, 0x0022, ..., 0x00FF
        eeprom_write_word((uint16_t *) i, data); // at byte locations 0x0000, 0x0020, 0x0040, ..., 0x01E0
        data += 0x11;                    // byte locations 0x0200 - 0x03FF are untouched
    }

    for (uint16_t i=0; i<512; i+=0x20) {
        data = eeprom_read_word((uint16_t *) i); // should read 0x0000, 0x0011, 0x0022, ..., 0x00FF
    }

    return(0);
}

 

Untested.  But you should be able to view in the Simulator.

 

When you wrote

    for (uint16_t i=0; i<1024; i++) { // erase all 1024 bytes
        eeprom_write_word((uint16_t *) i, 0x00ff);
    }

You would effectively write 0xFF in each byte except for 0x00 in location 0x0000 where it has wrapped round.

i.e. you get almost what you intended but in the wrong way.

 

Untested.   I will let you try it for yourself.

 

Ah-ha.  I just looked at your hex dump.   How did you get that ?

The AS7.0 Simulator produces everything as expected.   (note that words are stored little-endian)

 

David.

 

p.s. I might try your program out on a real-life ATmega328P

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was actually trying to store two byte data in a word but this does not affect the second and third loops. The issue was NOT about what was written or read from the ATMega328p EEPROM as I mention in my post. It is working as expected. 

The problem is with the hex dump from avrdude as you can see from the attached file.

-xource-

Last Edited: Sun. Jun 12, 2022 - 12:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are you concerned about avrdude or just ArduinoISP ?

 

I can't believe that avrdude has a problem with reading the EEPROM.

After all,  avrdude has been in use for many years.

I guess that ArduinoISP users seldom do more than a Blinky.   And if they do it seldom contains EEPROM.

 

ArduinoISP.ino source code comes with every Arduino installation.

It looks ok.  But I will not bother trying it until you confirm your concerns.

Of course avrdude has recently undergone "changes".

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Initially I have the same assumption. However, I have verified that there was a misconfiguration in avrdude that cause the problem. This affects the older and latest version of avrdude. I have filed a new issue #990 upstream. 

 

For those interested in a quick fix, you can remove the offending lines in the ATmega328 eeprom section in avrdude.conf 

 

```

memory "eeprom"
paged        = no;
page_size    = 4;        #REMOVE this line

num_pages = 256;#REMOVE this line
size        = 1024;

```

 

My dump file is now GOOD.

Attachment(s): 

-xource-

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Most conf files have:   (I am looking at historic Arduino conf files)

 

    memory "eeprom"
    paged        = no;
    page_size    = 4;
    size        = 1024;

 

So I suspect you just need to remove the num_pages entry.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrdude and/or stk500v1 DO have some problems with EEPROM.  See:

https://github.com/Optiboot/opti...

https://github.com/avrdudes/avrd...

I thought these were inconsistencies about whether EEPROM is addressed as bytes or as words; I'm not sure if they'd manifest as the problem you are seeing.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, most conf files have page_size entry. However, there are instances in the repo where I came across num_pages.

 

Based on my observation removing page_size solved my problem.

-xource-

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the links. These might be related i.e. byte-based or word-based addressing.

 

For now, this is beyond my simple project to save data in EEPROM and dump them on my PC :) I will have a look after I sort out my project stuff

-xource-

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Updates on this issue

  1. I have tracked the actual cause of the bad EEPROM dump. I have used a version of the 'Arduino as ISP' from Adafruit here instead of the official Arduino here
  2. The Adafruit 'Arduino as ISP' does NOT properly handle word-based address when reading/writing eeprom causing it to repeat at 256 boundary.

 

EDIT: Change the post title for clarification

-xource-