Verification Error when programming from Raspberry Pi (avrdude with linuxgpio bitbang)

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

Hello,

 

I am trying to program an Atmega2560 chip using a raspberry pi. From the command line I am using the command:

 

```

sudo avrdude -p m2560 -C ~/AVR/gpio_config/cable1/cable_1.conf -c cable_1 -v -U flash:w:/home/pi/AVR/gpio_config/cable1/MP_US_6-7.hex:i

```

The writing process completes but the verification process always returns an error. 

 

 


 

Using AVR Studio Version 7, I attempted to verify the flash and also get the same error:

 

 


 

If I program the Atmega2560 with the same firmware file from AVR Studio it writes and verifies with no errors.

 

I have verified the fuse bits and lock bit. The file is 152912 bytes. On the following site, http://www.nongnu.org/avrdude/us..., there is a note related the the Atmega2560 version that flashing above 128kb is not supported by all programming hardware. I was hoping the linuxgpio would fall under the "known to work...bit banger" classification.

 

 

 

I am powering the 2560 from an external source and have verified this response on multiple 2560 chips.

 

Any ideas?

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

smbrandonjr wrote:
... there is a note related the the Atmega2560 version that flashing above 128kb is not supported by all programming hardware.
There's a defect :

bug #46843: avrdude=>6 fails to write from 128k-mark onwards, loops back to 0x0000

with a possible patch :

bug #51117: Problems with extended address (>128K) and buffer size


http://savannah.nongnu.org/bugs/?group=avrdude

 

"Dare to be naïve." - Buckminster Fuller

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

Thanks for pointing me to this. Dumb question coming up but if I install avrdude via apt-get, I am unable to find the butterfly.c file in order to make the changes I need to make. If I compile and manually install avrdude then I run into other issues that don't allow me to properly flash.

 

Any idea where the butterfly.c file is kept? I have tried locate butterfly.c, dpkg -l avrdude as well as few others...no luck.

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

"Dare to be naïve." - Buckminster Fuller

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

I found another firmware file from this manufacturer that is only 11kb and am getting the same type of error, a verification error. 

 

When I compile a file from arduino for example and use avrdude to flash it, it succeeds. 

 

So it seems my issue is not related to flash size.

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

In still trying to troubleshoot this...I was investigating the original .hex file versus the file that is created when I read the flash. I noticed that the original file is intel hex and has 16 data bytes while the read file shows 32 data byte instructions. I am trying to understand why this may be? 

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

My apologies as I am learning as I go but I have taken a look at the area where avrdude is alerting of the verification error. The picture attached is of the Intel hex file that I am flashing. All of the other lines have 16 bytes of data where this line has 11.

Attachment(s): 

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

Here is the read of the flash and you can see instead of x00 at x40ca, avrdude wrote xFF.

Attachment(s): 

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

In a normal Debian style repository that uses apt-get you "apt-get install foo" to install the "foo" package and you "apt-get source foo" to get the source code that was used to build what was in the package.

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

Thank you clawson. I was able to manually install 6.3. r1388 had the fixed linuxgpio.c code I needed to get it working on my raspberry pi.

Now I am trying to figure out why avrdude linuxgpio is writing 00 as FF.

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

I believe I have found a common theme in my verification error.

 

I am running into a verification error when using avrdude from the terminal of a raspberry pi only when the data byte count of a line in the intel hex file is less than 0x10 AND the data contains 0x00. In this scenario, avrdude appears to write 0xFF rather than 0x00.

I am programming an Atmega2560 and I ave verified this behavior with 3 different intel hex files. Two of the hex files are distributed by a 3rd party vendor and I have no insight or control over them. The third file I verified this on is the arduino provided "blink" sketch where I modified the third from last hex line of the file so that the data byte count would be less than 0x10. 

Original line: :1005C000FF1F881F8BBF0790F691E02D1994F894B8
Modified to:  :0F05C000FF1F881F8BBF0790F691E02D19940045

Read after avrdude flash: :1205C000FF1F881F8BBF0790F691E02D1994FFFFFFCF76

Verification error: first mismatch at byte 0x05ce, 0xff != 0x00

I do want to note that I can successfully flash the atmega2560 with this setup when the described scenario above is not met. I also have opened this issue with the official avrdude site, http://savannah.nongnu.org/bugs/... , but have not had any response yet.

I have attached my modified "blink" hex file.

Attachment(s): 

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

Here is verbose output when flashing this blink-2560-mod file. It looks like the bitbang command is writing 00 but during the read, FF is being read.

 

Writing:

 

 

Reading:

 

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

In further news, I have found that my issue is more specifically associated to the last data byte in the line when the byte count is less than 0x10. So for example, if the byte count is 0x09 and the last data byte before the checksum is anything but FF, I will get a verification error. If I modify the line so that the last data byte is FF (and change the checksum to be correct), the flash will verify correctly.

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

As you can build avrdude from source you should be able to add debug to it after it has done the hex decode to verify that's done correctly

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

clawson,

 

Thank you for the troubleshooting recommendation. 

 

I added two print statements in the fileio.c file in the ihex_readrec() function, one to print the "load offset" value and one to print the "data" values.

 

Now when I flash my chip I can see this output and I have verified that what is being printed out matches my intel hex file. 

 

Intel hex file line: 

 

 

My debug printout:

 

 

Is this what you meant by debugging what avrdude is doing with the hex code?

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

Yup. You seemed to be concerned that avrdude was not decoding the hex correctly. I was simply saying you could add code to check that it was. The above seems to suggest it is.

 

So if the verify fails on the last byte of a record that maybe suggests you need to add some debug to the point where it does the verify read.

 

Of course you may just find the avrdude -v-v-v-v output already contains the data you need to see.

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

clawson wrote:

Of course you may just find the avrdude -v-v-v-v output already contains the data you need to see.

 

I do believe that avrdude shows me the data with the verbose output. In my post #12 above you can see the bitbang_cmd() output for writing and reading on the line I am experiencing this issue with. 

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

I have analyzed the writing from both avrdude and using Atmel Studio v7 using a logic analyzer.

 

At the memory location that I am experiencing my verification error: It looks like my avrISP, utilizing Atmel Studio, writes the high byte as FF while avrdude does not attempt to write the high byte. 

 

Atmel Studio Write capture at location where I experience a verification error when utilizing avrdude:

 

 

 

Avrdude Write capture at location where verification error occurs:

 

avrdude write capture

 

While I have learned a great deal during this troubleshooting exercise, I am getting in over my head a little. I am hoping someone can at least confirm this might be an "easy" patch in avrdude (perhaps by writing some code to ensure that if a low byte is parsed from the hex file that a high byte is also parsed and if not, add "0x48 0xXX 0xXX 0xFF").

 

Note, I am not asking someone to write a patch for me, but rather verify that I am heading down the right path with my thought process.

 

At this point, I am not sure if this would be handled in the fileio.c, linuxgpio.c or bitbang.c file.

 

Thanks,

 

Mike

 

Attachment(s):