[Top][All Lists]
[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