Avrdude: verification error

[KristoZ]

Hi,
I am playing with my Goldilocks (22.1184MHz), but am getting "Avrdude content mismatch" errors for sketches larger than ~ 10kB. Here's an example of one of those errors:

Code: Select all

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0100
         0x00 != 0xa6
avrdude: verification error; content mismatch
avrdude: Send: . [1b] a [61] . [00] . [03] . [0e] . [11] . [01] . [01] f [66] 
avrdude: Recv: . [1b] 
avrdude: Recv: a [61] 
avrdude: Recv: . [00] 
avrdude: Recv: . [02] 
avrdude: Recv: . [0e] 
avrdude: Recv: . [11] 
avrdude: Recv: . [00] 
avrdude: Recv: g [67] 

avrdude done.  Thank you.

So far I haven't experienced any errors with relatively small sketches.
I have tried this on Arduino 1.0.1 and 1.0.5 (Win 7 64-bit), drivers and newest firmware from:
http://feilipu.me/2013/03/08/goldilocks ... uno-clone/
and Freetronics firmware from:
http://www.freetronics.com/pages/goldil ... kgQVz_pxdw
Tried both 20 and 20.1184 boards with no difference.

Could you please help me to troubleshoot this issue?

[feilipu]

KristoZ,

you're experiencing something that is pretty much an inherent problem with the use of the ATmega32U2 (or '16U2 in Arduino boards) as a Serial interface, whilst driving it with a main crystal of 16MHz. Basically its synchronization with the true USART rate is just crappy.
Wormfood AVR baud calc is the best resource to see the issue.

Normally, when both the 32U2 and 328P are running at the same (but incorrect) 16MHz baud rate this is not an issue, but the Goldilocks runs at 20MHz or 22MHz, and relies on the serial rate being accurate to avoid bit slips between the two USART clocks over the entire period of a programming cycle.

During the development phase of the Goldilocks, I spent hours trying to remediate this situation, and eventually fixed both the rate calculations to match the avr-libc calculation (the datasheet calculation is wrong in some cases), and actually slowed down the serial speed to 38,400 baud to improve synchronisation. This provided a working solution for most of the boards, but sometimes (depending on crystal tolerances, etc) it can still be an issue. It is the issue that you are experiencing.

From my 10 overclocked Goldilocks boards, I have three that I can't program with the serial bootloader. And actually these are the three boards that I use day to day. The USART rate generated by the 32U2 on these boards is just wrong enough to prevent larger sketches from being successfully programmed. But these boards still behave perfectly in every other way.

One possible way to fix the issue is to slow the serial bootloader down to 19,200 baud, although there are ALWAYS residual errors at 16MHz, and even though the rate is lower it may still experience slip during the programming cycle. Another would be to change the crystal on the 32U2 to 14.7456MHz which would fix the USART error, but may cause complexity with the USB timing.

But, any solution would involve reprogramming the Goldilocks 1284p bootloader using some kind of AVR-ISP. This then, is the best solution and the one that I use. The most effective solution is to use an AVR-ISP to program the Goldilocks.

I use the AVR-ISPmk2 but I can also recommend the freetronics USBASP.

The other advantage to using the AVR-ISP to programme the Goldilocks is that your serial port can remain open during programming, which saves re-enabling the serial terminal each time you go through a programming cycle.

Sorry that I can't provide a simple fix for the issue, but at least you know that you're not alone.

[KristoZ]

Thank you very much for your detailed reply!

Per your recommendation I tried reprogramming the default (Freetronics) Goldilocks bootloader using my USBtinyISP v3, but got the "verification error" again. I also failed to burn the bootloader from your web page, but I presume I have to compile it first?
I also tried to upload a sketch to the 1284p directly, following the instructions found at http://www.arduino.cc/en/Hacking/Programmer , but failed (Arduino keeps asking for serial port). Is there any trick to make it work?

[feilipu]

Hi KristoZ
now that is quite odd.

First off, if you are using the USBtinyISPv3 then you don't need the bootloader on the 1284p. So that's one thing you don't have to worry about. You're writing direct to the 1284p hardware using the ISP function of the chip.

[As an aside FYI, if you do like the bootloader for its monitor capability, then use avrdude with -D option, then it won't erase the chip (and the bootloader you've previously written) before rewriting it to programme your sketch. Worth trying out if you've got new hardware, or a debugging issue and you want to see exactly what is being written to your device.]

If you want to put the bootloader back, because you've compiled your own variant for example, then you can use the instructions in the arduino production_firmware directory as your guide.

Code: Select all

### stk500v2 Bootloader for 1284P at 20MHz ###
> avrdude -cavrisp2 -pm1284p -u -Uflash:w:stk500boot_v2_goldilocks.hex:a -Ulfuse:w:0xd7:m -Uhfuse:w:0xd8:m -Uefuse:w:0xfc:m -Ulock:w:0xf:m

To address your issue let's try these commands for the USBtinyISPv3, with it plugged into the 1284p ISP plug. Check the cable is orientated correctly. If it doesn't work, flip the connector around and try again.

Code: Select all

> avrdude -cusbtiny -pm1284p
> avrdude -cusbtiny -pm1284p -u -Uflash:w:stk500boot_v2_goldilocks.hex:a -Ulfuse:w:0xd7:m -Uhfuse:w:0xd8:m -Uefuse:w:0xfc:m -Ulock:w:0xf:m

From the command line:
The first line will just check that avrdude can speak to the 1284p. If you don't get a good looking result from this first line, then there are problems with your avrdude installation, your powering of the Goldilocks, or some other connectivity problem. You need to sort this out first. Adafruit USBtinyISP AVRDUDE Tutorial

The second line will programme the bootloader from within the production_firmware folder. This is useful to check that there are no issues with the USBtinyISP, as the bootloader programming exercises all of the flash memory, as it is written at the top of the memory.

Ok, if you got past this step, then it is just a matter of educating the Arduino IDE that you're using the USBtinyISP. You can do this in the Tools menu, by selecting the correct Programmer. Then you should be able to programme any sketch that fits in the 1284p.

Please let us know how you go.

Edit: It suddenly occurred to me about an old problem. That might be affecting you. It is to do with the chip delay calculation for the 1284p. There is a bug in avrdude that has never been fixed. See Step 3 in freeRTOS and libraries for avr ATmega But, only do this if you're not getting happy face above already.

[KristoZ]

Hi,
I just tried burning both yours and Freetronics bootloader as you advised. I also compiled a bootloader myself, but the results are always the same. See for yourself:

Code: Select all

E:\Dropbox\Arduino\hardware\Goldilocks-22\bootloaders\stk500v2>avrdude -cusbtiny
 -pm1284p -u -Uflash:w:stk500boot_v2_goldilocks_22.hex:a -Ulfuse:w:0xd7:m -Uhfus
e:w:0xd8:m -Uefuse:w:0xfc:m -Ulock:w:0xf:m

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.03s

avrdude: Device signature = 0x1e9705
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 "stk500boot_v2_goldilocks_22.hex"
avrdude: input file stk500boot_v2_goldilocks_22.hex auto detected as Intel Hex
avrdude: writing flash (129490 bytes):

Writing | ################################################## | 100% 71.38s

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

Reading | ################################################## | 100% 67.76s

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

avrdude done.  Thank you.

By the way, isn't the 129490 bytes a bit too much for a bootloader?

It connects just fine, but after failing this verification the D13 on Goldilocks just blinks.
And right after that I ran the "avrdude -cusbtiny -pm1284p" test sequentially 10 times and on 5 of those I got this:

Code: Select all

avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.

But after reconnecting the USBtinyISP I get no connection problems. I suppose the Goldilocks then goes into some sort of "panic mode" and fails to respond on all of the connection requests?

I also changed the avdrdude.conf to "chip_erase_delay = 55000;" for Atmega1284P and even tried 2 different USB cables without any improvement.
However, now I am able to successfully upload larger sketches (~30kB).

[feilipu]

Hi KristoZ

What you're seeing is correct. The USBtinyISP is programming the Goldilocks correctly. The correct result of programming the bootloader is to have the D13 LED just flash. That is the mode you see when there's nothing (except the bootloader) programmed. See the text file in the production_firmware file to see the expected result of programming the bootloader.

To test the bootloader monitor, follow Tronixstuff guide in his video review, or in my User Guide.

It is odd that it doesn't verify though. Don't know the reason for that (if the bootloader is being correctly programmed which you test above).

The large size is because the bootloader is programmed at top of flash memory. Basically 122880 bytes of nothing need to be programmed before the bootloader code starts at 0x1E000. It finishes at 129490 bytes, well inside the 131071 bytes available to 0x1FFFF.

It is actually the USBtinyISP that you see going into "panic mode". As I noted, if you use the USBtinyISP then you don't need or use the bootloader at all. The USBtinyISP is talking directly to the 1284p hardware, and the error you see originates in the USBtinyISP.

In fact if you do use the USBtinyISP to programme the 1284p, then you ARE erasing away the bootloader by default. Writing one sketch with the USBtinyISP has already removed the bootloader. But that's not bad. Using the ISP mode for programming is in any case better and more robust than the serial bootloader, anyway.

I don't read / know whether you're uploading the larger sketches with the bootloader, or with the USBtinyISP.

If you mean bootloader - I'm not sure why it is better now than it was before. The code for the bootloader is the same, and you didn't change the 32u2 code either. It can only be that the mismatch between the 32u2 and the 1284p is slightly less. Is it warmer? Serious question. Crystal timing drifts slightly. But, we haven't solved your problem at all.

If you mean USBtinyISP - I'm not sure why you'd be limited to 30k sketches. It should be able to load full size sketches... You just did that by writing the bootloader to 122880 to 129490.

Try setting the Tools/Programmer in the Arduino IDE to USBtinyISP and using that to programme sketches. If avrdude is working from command line now with your USBtinyISP, then it is just a matter of getting it working inside the Arduino IDE.

[KristoZ]

Hi Philip,
Thank you again for replying and trying to help! I appreciate it!

About the outcome of burning a bootloader - it says "3 blink cycles" in the instructions, but I get 1 super-short blink and right after that one ~0.5s blink - I doubt it's the expected outcome.
Also, after programming the bootloader I am unable to upload any sketches traditionally (by using the 32u2 (USB cable and Arduino)). I get the timeout errors:

Code: Select all

Binary sketch size: 1,228 bytes (of a 122,878 byte maximum)
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_getsync(): timeout communicating with programmer

I am unable to enter the "Bootloader prompt" neither, though I'm pretty sure I am doing it right (worked before).

Sorry that I wasn't clear in my previous message - as you are now aware I am no longer able to program the 1284p using a bootloader, because I haven't succeeded in burning it so far.

I just tried programming one larger sketch (115k) in ISP mode by using the USBtinyISP and... it failed the verification again! I can try to pinpoint the size limit over which it fails to verify if it helps.
Is it possible that some part of the 1284p's flash memory is damaged, which is causing the errors? But then it shouldn't be possible to burn the bootloader in it before shipping... Strange.

One more thing I tried to do was programming a Telnet client sketch from the Arduino Examples and stacking the Goldilocks with Ethernet shield, but it even fails to obtain the static IP (though exactly the same sketch and Ethernet shield works fine with Duemilanove). But that's probably another story - topic.

[feilipu]

Hi KristoZ,

I think all the (current) problems stem from one point, the USBtinyISP. It may well be, but I can't confirm or deny, that it isn't capable of programming a 1284p.

I know that some of the clone devices can't programme the 2560 properly. It might be that the same issue is plaguing the USBtinyISP with the 1284p?

I have played around with a number of clones of different ISPs and have found some mixed results. In the end, I just went out and put down my $44 to get an Atmel AVRISPmk2. Since then, I've never had a problem programming anything. Now, it is not open source, etc, but hey, it just works. Also, comes with a CD with every ATMEL datasheet.

If your USBtinyISP is not working properly then you won't be able to burn anything properly. Your sketches (without the bootloader) won't be loaded via ISP correctly. And also, since you've broken or removed the bootloader by using the USBtinyISP directly, then clearly the serial bootloader won't work either.

There is little chance you've broken the Goldilocks. Unless you've been poking strange voltages onto the 5v pin. So, don't worry about that.

I suggest taking a deep breath, and going for an Atmel AVRISPmk2. When you have one of those you can be 100% sure you can program ANYTHING in the ATmega or XMEGA range. That's what was used for programming the Goldilocks from blank canvas.

For other programming suggestions, I'll have to leave it to others to comment.

Let's get programming 100% right, before we start elsewhere.

[KristoZ]

Yes, I see your point and therefore have just ordered one mkII. Will update you when it arrives.

[pschaeffer]

Folks,

I have seen an error just like this. Perhaps my experience may be of some help. I was trying to use the 'Arduino as ISP' approach to load the bootloader onto an ATMega1284 (not the ATmega1284p... an ordering error) and then to load and run sketches (such as blink).

The bootloader was correctly installed using the 'Arduino as ISP'... However, my efforts to upload a sketch using the 'Arduino as ISP' approach failed. I always got some sort of memory verification error. The key mistake was using the regular upload button. If you use the normal upload button, the Arudino IDE (1.0.5) issues an AVRDUDE command with the -D flag. The -D flag blocks the normal AVRDUDE chip erase operation.

Stopping chip erase does protect the flash. Since flash can not be written without a chip erase, the upload does nothing (with no reported errors other than from verification). If you use 'Upload Using Programmer' from the file menu, then the -D flag is dropped. That allows the flash to be written and everything is OK. Of course, without the -D flag the entire flash is erased (along with the EEPROM apparently) and the boot loader is gone (erased).

The application runs normally even without the bootloader and everything is OK. Of course, I still can't get the bootloader to upload my sketches. Still working on that one.