Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
20 years ago

"__attribute__((section(".SDRAM")))" problem

Hi all,

I'm trying to allocate a buffer in SDRAM using the declaration:

volatile int buff1_app[1280] __attribute__((section(".SDRAM")));

in SOPC i've defined a SDRAM controller named "sdram".

I've set the reset address of my system in flash, exception address,program and data memory resides in SDRAM. When i compile i receive the error message:

*** [ext_flash.flash] Error 5

H320_prove Error 5-mag-2005 12.29.36 - * *** [ext_flash.flash] Error 5 Boot copier overlaps data in flash H320_prove line 0 Error

5-mag-2005 12.29.36 - * Boot copier overlaps data in flash Error generating Flash file, exiting H320_prove line 0

if i define the buffer:

volatile int buff1_app[1280] ;

everything works fine.

Any suggestion?

14 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    20 years ago

    I'd expect to see this error if you had (for example) left your .rodata in flash while your .text sections was in sdram. Check your system library properties are really set correctly.

    Also, the tools are case sensitive, so if you have named your memory sdram then you should assign your data to ".sdram" not ".SDRAM".
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    20 years ago

    Hi monkeyboy,

    if I use lowcase:

    volatile int buff1_app[1280] __attribute__((section(".sdram")));

    I have no compilation error.

    I download my code in flash, power on the board, the program boots but, after some printf, it stops its execution.

    If i declare my buffer:

    volatile int buff1_app[1280];

    everything works.

    What's the difference between the two declarations? In my system library properties i have program data,read only data, read\write data in sdram.

    thanks
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    20 years ago

    Hi MIR,

    I've read your old topic but I'm not sure it's my case. My SDRAM signals are not shared on avalon tri-state bus, with other peripheral: I have the SDRAM controller component, whose signals are connected only with my SDRAM. In particular my design has two CPUs, and each one can access SDRAM.

    Any ideas?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    20 years ago

    Probably a stupid question, on my part, but do you have a Mutex to avoid SDRAM access collisions?

    - slacker
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    20 years ago

    Hi slacker,

    I don't have a mutex, but the SDRAM controller has an avalon slave port connected with various avalon master (instruction and data master of CPU1 and data master of CPU2...), so there must be an avalon arbiter that manage the access.Isn't it?

    Furthermore my system works without the "attribute" definition...
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    20 years ago

    The difference between your two declerations is where in SDRAM your buffer will be placed. The decleration:

    volatile int buff1_app[1280] __attribute__((section(".sdram")));

    will place the buffer after the .rodata and .rwdata sections, and immediately before the heap. The decleration:

    volatile int buff1_app[1280];

    will place it somewhere inside the .rwdata section.

    It could be that your stack and data are colliding, and the changes in memory layout is making you more sensitive to the problem. If you are using the 5.0 version of the kit, you could turn on stack checking to determine if this is the case.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    20 years ago

    Hi monkeyboy,

    thank u for the precious information.

    <div class='quotetop'>QUOTE </div>

    --- Quote Start ---

    It could be that your stack and data are colliding, and the changes in memory layout is making you more sensitive to the problem[/b]

    --- Quote End ---

    I don&#39;t think this could be the reason. Because my system works even if I allocate my buffer dinamically (malloc...), so it stays in the heap and stack should collide with heap...

    Instead my conjecture is that there could be problem with "attribute" location and the heap (maybe the heap averlaps attribute zone...).Could it be?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    20 years ago

    If you check your linker script (generated.x) you should find the section: 

        .sdram :
    {
        PROVIDE (_alt_partition_sdram_start = ABSOLUTE(.));
        *(.sdram .sdram.*)
        . = ALIGN(32 / 8);
        PROVIDE (_alt_partition_sdram_end = ABSOLUTE(.));
        _end = ABSOLUTE(.);
        end = ABSOLUTE(.);
    } > sdram

    The symbol end is used for the start of the heap, and the above linker fragment will ensure that it is immediately after anything placed into the .sdram section. You can easily check that this really works by calling malloc() and checking that the returned address isn&#39;t within your array.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    20 years ago

    Yes,u r right: i&#39;ve verified it through some printf in the code, the addresses don&#39;t overlap.

    If u have other ideas, they r welcomed...