[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[avrdude-dev] [bug #28660] Problem with loading intel hex rom files that
From: |
anonymous |
Subject: |
[avrdude-dev] [bug #28660] Problem with loading intel hex rom files that exceed 0x10000 bytes |
Date: |
Mon, 18 Jan 2010 08:14:21 +0000 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091211 Gentoo Firefox/3.5.5 |
URL:
<http://savannah.nongnu.org/bugs/?28660>
Summary: Problem with loading intel hex rom files that
exceed 0x10000 bytes
Project: AVR Downloader/UploaDEr
Submitted by: None
Submitted on: Mon 18 Jan 2010 08:14:21 AM UTC
Category: None
Severity: 3 - Normal
Priority: 5 - Normal
Item Group: None
Status: None
Privacy: Public
Assigned to: None
Originator Name: Bradley Jarvis
Originator Email: address@hidden
Open/Closed: Open
Discussion Lock: Any
_______________________________________________________
Details:
The fileio.c contains a 'fix' on line 326 that shifts the upper 16bit address
of the extended segment address 4 bits. This 'fix' is incorrect and causes an
intel hex formatted file to be corrupted.
The code from avrdude 5.9
case 2: /* extended segment address record */
// note: shift values use to be 8 and 4 - the first had to be wrong
baseaddr = (ihex.data[0] << 12 | ihex.data[1]) << 4;
break;
case 3: /* start segment address record */
/* we don't do anything with the start address */
break;
case 4: /* extended linear address record */
baseaddr = (ihex.data[0] << 24 | ihex.data[1]) << 16;
if(nextaddr == 0) offsetaddr = baseaddr; // if provided before
any data, then remember it
break;
case 5: /* start linear address record */
/* we don't do anything with the start address */
break;
You will see the the comment above the incorrect line says the values used to
be 8 and 4 and then says that they were incorrect. The old value of 8 is
actually correct if you look at the brackets. It offsets the top byte by 8bits
then or's the bottom byte then shifts the whole lot by 4 bits.
The extended linear address calculation (case 4) is also incorrect, the 24
should be changed to 8. I personally would also add brackets around the
(ihex.data[0] << 8) just so that the math is clearer.
This is the corrected bit of code (this also supports case 3 and 5 of the
intel hex format)
case 2: /* extended segment address record */
baseaddr = ((ihex.data[0] << 8) | ihex.data[1]) << 4;
break;
case 3: /* start segment address record */
baseaddr = (((ihex.data[0] << 8) | ihex.data[1]) << 4) +
((ihex.data[2] << 8) | ihex.data[3]);
break;
case 4: /* extended linear address record */
baseaddr = ((ihex.data[0] << 8) | ihex.data[1]) << 16;
if(nextaddr == 0) offsetaddr = baseaddr; // if provided before
any data, then remember it
break;
case 5: /* start linear address record */
baseaddr = ((((ihex.data[0] << 8) | ihex.data[1]) << 8) |
ihex.data[2] << 8) | ihex.data[3];
break;
Hehe, it would be good if things like this were checked instead of as the
comment suggests it was changed on a whim. The hex file I had this happen on
was generated for a atmega2560 using avr-gcc
Thanks, Brad
_______________________________________________________
Reply to this item at:
<http://savannah.nongnu.org/bugs/?28660>
_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/
- [avrdude-dev] [bug #28660] Problem with loading intel hex rom files that exceed 0x10000 bytes,
anonymous <=