malloc and free functions halt execution

Both the heap and the stack should be in RAM. How much RAM do you have?

Thanks for your response.

Sorry, I meant 6000 and 2000 bytes. Yes, they should be in RAM.

From my map-file:

          origin           length         used          unused    attr.

RAM 00001c00 00004000 0000281a 000017e6 RWIX

The stack is located directly beneith FLASH1 in memory:

.stack 0 00005430 000007d0 UNINITIALIZED

00005430 00000004 rts430xl.lib : boot.obj (.stack)

00005434 000007cc --HOLE--

Heap:

.sysmem 0 00001c00 00001770 UNINITIALIZED

00001c00 00000008 rts430xl.lib : memory.obj (.sysmem)

00001c08 00001768 --HOLE--

This seems to be ok I guess. The memory sizes are 6000 and 2000 (0x1770 and 0x07d0) and the positions are right?

What about this other runtime library I asked about, the one with extension _eh, when is that supposed to be used? I made the memory allocation static for now but this is definitely not a solution.

Thanks

/Adde

Adde said:

I made the memory allocation static for now but this is definitely not a solution.

Just after writing this I single-stepped further in my application and got to the next point malloc are used (small allocation this time),  and execution halted again. Something unexpexted is happening, I have tried increasing the heap size without any results. I have also (until now) assumed malloc returns a NULL-pointer if the allocation fails, not just halt execution.

I did not answer how much RAM I had earlier. This is 16 kB for my device (the F5438).

/Adde

I had a similar problem.

As source code for malloc() is not available, I single stepped into its assembly, and after about 15 steps, I found myself in the middle of one of my functions, out of the blue...

It turned out that malloc() is using some pointer to one of its functions, and calling it indirectly (jumping to the address written in this pointer variable).

Adding a "watch-point" (data break-point) for write access on this variable's address, I found that my code is overwriting it (out of bounds array index), causing malloc() to jump to (call) a function at a wrong address.

Generally, stack starts at upper limit of RAM and grows downward. Static and global variables are usually placed at lower limit of RAM and go upwards. The space in the middle is the heap.

Note that the limits you specify in the linker file are just guidelines. There is nothing that prevents the stack from growing past the bounds you set in linker file and overwriting memory you expect to use as your dynamic allocation heap.

I would recommend using the debugger to halt your program at the reset vector, then fill RAM with a known pattern (like 0xDEAD) and then run your program until you get your failure condition. Then check your stack range to see if the stack overflowed. Also check that there is still enough 0xDEAD space left to satisfy your malloc() request etc....

That you should help you narrow down the source issue.

I use dynamic memory allocation on the 5438A as well, and have no problems. I have a custom memory manager and malloc() implementation however.

Hey, Brian, the stuff about the growing stack is my text. :)