avrdude: verification error, first mismatch at byte 0x10000

[Matthias1992]

Hey, I had an problem with my bin file witch is 73880 bytes large.

I definde #define LARGE_MEMORY but that was not the fix

address = recchar() << 8) | recchar(); has to be recasted in address = (uint32_t)(((uint32_t)recchar() << 8) | (uint32_t)recchar()); I think there is some error in the shfting operation maybe its pefromded in 16 bit ?

regards Matthias

[bandtank]

Are you saying the casts fixed your issue or was that an attempt which did not succeed? Which microcontroller are you using, what is your development environment and compiler, and what happened when you tried the code without the casts?

[Matthias1992]

hey yep the cast fixed this issue

I use QT creator with : gcc version 4.9.2 (GCC)

when I try to update the application code on my Xmega, and the application is greater 65536 bytes

avrdude gave me always the mismatch error at byte 0x10000

If the file was smaller there was nor error, if you with I can provide with my bin file where the problem happens

[bandtank]

Could you please upload the assembly output of the code with and without the casts? I would like to see what your compiler is doing. Please don’t change anything other than the cast when you compile each file.

[prenticedavid]

I found the same problem. i.e. any pc >= 0x10000 would not program or verify. My solution was:

            else if(val == COMMAND_SET_ADDRESS) {             // Set address (words, not bytes)
                address = ((ADDR_T)recchar() << 8) | recchar(); // ensure unsigned ADDR_T expression
                sendchar(RESPONSE_OKAY);                      // Send OK back.
            }

The original expression was calculated as an "int". Hence bit15 gets sign-extended in the assignment.

Bootloader works fine for small programs on my ATxmega128a4u but fails on anything above 64kB.

I only possess x128A1, x32a4u, x128a4u, x32e5 chips. The address assignment is ok for <= 128kB. What happens if you try to upload a 256kB program on the larger Xmegas like x256a3bu or x384d3 ?

Incidentally, the AS7.0 Solution builds ok on my old Win7-32 Laptop. But makefile fails on my Win10-64 Desktop PC when creating EEP and LSS files.

        make: Entering directory 'C:/Users/David Prentice/Documents/Atmel Studio/Xmega_Bootloader'
        avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 --no-change-warnings -O ihex Xmega_Bootloader.elf Xmega_Bootloader.eep || exit 0
              0 [main] sh 2420 sync_with_child: child 6284(0x1C8) died before initialization with status code 0xC0000142
             18 [main] sh 2420 sync_with_child: *** child state waiting for longjmp
        /usr/bin/sh: fork: Resource temporarily unavailable
C:\Users\David Prentice\Documents\Atmel Studio\Xmega_Bootloader\makefile(388,1): error: recipe for target 'Xmega_Bootloader.eep' failed
        make: *** [Xmega_Bootloader.eep] Error 128
        make: Leaving directory 'C:/Users/David Prentice/Documents/Atmel Studio/Xmega_Bootloader'

It would be nice to know why this is happening only on Win10-64. Disabling "parallel builds" does not cure it. The fix is simple. Remove the dependency:

#all: $(TARGET) $(PROJECT).hex $(PROJECT).eep $(PROJECT).lss
all: $(TARGET) $(PROJECT).hex

David.

[bandtank]

Very interesting. Thank you for posting this information. It is extremely helpful. Unfortunately, I do not have access to a Windows 10 system, but I will try to figure out the problem from afar.

If you are willing to make a pull request with your changes, I would love to incorporate your solution.

[prenticedavid]

The (ADDR_T) cast is nothing to do with Win7, Win10, Linux, ... It is just a feature of C expressions defaulting to "signed int" On an int16_t compiler you get problems with sign extension of bit15.

I can submit a pull-request but it is a pretty trivial fix.

You could equally well do:

                address = (ADDR_T)((recchar() << 8) | recchar()); // calc as int.  cast result to unsigned

I am more interested in the "bigger" Xmegas. What does avrdude do for > 128k ?

And the "child sync" is just an aside.

David.

[bandtank]

I was responding specifically to this comment regarding Windows 10:

Incidentally, the AS7.0 Solution builds ok on my old Win7-32 Laptop. But makefile fails on my Win10-64 Desktop PC when creating EEP and LSS files.

I have not touched this repository for years. I also don't have a way to validate any changes without going through a lot of effort, which is why I requested a PR if you already have a working fix.

Regarding the larger XMegas, I had no issues with 256 kB versions, but that was 10 years ago on a different version of AVRDude and WinAVR. With that said, I've been meaning to get back into microcontrollers, so maybe this is the right opportunity to buy some new hardware for testing. I'll report back with my results in a few weeks.

[prenticedavid]

Don't worry about Windows 10. I will investigate the parallel / sync problem another day.

The important issue is fixing the sign-extension in Xmega_Bootloader.c

I am building for an ATxmega128a4u in AS7.0.2542 I get the same C behaviour with Pack 1.0.39 as with the current Pack 1.3.146

I can probably build for an ATxmega128A1 with WinAvr-2010 but it seems a bit retrograde. WinAvr had a lot of compiler issues. I don't think that WinAvr even knows the Xmega A4U chips.

I have created a Branch "prenticedavid/bandtank_16d4" on https://github.com/prenticedavid/Xmega_Bootloader/tree/bandtank_16d4 This is just two user-commits i.e. ADDR_T and avoid EEP,LST dependency

There are massive machine-generated changes to XML and CPROJ files. But they simply reflect the Pack version numbers.

David.

[bandtank]

Solved by 2963fc2bf723062c4881fd4288769882cd5d37a5