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.

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.

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.