I have this in my .map file (GCC, Cortex-M) .bss 0x20000108 0x2c90 load address 0x00028793 0x20000108 _bss = . FLASH starts at 0x0, and RAM starts at 0x20000000. From other parts of the .map file, it looks like my app fills 0x0 - 0x0002868c, which makes sense according to the size of the .bin I'm programming in. I've had errors before from the linker when I turn off optimization and the binary gets larger, because I reserve everything starting from 0x36000 for other data, even though I'm not seeing anything beyond the last .rodata.
Hi Jerry, I'll try to explain... BSS is a section which means (B)lock (S)tarted by (S)ymbol. Don't care about the name. In this section all static variables and static data collected which are not initialized with data. This block needs no room in the created binary file as it contains no data, only the length and start address (in your case 0x20000108) is important for address calculations. Most startup codes use the symbols (e.g. '__bss_start', '__bss_end__'), provided by the linker and wash(x) the memory with zero at startup with the provided addresses. Here is also a link to WIKIPEDIA: http://en.wikipedia.org/wiki/.bss Hopefully you understand my explanation as I'm not a native english speaker ;-) 900ss (x) This word I found in the past for a function to fill memory with zero and I like it ;-)
I understand you perfectly, but am still a little confused by this. I'll be more specific by explaining the exact problem better: I compiled with -o0 (no optimization), so my code got a little bigger. It's not the way I plan on running it, but it's good for debugging. For any new viewers of this message, I have a Cortex-M3 and using GCC. FLASH is from 0x0 - 0x3FFFF, and SRAM is from 0x20000000 - 0x20017FFF. I'm using __attribute__((section("scstation0"))) to place "scstation0" starting at 0x36000. The application is filling 0x0 - 0x34dc0, based upon (my best guess) the .map file. I also double checked by looking at the size of the resulting .bin file if I temporarily REMOVE "scstation0"; in this case it's 0x34EB7 in length. So, the point is, it seems the application is getting nowhere close to the 0x36000 where "scstation0" starts. But, when I link I see this: c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/arm-none-eabi/4.3 .3/../../../../arm-none-eabi/bin/ld.exe: section scstation0 [00036000 -> 00037fc 3] overlaps section .bss [00034ec7 -> 00037b16] collect2: ld returned 1 exit status make: *** [RTOSDemo.axf] Error 1 So .bss claims to run all the way to 0x37B16, but my application writes non-volatile data during run-time anyway to "scstation0" and I have no problems. What does this actually all mean? Please see below for part of the .map file which was generated with -o0, which has different addresses than my initial post. .data 0x20000100 0x8 c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/arm-none-eabi/4.3.3/../../../../arm-none-eabi/lib/th umb2\libc.a(lib_a-ctype_.o) 0x20000100 __ctype_ptr 0x20000104 _ctype_ptr_ 0x20000108 _edata = . .bss 0x20000108 0x2c50 load address 0x00034ec7 0x20000108 _bss = . *(.bss*)
Jerry Milner wrote: > I'm using __attribute__((section("scstation0"))) to place "scstation0" > starting at 0x36000. Where you give the linker the information that scstation0 start at 0x36000? > ...., but my application writes > non-volatile data during run-time anyway to "scstation0" and I have no > problems. This makes me wondering, as the location is in the Flash memory. How you wrote data in there? You have to use special flash write functions otherwise no data is written there. Sorry, I don't know why the secion bss overlaps with your scstation0. In my opinion the bss don't have to reserve space in the flash rom but the error message let us learn others!? I take a look at my map files and the it seems to be the same. A good idea is to post the linkerscript and also the output of your make process. So also people looking here can see more details.
It is interesting to note that the length of [00034ec7 -> 00037b16] is the same as the size of your BSS section. I wonder if this is an issue with your linker script. I suggest that you post that and probably the complete map file.
Attached is the .map and linker file.
By the way, to answer 900ss I tell the linker that my data section starts at 0x36000 by using in the makefile: -Wl,--section-start=scstation0=0x036000
Jerry Milner wrote: > Attached is the .map and linker file. I think change: .bss : to .bss (NOLOAD) : in the linker script. Clifford
Thank you, that fixed it. I haven't tried running the binary yet but I believe it was strictly a linker problem.
Jerry, can you please post the new mapfile? I tried the NOLOAD also a few days ago, when you post your problem, but I saw no changes in the mapfile in my small test project. That's the reason why I don't post that. Now I like to know if there is a difference in your mapfile. Thank you.
It looks like it didn't change my mapfile, either. Here's the lines that I believe was causing problems before: .data 0x200000fc 0x8 c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/arm-none-eabi/4.3.3/../../../../arm-none-eabi/lib/th umb2\libc.a(lib_a-ctype_.o) 0x200000fc __ctype_ptr 0x20000100 _ctype_ptr_ 0x20000104 _edata = . .bss 0x20000104 0x3034 load address 0x00028377 0x20000104 _bss = . The linker doesn't complain anymore though. Perhaps the NOLOAD just tells the linker that nothing is going in that region, so it doesn't generate an error. Oh, to answer your question about writing to Flash memory, yes, I have to use registers on the micro to write to Flash. Not all micros are able to, but I believe mostly the lower end ones aren't able to.
OK, then it looks the same as in my try. I guess yo are right, it tells the linker nothing to load, but he didn't change the map file. And yes, for the writing to flash I was wondering a little bit.... :-) Thank you.
900ss wrote: > OK, then it looks the same as in my try. I guess yo are right, it tells > the linker nothing to load, but he didn't change the map file. > Since the linker aborted in an error, it seems likely that it would not have generated a map file, so the map file shown would have been from an earlier successful build.