Linker script file for UC3C0512C and SDRAM

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

Hi everyone,

 

I have a 256 MBit SDRAM connect to a UC3C0512C, the memory works fine but the problem I´m  having is with the script file for the linker.

I´ve tried to use the application notes AVR32733, AVR32765 and also checked the link_uc3a0512_extsdram.lds file but I´m unable to get it to work with the UC3C0512C frown

I always end-up with linker errors when I try to declare a variable in the SDRAM, so I was just wandering if someone has a working version or example.

 

Thanks in advance!

 

Eric

This topic has a solution.
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi again,

 

I just want to add some additional information.

I´m using AtmelStudio 6.2.993 with ASF 3.22.0 and my goal is to be able to easily declare and use large arrays placed in the SDRAM, while the heap could stay in the internal ram for performance reasons (I hope this makes sense...) I´m attaching the linker script (extension changed from .lds to .txt)

If I declared and try to use a not initialised variable, such as BSS_SDRAM uint8_t sdram_test[128000]; with #define BSS_SDRAM __attribute__((__section__(".bss_sdram"))) then the linker stops with error "allocated section `.bss_sdram' not in segment"  I´m afraid I really struggle understanding the syntax of the linker script file.

 

Thanks again for any cues and help.

 

Regards:

 

Eric

 

Attachment(s): 

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

Is the linker using your .lds file ? (temporarily rename it, re-link and see what happens).
By default, Studio6 (via mysterious means) uses the .x linker files in program files\atmel\atmel toolchain\avr32 gcc\native\ .... \avr32-gnu-toolchain\avr32\lib\ldscripts
who the bleep created that structure ?

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

Hi Mikech,

 

Good point and thank you for the suggestion.

I´ve check and the linker is definitely loading the right script file (build fails if I rename the file).

 

Best regards:

 

Eric

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

You can sidestep modifying the linker file by doing your own memory 'management' with pointers.
ie. create a structure which contains all the variables that you want to be in the SDRAM, then create a pointer to that structure and set the contents of that pointer to the base of your SDRAM memory-region, then use the pointer to access the items in that structure.
It is not as convenient as simply placing the variables into the .sdram region, and it may be slower to get at those variables, but my brain hurts when I look at a linker-script.

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

I always end-up with linker errors when I try to declare a variable in the SDRAM,

Such as?

 

Also seeing the mods. you've made to the generic script would be good too.

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

Dear Mikech,

 

I´m on your side with the consequences of looking at a linker script frown

The reason I would like to stay away from managing manually the SDRAM with pointers is the risk of making mistake and creating potential runtime bugs difficult to detect.

At the end of the day, this what the compiler at linker are meant to be taking care of wink

 

Dear Clawson, the error I´m getting is the one I mentioned in my first post: "allocated section `.bss_sdram' not in segment"

 

The modifications I´ve made are in three areas:

 

1-) I added an extra entry in the MEMORY part:

 

  SDRAM (wxa!ri) : ORIGIN = 0xD0000000, LENGTH = 0x02000000

 

2-) I added two entries in the PHDRS part:

 

  SDRAM_AT_FLASH PT_LOAD;
  SDRAM PT_NULL;

 

3-) I added the following definitions in the SECTION area:

 

  . = ORIGIN(SDRAM);
  .data_sdram     ORIGIN(SDRAM) : AT ( LOADADDR(.balign) + SIZEOF (.balign) )
  {
    PROVIDE(_data_sdram = .);
    *(.data_sdram)
    . = ALIGN(8);
    PROVIDE(_edata_sdram = .);
  } >SDRAM :SDRAM_AT_FLASH

  PROVIDE(_data_sdram_lma = ABSOLUTE(LOADADDR(.data_sdram)));

  . = ALIGN(8);
  .bss_sdram :
  {
    PROVIDE(__bss_sdram_start = .);
    *(.bss_sdram)
    PROVIDE(_bss_sdram_end = .);
  } >SDRAM AT>SDRAM :SDRAM

 

The idea is to be able to use the bss_sdram for not initialised variables and data_sdram for initialised variables (based on the Atmel application notes).

 

I believe the error is in this last part where I guess I´m not properly referencing the SDRAM area...

I must admit I simply tried to re-use what I found in the example for the UC3A0512...

 

Thanks again for your time and suggestions:

 

Rgds:

 

Eric

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

Dear Menahem,

 

Thank you very much for the linksmiley!

I don´t know why I missed this one when I was searching in the forum.

 

I will try this approach and I will post the outcome...

 

Best regards:

 

Eric

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

Hello Eric,

 

Not at all, I really hope you can find a good solution.

Actually I'd never blame the site's search engine (as far as I can judge it is not bad at all), however this time it was an external hit by google.

 

Best wishes,

Menahem

 

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

Hello Menahem,

 

Thanks again for the link, it has been very valuable!

 

As indicated by jeffhenshaw in the referenced post, even if the "allocated section `.bss_sdram' not in segment" is displayed as an error is in fact only a warning, and does not prevent the build of the output files! Ok, I know Ishould have noticed this, but I guess I was asleep...

 

So as mentioned by jeffhenshaw, a way to get rid of the linker warning/error is to declare the memory as PT_LOAD in the PHDRS part, then the compiler will manage the allocation of the variables within the defined memory block and the linker will asume that a loader will take care of the initialisation, but if there´s no loader then nothing will happen.

 

However, there´s a downside, the declared variables will be created in the output files and (I guess) transfered to the programmer (in my case an AVR Dragon).

As a consequence, if you have declared large arrays, the "Load executable..." phase may take a significant amount of time, even if nothing gets loaded anywhere (as far I know).

So I guess the alternative is to either ignore the linker error, or to accept the programmer's delay.

 

At the end I've used the section declaration from jeffhenshaw and created just one unintialised segment (.bss_sdram), see attachment.

 

On a side note, you also need to change a Studio 6 script file so the size of the output code is not checked against the capacity of the MCU, otherwise the build process stops with an error. There´s some posts on the forum about this subject and the "official" version is also available in the Atmel knowledge base at http://atmel.force.com/support/articles/en_US/FAQ/Memory-overflow-error-with-external-SDRAM-project-for-AVR32-devices-in-Atmel-studio-6-2?q=RunOutputFileVerifyTask&l=en_US&fs=Search&pn=1

 

Thanks for all the help, regards:

 

Eric

 

Attachment(s):