Lpc2000

--- In lpc2000@yahoogroups.com, "xjag74" <detlef.weidner@w...> wrote:
> Check your *.ld file.
> I've these entries for the uninitialized data.
> Do you have the line with " . = ALIGN(4);" ?

Yes, these lines look exactly the same in my .ld file, including " . =
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!
> > :)