This is a duplicate from sparkfun electronics forum:
PC side:
IAR Elf Linker for ARM 5.30.0.51174 (5.30.0.51174)
H-JTAG server v0.9.0
HW Side:
Olimex LPC2378STK
IAR RAM DEBUG Settings:
define symbol __ICFEDIT_region_ROM_start__ = 0x00;
define symbol __ICFEDIT_region_ROM_end__ = 0x00;
define symbol __ICFEDIT_region_RAM_start__ = 0x40000044;
define symbol __ICFEDIT_region_RAM_end__ = 0x40007FFF;
place in RAM_region { readonly };
place in RAM_region { readwrite,
block CSTACK, block SVC_STACK, block IRQ_STACK, block FIQ_STACK,
block UND_STACK, block ABT_STACK, block HEAP };
Error[Lp011]: section placement failed: unable to allocate space for
sections/blocks with a total estimated minimum size of 0x8990
bytes in <[mem:0x40000044-mem:0x40007fff]> (total uncommitted space
0x7fbc)
Workaround:
To get rid of this message, I modified CSTACK from 0x2000 to 0x1000. I
don't like this but I don't know other solution.
Another option was to increase the optimization level in debug, which I
don't want. I keep it at NONE.
What can I do because the code is not finished and is growing?
Thank you
Out of ram memory when trying to debug with IAR (LPC2378)
Started by ●March 27, 2009
Reply by ●March 28, 20092009-03-28
Mircea Stanciu schrieb:
> Another option was to increase the optimization level in debug, which I
> don't want. I keep it at NONE.
Optimization has nearly no effect on RAM usage.
>
> What can I do because the code is not finished and is growing?
Get a bigger chip or external RAM.
Reduce heap, stack and check your real stack-usage.
--
42Bastian
Note: SPAM-only account, direct mail to bs42@...
> Another option was to increase the optimization level in debug, which I
> don't want. I keep it at NONE.
Optimization has nearly no effect on RAM usage.
>
> What can I do because the code is not finished and is growing?
Get a bigger chip or external RAM.
Reduce heap, stack and check your real stack-usage.
--
42Bastian
Note: SPAM-only account, direct mail to bs42@...
Reply by ●March 28, 20092009-03-28
--- In l..., 42Bastian wrote:
>
> Mircea Stanciu schrieb:
>
> > Another option was to increase the optimization level in debug, which I
> > don't want. I keep it at NONE.
>
> Optimization has nearly no effect on RAM usage.
>
> >
> > What can I do because the code is not finished and is growing?
>
> Get a bigger chip or external RAM.
>
> Reduce heap, stack and check your real stack-usage.
>
The OP is debugging in RAM:(
The 2378 has 512K of flash, so moving the code to flash seems like a sensible option.
Rgds,
Martin
>
> Mircea Stanciu schrieb:
>
> > Another option was to increase the optimization level in debug, which I
> > don't want. I keep it at NONE.
>
> Optimization has nearly no effect on RAM usage.
>
> >
> > What can I do because the code is not finished and is growing?
>
> Get a bigger chip or external RAM.
>
> Reduce heap, stack and check your real stack-usage.
>
The OP is debugging in RAM:(
The 2378 has 512K of flash, so moving the code to flash seems like a sensible option.
Rgds,
Martin
Reply by ●March 29, 20092009-03-29
mjames_doveridge schrieb:
> The OP is debugging in RAM:(
I could not see it from the info he sent.
--
42Bastian
Note: SPAM-only account, direct mail to bs42@...
> The OP is debugging in RAM:(
I could not see it from the info he sent.
--
42Bastian
Note: SPAM-only account, direct mail to bs42@...
Reply by ●March 30, 20092009-03-30
--- In l..., "mjames_doveridge" wrote:
>
> --- In l..., 42Bastian wrote:
> >
> > Mircea Stanciu schrieb:
> >
> > > Another option was to increase the optimization level in debug, which I
> > > don't want. I keep it at NONE.
> >
> > Optimization has nearly no effect on RAM usage.
> >
> > >
> > > What can I do because the code is not finished and is growing?
> >
> > Get a bigger chip or external RAM.
> >
> > Reduce heap, stack and check your real stack-usage.
> > The OP is debugging in RAM:(
>
> The 2378 has 512K of flash, so moving the code to flash seems like a sensible option.
>
> Rgds,
> Martin
>
I thought to movo the code into flash but I don't know how to debug anymore :(
>
> --- In l..., 42Bastian wrote:
> >
> > Mircea Stanciu schrieb:
> >
> > > Another option was to increase the optimization level in debug, which I
> > > don't want. I keep it at NONE.
> >
> > Optimization has nearly no effect on RAM usage.
> >
> > >
> > > What can I do because the code is not finished and is growing?
> >
> > Get a bigger chip or external RAM.
> >
> > Reduce heap, stack and check your real stack-usage.
> > The OP is debugging in RAM:(
>
> The 2378 has 512K of flash, so moving the code to flash seems like a sensible option.
>
> Rgds,
> Martin
>
I thought to movo the code into flash but I don't know how to debug anymore :(
Reply by ●March 30, 20092009-03-30
> > > Another option was to increase the optimization
level in debug, which I
> > > don't want. I keep it at NONE.
>> > Optimization has nearly no effect on RAM usage.
Have not used IAR compilers for years, but on GCC using -O1 -O2 etc. certainly makes a significant difference in RAM space.
> > > What can I do because the code is not finished and is growing?
Read your map output file and carefully inspect the RAM area. Check the lines which have large size. Make sure you understand where the big chunks of RAM are, and who is using them. Often you can find some surprises you did not expect, or were not aware of.
> > > don't want. I keep it at NONE.
>> > Optimization has nearly no effect on RAM usage.
Have not used IAR compilers for years, but on GCC using -O1 -O2 etc. certainly makes a significant difference in RAM space.
> > > What can I do because the code is not finished and is growing?
Read your map output file and carefully inspect the RAM area. Check the lines which have large size. Make sure you understand where the big chunks of RAM are, and who is using them. Often you can find some surprises you did not expect, or were not aware of.
Reply by ●March 30, 20092009-03-30
--- In l..., "Mircea Stanciu" wrote:
>
> --- In l..., "mjames_doveridge" wrote:
> >
> > --- In l..., 42Bastian wrote:
> > >
> > > Mircea Stanciu schrieb:
> > >
> > > > Another option was to increase the optimization level in debug, which I
> > > > don't want. I keep it at NONE.
> > >
> > > Optimization has nearly no effect on RAM usage.
> > >
> > > >
> > > > What can I do because the code is not finished and is growing?
> > >
> > > Get a bigger chip or external RAM.
> > >
> > > Reduce heap, stack and check your real stack-usage.
> > >
> >
> > The OP is debugging in RAM:(
> >
> > The 2378 has 512K of flash, so moving the code to flash seems like a sensible option.
> >
> > Rgds,
> > Martin
> >
> I thought to movo the code into flash but I don't know how to debug anymore :(
>
Why not? What is different?
Loading the flash via JTAG/FlashMagic/whatever does take more time than loading RAM, but it's not long enough to affect your overall debugging much, (well not my debugging, anyway - most of my time spent staring at board/screen wondering "it still locks up, what the f*** do I do now?").
Rgds,
Martin
>
> --- In l..., "mjames_doveridge" wrote:
> >
> > --- In l..., 42Bastian wrote:
> > >
> > > Mircea Stanciu schrieb:
> > >
> > > > Another option was to increase the optimization level in debug, which I
> > > > don't want. I keep it at NONE.
> > >
> > > Optimization has nearly no effect on RAM usage.
> > >
> > > >
> > > > What can I do because the code is not finished and is growing?
> > >
> > > Get a bigger chip or external RAM.
> > >
> > > Reduce heap, stack and check your real stack-usage.
> > >
> >
> > The OP is debugging in RAM:(
> >
> > The 2378 has 512K of flash, so moving the code to flash seems like a sensible option.
> >
> > Rgds,
> > Martin
> >
> I thought to movo the code into flash but I don't know how to debug anymore :(
>
Why not? What is different?
Loading the flash via JTAG/FlashMagic/whatever does take more time than loading RAM, but it's not long enough to affect your overall debugging much, (well not my debugging, anyway - most of my time spent staring at board/screen wondering "it still locks up, what the f*** do I do now?").
Rgds,
Martin
