Hi,
I have a weird error:
c:/intelfpga_lite/18.1/nios2eds/bin/gnu/h-x86_64-mingw32/bin/../lib/gcc/nios2-elf/5.3.0/../../../../../H-x86_64-mingw32/nios2-elf/bin/ld.exe: address 0x10043600 of CPU0_OSII.elf section `.bss' is not within region `cpu_0_cpu_0_memory'
Which is correct as the address range of the memory goes from 0x1002_000 to 0x1003_ffff. But I don't understand why this error happens. The other processor has the same configuration but no compilation error.
What did I do wrong?
Thanks
Hi,
The address the compiler is complaining about, 0x10043600, is not within the bounds you say your CPU has for the memory (0x1002000-0x1003FFFF).
Did you allocate a large amount of memory on the heap in your C code? Perhaps a large array?
Look on the NIOSII, the bit addresses available. If I remember well, they output them A26..A0 NOT A31..A0.
Thus the address 0x1xxx_xxxx cannot be accessed.
RB
Hi,
I don't have a solution but I encountered the same problem.
It happens when I use the printf function with a variable, such as "printf("toto=%d", toto);". If the printf is given a constant string, this error doesn't happen. So the printf function probable need a large amount of heap space when used with variables.
As for what Jonathan faced, when you use the variable integer of printf it would require a much bigger space in memory compared to just printing a constant string. There would be the added lines to read from memory, store the variable locally, calling a few lines that convert each the integer into a string which might be using a very big index that will take a lot of memory. I've not dug deep into how printf is working, but as you seen the added memory requirements are big enough so that you don't have space on your memory to store your code anymore because of that.
So yes, it seems that the printf function is causing that, but only on one processor (same code on both) and both have the same amount of memory allocated.
Strange...
Hi,
I had similar issue. Your code is too big for your memory. So the compiler complains about not being able to place .bss on the onchip memory as the address the compiler gave some section is 0x10043600.
If you want to see exactly how much space the different parts of the code take you can look at the .map file the compiler generates. From what you wrote you are short on at least 0x3600 bytes of memory to be able to download the code to your device.
Okay, got it to work!
When the bsp was generated, it linked the sdram region to the available memory regions.
The linker was also set to sdram_controller_0
Setting all the linker region to the onchip memory, was not enought, I had to delete the region from the "Linker Memory Regions".
This made that the compiled code took 20k less memory. The sdram is still available throught the avalon bus as expected.
So finally, problem solved :)
Follow the pulses of EPFL on social networks
© 2023 EPFL, all rights reserved