avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] Big end little end thingie


From: Anton Erasmus
Subject: Re: [avr-gcc-list] Big end little end thingie
Date: Fri, 11 Jan 2002 23:04:52 +0200

Date sent:              Thu, 10 Jan 2002 20:56:09 -0500 (EST)
From:                   RogerB <address@hidden>
To:                     AVR GCC List <address@hidden>
Subject:                Re: [avr-gcc-list]  Big end little end thingie

> 
> 
> 
> On Thu, 10 Jan 2002, Anton Erasmus wrote:
> 
> >
> >
> > Hi,
> >
> > Atmel stuffed up their S-Record generation and interptretation. If
> > you want to use any of atmels software u either Intel Hex or binary.
> > There used to be a hack in avr-gcc to enable it to generate the
> > incorrect atmel version of S-Records.
> >
> > Regards
> >    Anton
> >
> > avr-gcc-list at http://avr1.org
> >
>         I'm not making a srec file with studio just a intel hex
> file and I'm looking at the list files and the first two used bytes
> S11300000AC0 for the srec and :10000000C0A0 for the hex file. The 0A
> part might change but it's followed by C0 on the linux box with srec
> or ihex code,  with studio the ihex file is the other way around. The
> flash location 0000 is 0A and 0001 is C0 which the .lst say is a ld
> instruction. It should be a jump to the program start or something
> similar.
>         That seems like gcc is building the wrong ended code
> if the micro wants little end but  I don't see a switch
> for that anywhere.
> 
> 

I have found the display of memory in AVR studio to be very 
confusing. When switching between byte and word display - one of 
them is definately in the wrong order. 
What version of avr-gcc are you using? The earlier versions of avr-
gcc generated "incorrect" (Byte swapped) srec files, so that they 
could be used with the Atmel/Kanda software provided with the 
STK200/300. 

With the latest avr-gcc for windows from the avfreaks.net site I get 
the following intel hex file:

:100000000C94A1000C94BF000C94BF000C94BF0092  

and the following srec file:

S2140000000C94A1000C94BF000C94BF000C94BF008D

Both are correct and consistent.

Regards
   Anton

avr-gcc-list at http://avr1.org



reply via email to

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