Go Down

Topic: Mega 2560 verify error at byte 0x10000 when uploading (Read 159 times) previous topic - next topic

rick360

Jul 20, 2019, 10:33 pm Last Edit: Jul 20, 2019, 10:35 pm by rick360 Reason: add pic inline
First let me say Hi all, noobie here to forum and to Arduino, but not to electronics, programming etc.

I have a Mega 2560 that I have a program in Assembly language that I have developed and tested in Atmel Studio 7 to use with my Arduino. It has a large data table (128KB) that starts at code mem location 0x8000 (word address) to 0x18000. When I upload to the Mega using a command line form of avrdude it gives the "verify error at byte 0x10000". I will attach a pic of the cmd screen output from avrdude.

The code appears to be there (< 0x10000 ???) and running cause the led blink rate changes to how my code is programmed. Loading simple sketches from the Arduino interface work as per normal and so does loading small code developed in Atmel Studio.

Anybody have any ideas on what is causing this error at the upper area of code memory?

Rick


rick360

I've tried 2 different Mega 2560's and 2 different computers (both Windows 7 64bit) and always the same error at the same address.

I've looked at the Hex file and it looks normal. There is an extended address change at that point in memory. The error is at the mid-point of my data table. The program compiles clean in Atmel Studio 7.

Have searched the internet and found nothing to help yet.

Wondering if this thread should be in "Avrdude, stk500, Bootloader issues" forum instead of here. Moderator please move if appropriate.

Rick

lastchancename

In your command line call to launch avrdude, have you correctly nominated the right values for chip, memory sizes etc?
Experienced responders have a nose for laziness, (they were beginners once)... Sure, there are trolls, chest-beaters, and pretenders - but the help you'll get here is about as good as it gets - if you try to help youself!.

rick360

The avrdude command line is duplicated from the Arduino standard programming interface output with Mega2560 selected. It knows the correct memory size from the avrdude.conf file.

I have done more testing and am starting to get an idea of the problem. I read a post on another forum about large gaps in code memory causing verify error at the point of the continuation of code. Strange that small gaps like between INT vectors used doesn't cause the problem.

I also found out avrdude reports memory addresses as bytes, not words, so the error address was actually the first byte of the data table. (word addr=0x8000 ; byte addr=0x10000).

When I remove the .ORG 0x8000 statement that sets the address of the data table and even add more data to the table, it now loads ERROR FREE. But I need the table to stay where I put it in code.

So now I need a way to fill the gaps between my code and the start of the data table with 0xFF at every byte.

Hmmmmmm, probably need more testing.

Anybody have a good method to fill the gaps easily?

Rick

Whandall

Ah, this is obviously some strange usage of the word 'safe' that I wasn't previously aware of. (D.Adams)

rick360

Why?
I could move the data table but it would slow down my code by requiring timer readings be adjusted before retrieving a value from the table. The table is for a precision tach being calculated from timer readings at very high rate.

The programmer SHOULD put/leave FF's in flash memory where no code resides and continue on programming the rest correctly. It doesn't do that. I've been thinking about some work-arounds either to "fix" the hex file or in my assembly code to fill unused areas before the data table.

Rick


Whandall

I could move the data table but it would slow down my code by requiring timer readings be adjusted before retrieving a value from the table.
At most it would be a 24 bit addition to map a pointer anywhere, that's not much in a normal program.

You did not show the whole time critical path, so it's hard to guess whether a couple of cycles matter,
or could be spared in other parts of the path.
Ah, this is obviously some strange usage of the word 'safe' that I wasn't previously aware of. (D.Adams)

Go Up