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 回复数
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".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. thanksSoin,
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. MikeHi 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?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...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.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?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't within your array.
One possible explanation is that in your application code you are over running the end of buff1_app, or have some other kind of memory over write. If this was the case then the changes in memory organisation could cause the otherwise apparently harmless over write to cause a problem.
However that doesn't tie with it working on JTAG download, but not when booting from flash. If it only fails on boot from flash, then that would suggest the problem is related to how the bootloader loads the code. Could this be a cache coherency problem? Do you have any cache in your system? If so, try disabling the caches and see if that changes the behaviour.I usually get a similar error when I try to use the attribute compiler flag, putting in a section name that does not exist.
for example, writing <div class='quotetop'>QUOTE </div> --- Quote Start --- volatile int my_shared_data __attribute__ ((section (".fake")));;[/b] --- Quote End --- gives me the following error: <div class='quotetop'>QUOTE </div> --- Quote Start --- 16-mag-2005 12.26.47 - (GRAVE) elf2flash: Boot copier overlaps data in flash 16-mag-2005 12.26.48 - (GRAVE) elf2flash: Error generating Flash file, exiting[/b] --- Quote End ---