avrdude: verification error, first mismatch at byte 0x7800

Hi,

i've been trying to upload a sketch to my arduino Uno and avrdude give me an error every time

avrdude: verification error, first mismatch at byte 0x7800
0x05 != 0xff
avrdude: verification error; content mismatch

i tried to upload the sketch on my mega board and its working fine no problem. My sketch is pretty big for a uno board (31 506 bytes out of 32 256) is it why avrdude is giving me this error ?

You might be encountering a glitch in the way Arduino uses avrdude. Avrdude assumes that memory has been cleared to 0xFF before uploading. If it finds a 'page' (512 bytes?) of 0xFF in your code it won't bother sending it because it assumes the memory is already set that way. If the memory ISN'T set that way (from a previous upload) your code won't verify.

At least that is my understanding.

Do you have a big chunk of your data full of 0xFF (-1) bytes?

yes,

i got 2 bitmaps showing "arrows" pointing up and down

const uint8_t fleche_haut[] U8G_PROGMEM = {
 0x1,0x80,0x3,0xc0,0x3,0xc0,0x7,0xe0,0x7,0xe0,0xf,0xf0,0xf,0xf0,0x1f,0xf8,
0x1f,0xf8,0x3f,0xfc,0x3f,0xfc,0x7f,0xfe,0xff,0xff,0xff,0xff,0x7f,0xfe
};
 
const uint8_t fleche_bas[] U8G_PROGMEM = {
0x7f,0xfe,0xff,0xff,0xff,0xff,0x7f,0xfe,0x3f,0xfc,0x3f,0xfc,0x1f,0xf8,0x1f,0xf8,
0xf,0xf0,0xf,0xf0,0x7,0xe0,0x7,0xe0,0x3,0xc0,0x3,0xc0,0x1,0x80
};

but i tried to exclude them from my code but avrdude still give me the same error at the same byte

edit:

i found why its not uploading, im using a DS18B20 thermometer using the 1-wire protocol and my device adresse is defined like this

DeviceAddress thermometre = { 0x28, 0x47, 0x60, 0x47, 0x04, 0x00, 0x00, 0x07 };

but i guess i cant really changed that adress

is there a way to clean the memory before uploading the new sketch?

djosimd:
i've been trying to upload a sketch to my arduino Uno ...

Which revision?

Since its not written R3 on it, im guessing its a rev2, its an official arduino board too, not one of those chines crap. I uploaded other sketches on it to chek if it was the board or my code but its doesnt seems to be neither of them since my board work fine and im able to upload my sketch to my arduino mega

To me it looks more like the AVR has a 2k bootloader in it or perhaps thats what the fuses
are set to.
0x7800 is would be the first byte in a 2k boot loader space.

Run the fusesbytes sketch to verify how they are set:

(download a zip image using the [ZIP] button )

If it is using a 2k bootloader, you could use the IDE to burn the smaller
optiboot bootloader in it instead if you have an ISP programmer.

--- bill

djosimd:
Since its not written R3 on it, im guessing its a rev2, its an official arduino board too, not one of those chines crap.

In which case the bootloader is buggy. Do you have the means to replace it with version 4.4?

Thanks bperrybap !!

I had th 2 ko bootloader, i replaced it with optiboot and now im able to upload my sketch, i know the maximum size for my uno is around 31 700 bytes,

thank you ! i would have never guesses that on my own

hi guys, i urgently need a solution to my issue.

i am trying to load the firmware for Razor 9dof imu using FDTI, selecting arduino pro or pro mini as the board and selecting the right com port. i get an error while uploading

avrdude: verification error, first mismatch at byte 0x0002
0x00 != 0xa2

what do i do from this point?

Gbaski5:
hi guys, i urgently need a solution to my issue.

i am trying to load the firmware for Razor 9dof imu using FDTI, selecting arduino pro or pro mini as the board and selecting the right com port. i get an error while uploading

avrdude: verification error, first mismatch at byte 0x0002
0x00 != 0xa2

what do i do from this point?

This is a completely different issue - your verification error is happening immediately (ie, it's failing to write anything except the first word, which might be the same just based on luck, since that's pointing to the start of the program, which is often right after the end of the vectors.

You should have started a new thread instead of bumping a THREE YEAR OLD THREAD on a DIFFERENT PROBLEM.

What board are you uploading to? Is it an official board? Arduino on breadboard? Something else? Could it be improper fuse or lockbit settings causing the chip to not actually be writable? If so, burning the appropriate bootloader via ISP programmer should sort it out.