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

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

Re: [avr-gcc-list] How does external memory work? (i just got bitten)


From: Reza Naima
Subject: Re: [avr-gcc-list] How does external memory work? (i just got bitten)
Date: Fri, 30 May 2003 02:59:54 -0700
User-agent: Mutt/1.4i

Er, as pointed out in an email, I meant that adding the 'static'
directive fixed it, not 'struct'.  I had to do this for all the
variables, though some of them seemed to work sometimes.    

Reza
 
On Fri, May 30, 2003 at 02:09:52AM -0700, Reza Naima sent me this...
> After 2 days of debugging, I found out a problem in some code, which
> makes me wonder how external memory is managed/used by avr-gcc.  I've
> read the docs on using malloc ..
> 
> http://savannah.nongnu.org/download/avr-libc/doc/avr-libc-user-manual/malloc.html
> 
> .. and it seems that you are required to explicitly tell avr-gcc to use
> the external memory.  In my application, I am using an external
> device via the memory-mapped interface (ftdi usb/serial IC), and as
> that's the only thing attached, any external memory references will
> allow me to interact with the IC.  I picked 0x1100 arbitrarily, and
> accessing the ic via that memory location worked just fine.
> 
> The problem we had was that the avr-gcc decided to store a large char
> array in the external memory address range (somewher around 0x7C00,
> if i recall) -- which doesn't exist.  Prepending the variable with the
> 'struct' directive fixed it.  Now, I dont know why it happened, nor know
> how to prevent it happening with other variables.  Here is the output of
> the Sections from the .lst file ... (atMega128 processor)..
> 
> Sections:
> Idx Name          Size      VMA       LMA       File off  Algn
>   0 .data         000000aa  00800100  0000014e  00000202  2**0
>                   CONTENTS, ALLOC, LOAD, DATA
>   1 .text         0000014e  00000000  00000000  000000b4  2**0
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>   2 .bootloader   000007f2  0001e000  0001e000  000002ac  2**0
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>   3 .bss          00000004  008001aa  008001aa  00000a9e  2**0
>                   ALLOC
>   4 .noinit       00000000  008001ae  008001ae  00000a9e  2**0
>                   CONTENTS
>   5 .eeprom       00000000  00810000  00810000  00000a9e  2**0
>                   CONTENTS
>   6 .stab         0000162c  00000000  00000000  00000aa0  2**2
>                   CONTENTS, READONLY, DEBUGGING
>   7 .stabstr      00000bbc  00000000  00000000  000020cc  2**0
>                   CONTENTS, READONLY, DEBUGGING
> 
> 
> Any thoughts?  
> 
> Thanks,
> Reza
> 
> _______________________________________________
> avr-gcc-list mailing list
> address@hidden
> http://www.avr1.org/mailman/listinfo/avr-gcc-list


reply via email to

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