avrdude-dev
[Top][All Lists]
Advanced

[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/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]