UC3B, malloc, and stack space

Go To Last Post
6 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I needed some more heap in a project so I got rid of all the printf statements and reduced the stack size from 4096 bytes downto 768 (the program without printf uses around 600 bytes maximum).

However, malloc keeps thinking that it should stop allocating when it gets 0x7000 instead of the new heap end of 0x7D00. I modified the .lds file to change from the hardcoded 0x1000 to 0x300 in a couple of places:

    . = ALIGN(8);
    _end = .;
    PROVIDE (end = .);
    __heap_start__ = ALIGN(8);
    . = ORIGIN(CPUSRAM) + LENGTH(CPUSRAM) - 0x300;
    __heap_end__ = .;
    /* Stabs debugging sections. */

    and

    .stack ORIGIN(CPUSRAM) + LENGTH(CPUSRAM) - 0x300 :
    {
    _stack = .;
    *(.stack)
    . = 0x300;
    _estack = .;

The linker map file shows that this change was made:

    0x000034b8 errno
    0x000034c0 . = ALIGN (0x8)
    *fill* 0x000034bc 0x4 00
    0x000034c0 . = ALIGN (0x8)
    0x000034c0 _end = .
    0x000034c0 PROVIDE (end, .)
    0x000034c0 __heap_start__ = ALIGN (0x8)
    0x00007d00 . = 0x7d00
    0x00007d00 __heap_end__ = .

Anyone know what's wrong with malloc?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi

malloc() is library dependent so doesn't always work the same way. If you are working with GCC malloc() tends to use a block size of multiples of 4k, so 4k is the smallest and if one needs 4k + 1 byte it is necessary to allocate 8k heap space to get the extra byte.

This is also configurable in the library though (since open source). See the following thread which also discusses malloc() and its GCC implementation.

http://www.luminarymicro.com/component/option,com_joomlaboard/Itemid,/func,view/catid,6/id,3975/#3975

Regards

Mark

uTasker.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Mark. I was afraid it was something like that. The libraries seem to be written assuming a large amount of memory. In my case I can't afford to throw away 3K of RAM.

Fortunately I don't need the complexity of malloc because the memory is never free'd. So I just wrote a simple "getmem" function that starts with the address obtained initially from a malloc of an integer and then simply moves up from there. That allows me to use all the available heap space instead of just the space that newlib thinks I should get :)

Reminds me of Atmel's interrupt vector handling system that took 16K of the 32K of RAM, that was the first to be replaced :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi

Yes malloc() can often be avoided. In the uTasker project there is a uMalloc() which is used as a non-freeable heap (either alone or beside the library malloc()) as described here:

http://www.utasker.com/forum/index.php?topic=96.msg384#msg384

This helps optimise memory consumption but keeps good configuration flexibility. In small memory projects static memory allocation makes high reliability easier to obtain since it removes potential allocation failure risks.

Regards

Mark

PS. There is an AVR32 running (at the moment) on-line at http://demo.uTasker.com The stack and heap use can be viewed on the "administration" side.

PPS. The library printf()routines tend to need malloc() to work and therefore simplified printf() type routines are also sometimes useful.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

I just put this on my linker miscelaneous section

--stack,0x100

put the size you want to. I have not modified the lds file. I use the stock one that came with the toolchain.

Jonathan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Jonathan

I don't think that the value of stack is controlling the heap apart from maybe limiting its maximum size so that it doesn't grow beyond the area that the stack is expected to be working in (?)

Regards

Mark