Lpc2000

Check your *.ld file.
I've these entries for the uninitialized data.
Do you have the line with " . = ALIGN(4);" ?

  .bss :
  {
    __bss_start = . ;
    __bss_start__ = . ;
    *(.bss)
    *(COMMON)
  } >DATA
  . = ALIGN(4);
  __bss_end__ = . ;
  __bss_end__ = . ;



--- In lpc2000@yahoogroups.com, "arkeryd" <arkeryd@y...> wrote:
> These exact 12 bytes of bss memory, occupied by __uClibc_main.o, 
cause
> the trouble. Normally main() won't start, but if doing a workaround 
in
> startup.s so that these bytes are not cleared, then main() starts.
> 
> (
> .map file extract:
>  .bss           0x40000b0c        0xc
> /cygdrive/c/Cygnus/Arm-Tools/Bin/../lib/gcc-lib/ar
> m-thumb-elf/3.3.1/../../../../arm-thumb-elf/lib/li
> bc.a(__uClibc_main.o)
>                 0x40000b0c                __environ
>                 0x40000b0c                environ
>                 0x40000b10                __progname
> )
> 
> What could it be?
> 
> Kind Regards
> 
> / DA
> 
> --- In lpc2000@yahoogroups.com, "arkeryd" <arkeryd@y...> wrote:
> > According to debug session trough simulator,
> > R1 (bss start) is loaded with 0x40000380 and R2 (bss end) with
> > 0x40001748, in other words the exact same addresses as in the .map
> > file.
> > 
> > 
> > After investigating further I have found that the range of memory,
> > where clearing causes software to hang, is the same as bss range
> used
> > by standard c libraries, below follows excerpt from the .map file.
> > 
> > Feels weirder and weirder...
> > 
> > .bss           0x40000b0c        0xc
> > /cygdrive/c/Cygnus/Arm-Tools/Bin/../lib/gcc-lib/ar
> > m-thumb-elf/3.3.1/../../../../arm-thumb-elf/lib/li
> > bc.a(__uClibc_main.o)
> >                 0x40000b0c                __environ
> >                 0x40000b0c                environ
> >                 0x40000b10                __progname
> >  .bss           0x40000b18        0xc
> > /cygdrive/c/Cygnus/Arm-Tools/Bin/../lib/gcc-lib/ar
> > m-thumb-elf/3.3.1/../../../../arm-thumb-elf/lib/li
> > bc.a(__exit_handler.o)
> >                 0x40000b1c                __exit_function_table
> >                 0x40000b18                __exit_count
> >                 0x40000b20                __exit_slots
> >  .bss           0x40000b24        0x4
> > /cygdrive/c/Cygnus/Arm-Tools/Bin/../lib/gcc-lib/ar
> > m-thumb-elf/3.3.1/../../../../arm-thumb-elf/lib/libc.a(exit.o)
> >                 0x40000b24                __exit_cleanup
> >  .bss           0x40000b28        0x4
> > /cygdrive/c/Cygnus/Arm-Tools/Bin/../lib/gcc-lib/ar
> > m-thumb-elf/3.3.1/../../../../arm-thumb-elf/lib/libc.a(abort.o)
> >  .bss           0x40000b2c       0x98
> > /cygdrive/c/Cygnus/Arm-Tools/Bin/../lib/gcc-lib/ar
> > m-thumb-elf/3.3.1/../../../../arm-thumb-elf/lib/libc.a(malloc.o)
> >  .bss           0x40000bc4        0x4
> > /cygdrive/c/Cygnus/Arm-Tools/Bin/../lib/gcc-lib/ar
> > m-thumb-elf/3.3.1/../../../../arm-thumb-elf/lib/libc.a(brk.o)
> >                 0x40000bc4                ___brk_addr
> >  .bss           0x40000bc8        0x8
> > /cygdrive/c/Cygnus/Arm-Tools/Bin/../lib/gcc-lib/ar
> > m-thumb-elf/3.3.1/../../../../arm-thumb-elf/lib/libc.a(errno.o)
> >                 0x40000bcc                _h_errno
> >                 0x40000bc8                errno
> >                 0x40000bcc                h_errno
> >                 0x40000bc8                _errno
> >  .bss           0x40000bd0        0xa
> > /cygdrive/c/Cygnus/Arm-Tools/Bin/../lib/gcc-lib/ar
> > m-thumb-elf/3.3.1/../../../../arm-thumb-elf/lib/li
> > bc.a(_ppfs_parsespec.o)
> >  *fill*         0x40000bda        0x2 00
> >  .bss           0x40000bdc        0x8
> > /cygdrive/c/Cygnus/Arm-Tools/Bin/../lib/gcc-lib/ar
> > m-thumb-elf/3.3.1/../../../../arm-thumb-elf/lib/libc.a
(mbsrtowcs.o)
> >  .bss           0x40000be4        0x8
> > /cygdrive/c/Cygnus/Arm-Tools/Bin/../lib/gcc-lib/ar
> > m-thumb-elf/3.3.1/../../../../arm-thumb-elf/lib/
> libc.a(__mbsnrtowcs.o)
> >  .bss           0x40000bec      0x200
> > /cygdrive/c/Cygnus/Arm-Tools/Bin/../lib/gcc-lib/ar
> > m-thumb-elf/3.3.1/../../../../arm-thumb-elf/lib/
> libc.a(_stdio_init.o)
> > 
> > 
> > Kind Regards
> > 
> > / DA
> > 
> > 
> > --- In lpc2000@yahoogroups.com, "xjag74" <detlef.weidner@w...>
> wrote:
> > > Hi,
> > > 
> > > try to figure out with which values R1 und R2 are loaded before
> the 
> > > loop (the values for the symbols __bss_start__ and __bss_end__).
> > > 
> > > Regards
> > > XJAG
> > > 
> > > --- In lpc2000@yahoogroups.com, "arkeryd" <arkeryd@y...> wrote:
> > > > Thanks, but...
> > > > 
> > > > I checked the .map file and it shows the same thing, the bss
> area 
> > > ends
> > > > at address 0x40001748.
> > > > 
> > > > The ram area ranges from 0x40000000 to 0x40003FFF and the 
stack
> > is 
> > > at
> > > > the end of the ram area, and total stack size is below 0x500
> > bytes.
> > > > 
> > > > So as described below, it does't look like is an overlap
> > conflict, 
> > > but
> > > >     main() refuses to start unless commenting out the clear 
bss
> > code
> > > > from startup.s.  
> > > > 
> > > > I can't even get some dummy code just setting the leds - 
using 
> > > MBC2100
> > > > dev board - followed by an eternal looop at beginning of main
()
> to
> > > > run, unless commenting out the code for clearing bss section.
> > > > 
> > > > Kind Regards
> > > > 
> > > > / DA
> > > > 
> > > > 
> > > > 
> > > > --- In lpc2000@yahoogroups.com, "xjag74" 
<detlef.weidner@w...> 
> > > wrote:
> > > > > Hi,
> > > > > 
> > > > > have a look to the Map-file.
> > > > > Check if the bss area is within the range of the RAM memory
> > area 
> > > > > (below the stack area).
> > > > > 
> > > > > regards
> > > > > xjag
> > > > > 
> > > > > 
> > > > > --- In lpc2000@yahoogroups.com, "arkeryd" <arkeryd@y...>
> wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > After adding several new source files to my application 
for
> > > > LPC2129,
> > > > > > it hangs when jumping from startup.s to main(). 
> > > > > > 
> > > > > > The first thing that came to my mind was that perhaps too
> > much 
> > > ram
> > > > > > memory was now used.
> > > > > > However, after checking by running startup.s trough the 
> > > debugger,
> > > > it
> > > > > > doesn't seem like that.
> > > > > > I use the default startup.s for LPC2129.
> > > > > > 
> > > > > > The last address used by the .data- and .bss-sections
> > > > > > (variables/arrays) in my application is 0x40001748.
> > > > > > 
> > > > > > And this should not collide with stack either, as I use 
the
> > > > default
> > > > > > stack address and sizes:
> > > > > > Interrupt Mode size: 0x80
> > > > > > User/system mode size: 0x400
> > > > > > And just 4 bytes size in other modes.
> > > > > > Top of stack address: 0x40004000.
> > > > > > 
> > > > > > The weird thing is even though no memory collision should
> > occur,
> > > > the
> > > > > > application starts if I comment out the "Clear .bss 
section 
> > > code"
> > > > in
> > > > > > startup.s, so it must somehow be some collision, but I 
don't
> > > > > > understand why.
> > > > > > 
> > > > > > # Clear .bss section (Zero init)
> > > > > >                 MOV     R0, #0
> > > > > >                 LDR     R1, =__bss_start__
> > > > > >                 LDR     R2, =__bss_end__
> > > > > > LoopZI:         CMP     R1, R2
> > > > > >                 STRLO   R0, [R1], #4
> > > > > >                 BLO     LoopZI
> > > > > > 
> > > > > > Any input to clear my confusion would be much appreciated!
> :)