Validation errors when uploading to the ATmega328

[cmatthews]

I have previously had code running on my Gertduino without any problems. I don't use the Arduino IDE but I followed Gordon's various instructions and was able to program the 328 from the command line using ino as per one of my previous posts (http://www.raspberrypi.org/phpBB3/viewt ... 86#p466086).

Subsequently, I decided to man up and have a play with using c code and a makefile. I started with the examples provided in the download from Element 14, but I found that I got verification errors every time I try to upload a .hex file to the ATmega. See below:

Code: Select all

$ ./program_328 blink.hex

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e950f
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "blink.hex"
avrdude: input file blink.hex auto detected as Intel Hex
avrdude: writing flash (594 bytes):

Writing | ################################################## | 100% 0.11s

avrdude: 594 bytes of flash written
avrdude: verifying flash memory against blink.hex:
avrdude: load data flash data from input file blink.hex:
avrdude: input file blink.hex auto detected as Intel Hex
avrdude: input file blink.hex contains 594 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.07s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
         0x0c != 0x00
avrdude: verification error; content mismatch

avrdude: safemode: lfuse changed! Was e7, and is now 0
Would you like this fuse to be changed back? [y/n] y
avrdude: safemode: and is now rescued
avrdude: safemode: hfuse changed! Was d9, and is now 0
Would you like this fuse to be changed back? [y/n] y
avrdude: safemode: and is now rescued
avrdude: safemode: efuse changed! Was 7, and is now 0
Would you like this fuse to be changed back? [y/n] y
avrdude: safemode: and is now rescued
avrdude: safemode: Fuses OK

avrdude done.  Thank you.

I have tried going back to using ino, but get the same errors. In the past, working with ino, I have dealt with verification errors by erasing the chip before I upload a sketch by using this command:

Code: Select all

avrdude -c gpio -p m328p -e -v

I find that this no longer helps, I basically can't upload to the 328 using either method (ino upload, or ./program_328).

I wonder whether I have messed something up somewhere, I have tried disabling the overclock on the Pi, and have tried running the avrsetup script a couple of times. Does any wise soul have any suggestions about where I might be going wrong?

[Jednorozec]

There's a bug in the ino upload code when it's being used with a GertDuino. I've put together a page on setting up ino at http://friendsoftheunicorn.net/content/using-ino. Maybe that will solve your problem.

[cmatthews]

There's a bug in the ino upload code when it's being used with a GertDuino. I've put together a page on setting up ino at http://friendsoftheunicorn.net/content/using-ino. Maybe that will solve your problem.

Thanks, I followed the instructions and while it looks like they would solve the problem that I originally had, where I needed to manually erase the 328 before uploading, it doesn't fix my bigger problem which is that I cant upload to the 328 through ino OR directly with AVRDUDE. I always get the same verification error caused by a mismatch at Byte 0x0000.

Here's what I am going to do next. I will swap the ATmega328 in the Gertduino, with one from my Gertboard and will look to see whether that works.

[cmatthews]

OK, swapping the chips worked. The ATmega328 from my Gertboard takes the upload just fine (by both methods).

Its a bit odd, the original chip seems to be partially functional at least in that I can send code to it. I didn't do anything nasty to the chip, it had been running a blink test program (LED0, LED1, LED2) for several hours when it just 'stopped working'. I still wonder whether I didn't mess something up somewhere, but I am stumped if I can figure out what it might be.

At least the ATmega328 is replaceable

[MightySmooth]

I had exactly this problem with my Gertduino last night, after much frustration the problem turned out to be the Arduino motor shield I had connected to the Gertduino. Any programming attempt with the shield attached failed with verification errors as described in your post:

avrdude: verification error, first mismatch at byte 0x0000
0x0c != 0x00
avrdude: verification error; content mismatch

Removing the shield fixed the issue and the program loaded and verified correctly.

I am new to Arduino/Gertduino so I'm not sure if I'm missing something obvious here. Is it typical to have to program these boards with no shield attached and then attach the shields when the program is loaded? Its a pain having to constantly shutdown the Raspberry Pi and Gertduino to swap shields in and out.

[Jednorozec]

OK, swapping the chips worked. The ATmega328 from my Gertboard takes the upload just fine (by both methods).

Have you tried putting the bad chip back into the Gertboard? Or better yet, do you have an Arduino that you could put the chip into?

[cmatthews]

@MightySmooth I think your problem may be different. The Arduino Motor Shield must be powered if it is fitted when you are uploading to the 328p. Some other shields (Tinkerkit for example) seem to have similar issues.

In my case, there was no shield fitted to the Gertduino, the ATMega just seemed to stop taking uploads. I tried setting the fuses with ./setup but that didn't help.

@Jednorozec I haven't tried it in any other hardware since to see if it works but I will give it a go when I have time. I suspect that it is an issue with fusebits and that HVPP might resurrect it.