extrernal SRAM - how to tell avr-ld the size

Go To Last Post
10 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm migrating an old Atmel Studio 7 project to MPLAB X IDE v5.30 with AVR-GCC 5.4.0.

My ATmega128 has an external parallel SRAM via XMEM interface.

I'm manually placing certain arrays to external ram, by defining .xmem section in avr-ld options and using __attribute__ ((section (".xmem"))) in C code.

It compiles and builds so far, but:

- I see no change in .hex regardless if "External RAM check for memory overflow" is selected or not

- there is no error when the section gets too big to fit in memory;

- there is no error/warning if a variable in .xmem is "initialized" in declaration (unlike with .noinit);

- .hex file contains .xmem content as well

- all address lines are used in my case, but what if, say, a 32Kbyte SRAM chip were used?

 

Is there any way easier than a handmade linker script to solve these problems?

 

Alternatives I thought about:

- calling avr-readelf -t post-build and checking section size, but this is awkward

- writing linker script manually, defining XRAM region and .xmem as section within and letting avr-ld do the check

- using .noinit section, but according to AVRLibcReferenceManual it seems to be part of .data

 

PS: I do set SRE, SRW in MCUCR in .init1

 

memory map, ATmega128 with external SRAM

 

MPLAB X IDE, linker options

Test program:

int bar = 17; //goes to .data
int foo;      //goes to .bss

char xtern1[32767] __attribute__ ((section (".xmem")));
char xtern2[32767] __attribute__ ((section (".xmem")));
char xtern3[32767] __attribute__ ((section (".xmem"))); //want build error here

int main() {
    foo++;
    bar++;
    xtern1[0]++;
    xtern2[0]++;
    xtern3[0]++;
    while(1);
}

.lss file shows correct placement and size (which is too big)

  1 .xmem         00017ffd  00801100  00801100  000001d0  2**0
                  CONTENTS, ALLOC, LOAD, DATA

.map file

Address of section .data set to 0x800100
Address of section .xmem set to 0x801100

.xmem           0x0000000000801100    0x17ffd
 .xmem          0x0000000000801100    0x17ffd build/default/production/mainprog.o
                0x0000000000801100                xtern3
                0x00000000008090ff                xtern2
                0x00000000008110fe                xtern1

avr-readelf -t output

  [ 2] .xmem
       PROGBITS        00801100 0001d0 017ffd 00   0   0  1
       [00000003]: WRITE, ALLOC

 

Stuff I checked:

https://www.microchip.com/webdoc/AVRLibcReferenceManual/malloc_1malloc_tunables.html

https://www.nongnu.org/avr-libc/user-manual/mem_sections.html#c_sections

 

 

This topic has a solution.
Last Edited: Wed. Feb 5, 2020 - 10:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just throw together a bit of Python to post process the tool output.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You could put in something to run into-

 

//-Wl,-section-start=.xmem_end=0xffff
volatile char xtern_end __attribute__ ((section (".xmem_end")));

 

int main() {
    (void)xtern_end; //so doesn't optimize away (along with volatile in definition)

   ...

 

but that only removes one item from your list.

 

At some point it just becomes easier to quit fighting it, and just modify/create a project specific linker script. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Thanks for your replies.

Question first: given my device choice, MPLAB uses its own "avr51.xn" linker script.

  • How can I supply correct __DATA_REGION_LENGTH__ value? Putting a #define into .c didn't help.
    • EDIT: Own answer: add --defsym=__DATA_REGION_LENGTH__=0xff00 to linker options
  • How can I "print" the value used by linker? I found experimentally that it corresponds to built-in RAM size.
__DATA_REGION_LENGTH__ = DEFINED(__DATA_REGION_LENGTH__) ? __DATA_REGION_LENGTH__ : 0xff00;

What I did, for record:

 

Added --verbose to linker options in project settings and saw that "avr51.xn" linker script is used.

Used -T linker option and used "my_avr51.xn" with .xmem section added

.xmem 0x801100 : { *(.xmem) } > data

EDIT: this seems to be not the same as .xmem=0x1100 in linker options. The latter does result in .xmem section placement at 0x801100, but its size limit is wrong.

Got it linking after changing __DATA_REGION_LENGTH__ to fixed 0xff00:

__DATA_REGION_LENGTH__ = 0xff00;

And this is how much fits in .xmem, one byte more and linker returns error, so far o.k.

char xtern1[32767] __attribute__ ((section (".xmem")));
char xtern2[28417] __attribute__ ((section (".xmem")));

Made "my_avr51.xn" again identical to original "avr51.xn" and added .xmem=0x1100 segment through project settings. Links o.k.

 

This is why it looks to me that I "just" need to supply a correct __DATA_REGION_LENGTH__ value and then I don't need to supply my own linker script.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Might I ask why you simply did not stay with using Studio since the project was created in that to begin with?

 

Seems odd(to me at least) to move an established project to a new platform.

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MaxMn wrote:
then I don't need to supply my own linker script.
You do know it is "easy" to use your own script? All you do is check a map file to find out which of the system linker scripts is currently be used. Take a copy of that file to your own project directory and make whatever small edits you require (like setting REGION_LENGTH) then just add -Wl,-T,newscript.x (or whatever you have called it) to your build invocation. Now it uses the modified file.

 

It's not like you need to write a new cone completely from scratch - just copy and make a one line edit or whatever it is.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You're right. After all, I only added one line to vendor's avr51.xn after plugging it in as "my own" linker script.

.xmem 0x801100 : { *(.xmem) } > data

I wasn't able to find a hint about linker script in use in the .map file, but --verbose linker option helped.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A very legitimate question. This is the last project which keeps my Win7 PC alive; no plans to go to Win10. Moving from WinAVR-20100110 (within Atmel Studio 7) to a newer AVR-GCC 5.4.0 (within MPLAB X IDE on linux) is an arguably useful side effect.

 

What I'd like even more is to migrate it to a different MCU, though... *sigh*

 

jgmdesign wrote:

... why you simply did not stay with using Studio ...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What version of windows is your MPLAB application running on?  Or are you using a linux/Mac OS?

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MPLAB X IDE v5.30 on Ubuntu 18.04.4 LTS

avr8-gnu-toolchain-3.6.2.1759-linux.any.x86_64

 

jgmdesign wrote:

What version of windows is your MPLAB application running on?  Or are you using a linux/Mac OS?