Forum Discussion
Altera_Forum
Honored Contributor
Honored Contributor"__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_ForumI'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
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
Soin,
Are your SDRAM signals shared on avalon tri-state bus? I also had a problem with hanging CPU ... see topic: cpu hangs after sdram-refresh (http://www.niosforum.com/forum/index.php?act=st&f=2&t=1038&hl=) This behaviour should be resolved with Quartus/NIOSII 5.0. Your section name depends on what you've entered in SOPC builder as device name. Mike - Altera_Forum
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
Probably a stupid question, on my part, but do you have a Mutex to avoid SDRAM access collisions?
- slacker - Altera_Forum
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
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
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'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
If you check your linker script (generated.x) you should find the section:
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't within your array..sdram : { PROVIDE (_alt_partition_sdram_start = ABSOLUTE(.)); *(.sdram .sdram.*) . = ALIGN(32 / 8); PROVIDE (_alt_partition_sdram_end = ABSOLUTE(.)); _end = ABSOLUTE(.); end = ABSOLUTE(.); } > sdram - Altera_Forum
Yes,u r right: i've verified it through some printf in the code, the addresses don't overlap.
If u have other ideas, they r welcomed...
