avrdude tribulations...

Having trouble uploading/verifying. Started out with trying to create bitmaps for display on a GLCD using the glcd library. Have spent time narrowing down to barebone sketch to generate the error. Here it is:

#include <glcd.h>

// 136 bytes of data = avrdude: verification error, first mismatch at byte 0x11ff
//                              0xff != 0x01
//                              avrdude: verification error; content mismatch
// 135 bytes of data = No errors.
// ...OR, change ANY single byte of the 136 bytes to ANY other value = No errors.
// ...OR, remove #include <glcd.h> = No errors.
// ...OR, remove Data[0]=0; = No errors.
byte Data[] = {


void setup(){

void  loop(){


The original data block was buried in a bitmap and caused upload verification errors. After a day of effort whittling code, the above has been produced. 136 bytes of value 255 is the minimum needed to generate an error. Larger blocks of the same data, sprinkled generously with values different to 255, will elimate upload errors. To eliminate possible hardware issues, I have tried this on my original Arduino Duemilenove and recently purchased Seeeduino V328 boards, both with different USB cables and with absolutely no other hardware attached and get exactly the same results. How this error is being generated is beyond me. I simply cannot for the life of me understand what is going on here. How is it possible, for example, by simply by removing the '#include ’ that a verification error can be eliminated? Even more confusing, how is it possible that by changing the value of a single byte in an array from 255 to any other value ( keeping the same size of code generated ) that once again a verification error can be averted??? I’ve searched the internet and forums extensively and discovered that this kind of verification problem occurs frequently! I’ve only recently seriously started programming for these boards and am quite concerned that a problem like this has occured so soon… :frowning: Is there anybody who can shed some light on this…??


This is most likely a rather interesting side effect of how FLASH is programmed. An unprogrammed (blank) FLASH memory cell is all 1-bits, or 255. The AVRDUDE uploader is "smart" in that if it sees that an entire page of FLASH (128 bytes) is all 1-bits then it just has to erase the page and not really have to program it.

Unfortunately, the bootloader does not support page erase without programming (I believe) so the page does not actually get erased, nor does it get programmed. That's why changing bytes from 255 to something else works: it forces AVRDUDE to actually erase/program the page, which the bootloader DOES do.

-- The Gadget Shield: accelerometer, RGB LED, IR transmit/receive, light sensor, potentiometers, pushbuttons

This is most likely a rather interesting side effect of how FLASH is programmed.

Yes, I kind of suspected it might be something along those lines. This explains why when deleteing the '#include ', it just so happens that the data block, presumably bounded by data other than 255, then straddles a page boundary forcing avrdude to program it and hence avoiding the verification error. Seems that avrdude and the boootloader are clearly not on the same page ( excuse the pun! ) when it comes to erasing the FLASH. If this is the case, then this begs the question: How is it that the writers of the GLCD library overlooked this? It is entirely possible to have bitmaps that contain large blocks ( greater than 136 bytes ) of black ( 255 ) pixels, if not bitmaps that are entirely made up of black pixels! Each bitmap is represented by a header (.h) file containing a static 'PROGMEM’ed array of the bytes that represent the bitmap, and which is included in the sketch at compile time. I have bitmaps that contain large blocks of black pixels and when I try to use them I get the errors as given. Is there a work around to this problem rather than the ridiculous situation of having to modify my lovingly ( :wink: )created bitmaps? Can I get avrdude to force a program rather than issue an erase command?

Thanks again.