Upload failures on 2x 6month old Diecimilas

Hi,

I've not had any problems over the last 6 months or so up until the last few times I've tried to upload a particular sketch.

The problem I'm currently having is that I get a "verification error; content mismatch" message every time I try to upload a particular sketch.

This has been tested with 2 Arduino Diecimilas. 1 Heavily used and one hardly used and they both report failures in the same place so I don't think its anything to do with the flash being worn out.

I think it may actually be due to the code I'm trying to upload as the code contains a font (using progmem) which will set over 256 bytes to 0xFF in one long chunk. commenting out the font causes the upload to work successfully.

My current working theory is that the long string of 1s being sent over serial is causing the sender and receiver to lose sync due to a timing issue.

I would try rearranging the font so that it doesn't have the long block of 1s in a large chunk but unfortunately the code I'm working on is time sensitive and I had to rearrange the font already so that I could access it more quickly.

Can anyone think of a work around (other than change font)? Is there any way to get the arduino bootloader to do serial comms at a slower rate?

Thanks,

Steve

My current working theory is that the long string of 1s being sent over serial is causing the sender and receiver to lose sync due to a timing issue.

That doesn't make sense, since the async communications protocols involved have periodic non-1 bits regardless. It is more likely (IMO) that either the avrdude or the bootloader have a checksum or verification code bug. Have you tried reading the "badly programmed" code back (using AVRdude directly) to see if there are really any errors in it?

I couldnt get AVR dude to read back the data in exactly the same format as the arduino tools create them. I got reasonably close and managed to fudge the data to get a reasonable comparison and diffed them (avrdude was reading 32 byte rows in intel format, the arduino tools generated 16 byte rows in intel format).

There were a some differences mainly where there were big blocks of 0xFF.

I'm reasonably sure that this is an accurate reflection of the differences as my font also displays in a corrupt manner.

The font is 1 bit per pixel 8x11 pixels per char 256 char extended ascii font organised as a large 1D array like this char1 row1, char2 row 1, char3 row 1, . . ., char1 row 2, char2 row 2, char3 row 2, . . ., char1, row3, char2 row3 etc.

The the first row and last 3 rows of all of the fonts were set to 0xFF but are displaying as 0x00. This makes me fairly certain the data stored on the microcontroller is not the same as the data i tried to send to it.

EDIT: changed all of the non printable characters I had to contain a pattern instead of 0xFF and it now uploads correctly. This isn't solved as the problem is repeatable (just define a 256 byte block of 0xff in progmem) but it does mean I can get on with the project.