new and delete for MCF5211 broken?

[wheeler]

I am using a 5211 and want to use new and delete. I have set up __heap_size and __heap_addr. I am calling new from a few places in my application. I am using new to make space for fairly small objects, and what I am finding is that the first objects are allocated close together at the start of the heap, but after a few new's, the memory starts coming from halfway up the heap, then after a few close together, they start coming from the top of the heap and then it runs out of memory. For example:

This is a for loop {

    compRevInterlock[ i ] = new CInterRelayUniOnToggleInterlock( compRelay[ i ], revRelay ); //space allocated at the start of the heap

    compRevDelay[ i ] = new CInterRelayUniOffToToggleDelay( compRelay[ i ], revRelay, // space allocated halfway up the heap

}

When I run through this loop, the first new will allocate near the start of the heap, and the second will allocate from halfway up. When the first is called again, it allocates in sequence from the start of the heap, and the second in sequence from the middle of the heap. Has anybody seen this behaviour before?

From the map file:

#>20000000          ___SRAM (linker command file)
#>00004000          ___SRAM_SIZE (linker command file)
#>00001000          ___SP_SIZE (linker command file)
#>20000890          ___HEAP_START (linker command file)
#>20003000          ___HEAP_END (linker command file)
#>20003000          ___SP_END (linker command file)
#>20004000          ___SP_INIT (linker command file)
#>40000000          ___IPSBAR (linker command file)
#>00000000          ___FLASH (linker command file)
#>00002770          ___heap_size (linker command file)
#>20000890          ___heap_addr (linker command file)
#>20004000          __SP_INIT (linker command file)

# Memory map:
  v_addr   p_addr   size     name
  00000000 00000000 00013F40 .p         FLASH
  00013F40 00013F40 00001BC0 .c         FLASH
  00015B00 00015B00 00000D50 .exceptlist FLASH
  00016850 00016850 00000000 .d         FLASH
  20000000 00016850 000001F0 .r         RAM
  200001F0 200001F0 000006A0 .b         RAM
  20000890 20000890 00000000 .alloc     RAM
  40000000 40000000 00000000            IPSBAR

I am compiling against:

C_TRK_4i_CF_MSL.a

C++_4i_CF_MSL.a

Cpp_4i_CF_Runtime.a

Message Edited by wheeler on 2007-05-18 10:59 PM

J2MEJediMaster added MCU type to subject line


Message Edited by J2MEJediMaster on 2007-05-22 10:54 AM

[CompilerGuru]

I think I saw such things with MSL before, but I'm not that familiar with this part.
AFAIK what you see is because malloc uses some memory pools for specific sized memory allocations.
This is very efficient if you have many allocations of the same size, but there is also the drawback that it only makes sense if the complete memory is much bigger than the chosen pool size. Looks like in your case the pool size is just half of the available memory.
I would try to see how this can be configured, either making the pools smaller or to disable them.
I'm not having CF here, so no details from me how to configure this :smileysad:

Daniel
BTW: and also no guarantee that this is really your problem, more a guess.