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

Go To Last Post
41 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): 

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

Any developments? I seem to have the same problem when programming a 2560 with linuxgpio from a Raspberry Pi Zero.

 

Edit:

 

Actually my problem might be similar, but different. I'm getting a verification error at 0x0000, 0x00 != 0x0c, followed by this:

 

avrdude: safemode: lfuse changed! Was ff, and is now fe
Would you like this fuse to be changed back? [y/n] n
avrdude: safemode: hfuse changed! Was dd, and is now 0
Would you like this fuse to be changed back? [y/n] n
avrdude: safemode: efuse changed! Was fc, and is now fe
Would you like this fuse to be changed back? [y/n] n
avrdude: safemode: Fuses OK (E:FC, H:DD, L:FF)

 

The command is avrdude -c 2560 -p m2560 -U test.hex

 

where "2560" programmer is:

 

programmer
  id    = "2560";
  desc  = "Use sysfs interface to bitbang GPIO lines";
  type  = "linuxgpio";
  reset = 4;
  sck   = 27;
  mosi  = 17;
  miso  = 22;
;

Last Edited: Wed. Jun 26, 2019 - 03:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Any developments? I seem to have the same problem when programming a 2560 with linuxgpio from a Raspberry Pi Zero.

Why not simply use an AVR programmer?---they are available for a few bucks & ready to go & get your software up & running. 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

What you suggest is a workaround. While a valid approach, I would like my linuxgpio working correctly.

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

andrzejtp wrote:
Any developments?
the defect is still open

AVR Downloader/UploaDEr - Bugs: bug #51497, avrdude not writing high byte... [Savannah]

...

avrdude not writing high byte using linuxgpio when data byte count is less than 0x10

...

andrzejtp wrote:
Actually my problem might be similar, but different.
Yea though fuses are only a few bytes.

Fuse programming is typically infrequent; workaround is to use a different programmer for fuses (PITA)

Should be able to pad application programming to do an end run around bug 51497.

 

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

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

The test.hex is a blink program, I (think I) am not attempting to write fuses. The same hex file with usbasp works perfectly.

 

How can I help with debugging?

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

andrzejtp wrote:
How can I help with debugging?

Protocol decoders - sigrok

...

 

(11th)

AVR ISP 

...

 

...

to confirm the defect then likely perform AVRDUDE source code review, experiment (hypothesis, design, perform), patch, test.

Might be able to run AVRDUDE through a debugger.

 

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

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

The problem is with linuxgpio, not with AVR ISP.

 

Your suggestions are very general. Analyzing the source code from absolute beginning is something I am capable of, but that is something I can very well do without the help of the forum. What a forum could offer is to shorten the time needed to become productive (e.g. by telling me which file to debug or which function, what to compare with what etc.) and this is the kind of advice I am looking for. As far as I understand from this thread there are bugs in the linuxgpio programmer implementation but little care is taken to eliminate them, because of an assumption that "linuxgpio simply isn't used very widely by many people". So here I am one of these poor guys trying to use linuxgpio. It apparently doesn't work correctly, so I offer help in debugging and perhaps fixing the problem. I'd expect some more concrete advice to get me started. Anyone?

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

Ok, I gave the linuxgpio programmer another try without looking into the source code (yet). What I notice is that it works well if I separate in time erasing the chip and writing the new flash contents. This works:

 

avrdude -c 2560 -p m2560 -eu && avrdude -c 2560 -p m2560 -U test.hex -D

 

while this doesn't:

 

avrdude -c 2560 -p m2560 -U test.hex

 

Any ideas why?

 

Now, speaking of http://savannah.nongnu.org/bugs/... I can reproduce it with this hex file: http://savannah.nongnu.org/bugs/....

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

andrzejtp wrote:
What a forum could offer is to shorten the time needed to become productive
Yeah but virtually no one in this forum is using the combination you are attempting to use. As you will have read above
avrcandies wrote:
Why not simply use an AVR programmer?---they are available for a few bucks & ready to go & get your software up & running.
So in 2019 no one beats themselves up trying to make kludgey solutions work when you can just buy something that is guaranteed for $2 and move on with the rest of your life. That is the reality of the thing.

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

clawson wrote:

Yeah but virtually no one in this forum is using the combination you are attempting to use.

 

That is a concrete piece of information without beating about the bush. Nonetheless, how can you be sure that it is only me trying to use the said combination?

 

clawson wrote:

So in 2019 no one beats themselves up trying to make kludgey solutions work when you can just buy something that is guaranteed for $2 and move on with the rest of your life. That is the reality of the thing.

 

Bit-banging is a valid approach. We are not talking about hundreds of MHz but simple spi. I don't like the idea of putting more hardware in my design given the fact that I already have an RPi there which, in 2019, should be able to bit-bang spi. With RPi inside I am able to ssh into it and program the 2 atmegas from it. All with a single USB connection, no need to disassemble the device or provide ISP connectors on its case. Adding more hardware means more power consumption in a battery-powered device. Or more complication if I want power/clock gating. And still using RPi zero as USB host (for two USB asp programmers, or one programmer and more circuitry to connect it to either of the two atmegas) rather than device precludes the possibility to ssh into it.

 

The reality is that avrdude does offer linuxgpio programmer support, but there are bugs. I offer help in debugging it rather than discussing whether it is "the right thing" (tm) to use it.

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

But the point is that because RPi is a USB host it should be able to host a $2 USBAsp. That "just works". because it is so cheap and easy I think you'll find that in this day and age most people trying to program AVR from Linux are going to be using something very like that. So there's  no real incentive to develop bit-bang ISP etc.

 

In fact it reflects things as they were maybe 15 years ago. Back then "the thing" for programming AVRs was the so called DAPA programmer. That relied on the fact that PCs in that era had 25 pin parallel connectors and 9 pin serial connectors either of which had plenty of IO. So with a simply plug and a handful of resistors you could useeither interface to bit-bang SPI to the ISP of the AVR. The early use of avrduded (and others - Ponyprog etc) was to drive such interfaces.

 

The Thomas Fischl had a great idea and the rest is history (once the Chinese vendors realised they could clone the design and make a profit even on $2).

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

clawson wrote:

But the point is that because RPi is a USB host it should be able to host a $2 USBAsp. That "just works".

 

Did I make it clear enough that we are talking about RPi zero built into the device of interest and accompanied by two atmegas, also inside the said device? The Pi is - among other purposes - the (built-in) programmer and has enough GPIO lines to provide two (bitbanged) ISP interfaces. The idea is to connect to the Pi with ssh over a single usb cable. And use a single USB socket on the case of the device, no ISP connectors nor the need to open the case to connect a programmer. Asking a 1GHz ARM to bitbang avr ISP is not a terribly demanding thing, is it?

 

Now, suppose I want to use USBasp. I then need to connect a USB hub through an OTG cable to the Pi and connect the two programmers to it - I don't want to have to open the case of the device to connect a programmer. If I wanted that, there would be no need for a built-in programmer in the first place. Or, if I don't want to use the hub, I can use a single programmer but then need to provide some more circuitry to select to which atmega the programmer is connected. This can be achieved, but how do I connect to the Pi zero from outside if its uUSB is taken by the OTG cable and acts as a USB host, not device? I could perhaps use UART, but then am left with 115200 and things such as zmodem to transfer files. And in fact I need the UART for other purposes.

 

If linuxgpio is provided, why not make it work properly?

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

andrzejtp wrote:
If linuxgpio is provided, why not make it work properly?
Then luckily for you avrdude is FOSS so anyone, and that includes you, can contribute improvements and fixes. FOSS tends to work like this- things get added when someone has a strong enough need to fix/implement some missing/broken function ;-)

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

So there seem to be two unrelated problems, but both result in verification stage failing. First I'm investigating this:

 

andrzejtp wrote:

This works:

 

avrdude -c 2560 -p m2560 -eu && avrdude -c 2560 -p m2560 -U test.hex -D

 

while this doesn't:

 

avrdude -c 2560 -p m2560 -U test.hex

 

I added debug messages in programmer methods in linuxgpio.c and bitbang.c (linuxgpio programmer uses some of the bitbang.c implementations), observed what gets called in case of the two separate avrdude invocations and imitated the same behaviour with the below changes (re-initializing the repo as a git repo; I used to speak cvs ages ago and never learnt svn but now I speak git), ignoring the return values (treat this as proof of concept rather than something fit for submitting as a patch):

 

diff --git a/main.c b/main.c
index ad50772..5dbcf30 100644
--- a/main.c
+++ b/main.c
@@ -1241,6 +1241,9 @@ int main(int argc, char * argv [])
       }
       exitrc = avr_chip_erase(pgm, p);
       if(exitrc) goto main_exit;
+      pgm->close(pgm);
+      pgm->open(pgm, port);
+      pgm->initialize(pgm, p);
     }
   }

 

With this programming works. I still don't know why it helps, so it is a classic example of engineering debt. Any ideas why this helps?

 

I haven't tackled the original poster's problem yet.

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

andrzejtp wrote:
The reality is that avrdude does offer linuxgpio programmer support, but there are bugs.
fyi

patch #9816: Implement new programmer type: linuxspi (AVRDUDE)

 

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

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

For ICSP from a R-Pi zero, I did not try linuxgpio, but I did find linuxspi worked as the root user with the Raspian package.

I had to run avrdude as root, but a fix is known (though I can't tell if it will land on the upstream). This link is to my notes:

 

https://github.com/epccs/Driver/tree/master/ICSP/Schooling

 

This link is to some of what I checked:

 

https://github.com/epccs/Driver/tree/master/ICSP/Evaluation

 

It is unnerving how fast it is over SPI.

 

I know facchinm does not want to be the avrdude dude, but he has collected some stuff that is just not getting collected in Savannah.

 

https://github.com/facchinm/avrdude

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

Thanks for pointing me at this patch. It does not solve my problem. It solves a similar, neighbouring problem: to program avr from RPi using RPi's hardware SPI. My problem is: program TWO avrs from RPi. While Chip Select could be somehow tweaked with GPIO, in my project the hardware SPI of RPi is taken for something else so I can't use it. Now I'm investigating why injection of pgm->close(), pgm->open() and pgm->initialize() solves my original problem.

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

I have looked at avrdude a few times now; it is on the edge of the sort of stuff I can understand. I would not be surprised if you are bypassing the same problem linuxspi has, i.e., "doesn't allow enough time for the udev rule to give access rights to the gpio user group"

 

https://github.com/kcuzner/avrdude/pull/17/

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

ron_sutherland wrote:

I have looked at avrdude a few times now; it is on the edge of the sort of stuff I can understand. I would not be surprised if you are bypassing the same problem linuxspi has, i.e., "doesn't allow enough time for the udev rule to give access rights to the gpio user group"

 

https://github.com/kcuzner/avrdude/pull/17/

 

I'm running as root, so no, this seems unrelated.

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

I investigated my problem a bit further:

 

andrzejtp wrote:

diff --git a/main.c b/main.c

index ad50772..5dbcf30 100644
--- a/main.c
+++ b/main.c
@@ -1241,6 +1241,9 @@ int main(int argc, char * argv [])
       }
       exitrc = avr_chip_erase(pgm, p);
       if(exitrc) goto main_exit;
+      pgm->close(pgm);
+      pgm->open(pgm, port);
+      pgm->initialize(pgm, p);
     }
   }

 

With this programming works. I still don't know why it helps, so it is a classic example of engineering debt. Any ideas why this helps?

 

I replaced the programmer method invocations with their actual code and kept trimming the replacement until I found a minimal, improving chunk. It boils down to: 1) unexport the "reset" GPIO pin, 2) export it again, 3) set "reset" pin direction to output and 4) issue "program enable". In fact these four correspond to the very last things avr_chip_erase() from the above snippet does (=>pgm->chip_erase()=>bitbang_chip_erase()), because unexporting, exporting and setting the direction have a net effect of high pulsing the pin. Then why do I need to repeat this sequence in order for it to succeed? It seems to me that the difference is in timing: the sysfs machinery is "slow enough" for the pulse to last "long enough". Now, if I add "bitbang_delay(20000);" between linuxgpio_setpin() invocatins in linuxgpio_highpulsepin() I eliminate my original problem without injecting pgm->close(), pgm->open() and pgm->initialize(). Does it make sense to you?

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

Everything else using that "init and erase" logic is working, so I don't think the change should be in main.c, it probably needs to be in linuxgpio.c

 

I see that linuxgpio.c is using "pgm->chip_erase     = bitbang_chip_erase;" and linuxspi.c is using "pgm->chip_erase     = linuxspi_chip_erase;". The bitbang_chip_erase function does not seem to be in bitbang.c, I am not sure where it lives.

 

I need to setup VScode and use its IntelliSense for diving into this so let me see if I can get that going.

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

ron_sutherland wrote:

Everything else using that "init and erase" logic is working, so I don't think the change should be in main.c, it probably needs to be in linuxgpio.c

 

I see that linuxgpio.c is using "pgm->chip_erase     = bitbang_chip_erase;" and linuxspi.c is using "pgm->chip_erase     = linuxspi_chip_erase;". The bitbang_chip_erase function does not seem to be in bitbang.c, I am not sure where it lives.

 

In my case it is gvim and ctags :D

 

bitbang_chip_erase() does live in bitbang.c.

 

The change I made indeed is in linuxgpio.c, in linuxgpio_highpulsepin(). The only change is lengthening the high pulse duration and affects only linuxgpio. And, as far as I can tell, the highpulsepin() programmer method is not used often, so adding a delay seems not to have any impact on programmer's performance.

Last Edited: Sun. Jul 14, 2019 - 09:18 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

VScode did find bitbang_chip_erase as you did; I must have had a typo in my lightweight editor. I think what you have sounds fine. The next trick is to sort out the best upstream if that is what you want to do with it.

 

I am now 100% sure that facchinm supplied the source for R-Pi's avrdude because this is its version (6.3-20171130) on my Pi Zero.

 

https://github.com/facchinm/avrdude/commit/2dc4c369ea570b61dd15f6ff83ec629402dcee3c

 

If you want your updates to land on Raspian sooner rather than later then that may be the place for it.