bugAVR Downloader/UploaDEr - Bugs: bug #28660, Problem with loading intel hex rom...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #28660: Problem with loading intel hex rom files that exceed 0x10000 bytes

Submitted by:  None
Submitted on:  Mon 18 Jan 2010 08:14:21 AM UTC  
 
Category: NoneSeverity: 3 - Normal
Priority: 5 - NormalItem Group: None
Status: FixedPrivacy: Public
Assigned to: David Hoerl <dhoerl>Originator Name: Bradley Jarvis
Originator Email: -unavailable-Open/Closed: Closed
Release: NoneProgrammer hardware: 
Device type: 

Mon 18 Jan 2010 11:08:08 AM UTC, comment #2:

I have reverted the changes from r851/r880, and can program
a 150 KiB file into an ATxmega256A3 quite fine with that.

Thus, I can lower the priority of the bug again. David,
can you have a look at whether AVR32 programming still works?

(This bug is serious enough to warrant a new release of
AVRDUDE I think.)

Joerg Wunsch <joerg_wunsch>
Project Administrator
Mon 18 Jan 2010 08:27:15 AM UTC, comment #1:

David, this appears to be caused by the changes in r851 and
r880, respectively.

Joerg Wunsch <joerg_wunsch>
Project Administrator
Mon 18 Jan 2010 08:14:21 AM UTC, original submission:

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

Anonymous

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by joerg_wunsch (Posted a comment)
  • -unavailable- added by None (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 7 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 19 Jan 2010 10:04:19 AM UTCjoerg_wunschStatusNone=>Fixed
      Open/ClosedOpen=>Closed
    Mon 18 Jan 2010 11:08:08 AM UTCjoerg_wunschSeverity5 - Blocker=>3 - Normal
      Priority7 - High=>5 - Normal
    Mon 18 Jan 2010 08:27:28 AM UTCjoerg_wunschPriority5 - Normal=>7 - High
    Mon 18 Jan 2010 08:27:15 AM UTCjoerg_wunschSeverity3 - Normal=>5 - Blocker
      Assigned toNone=>dhoerl

    Back to the top


    Powered by Savane 3.1-cleanup1