stm32 hangs on malloc

[gvandenbosch]

Posted on December 18, 2009 at 13:36

stm32 hangs on malloc

[st3]

Posted on May 17, 2011 at 13:34

Quote:

I have read somewhere that you should first create a memory heap

Not just ''should'' - you must create a heap first!

Remember: you're on a ''bare metal'' embedded system now - you don't have a big OS to do this stuff for you like you do on a PC!

Quote:

but I can't find how to accomplish that.

This must, then, mean that you haven't done it - which will certainly be why malloc crashes your system :o :-W

But, before you you do that, maybe you should think about why you are using malloc at all in an embedded system?

Generally, malloc is best avoided in embedded systems - and it's not usually difficult to avoid.

What exactly is it that you are trying to achieve, and why do you think that dynamic memory allocation is required?

[gvandenbosch]

Posted on May 17, 2011 at 13:34

Hello,

I am using a STM32-103STK from olimex.

I am trying to allocate memory using malloc, but my program hangs/crashes on the malloc command.

I have read somewhere that you should first create a memory heap but I can't find how to accomplish that.

Is the memory heap the problem or isn't malloc supported on the stm 32.

p.s. I am developping using the keil 3 uvision environment.

[st3]

Posted on May 17, 2011 at 13:34

Quote:

I only have malloc() so I can use printf() for debugging.

I thought I'd used printf without needing malloc - maybe that's because I used the microlib...?

[ccowdery9]

Posted on May 17, 2011 at 13:34

There are two things you need.

1. The linker needs to allocate some area. I have this in my linker (in the right place I might add!)

Code:

/* .heap section which is used for memory allocation */

.heap (NOLOAD) :

{

__heap_start__ = .;

*(.heap)

. = MAX(__heap_start__ + _HEAPSIZE , .);

} >DATA

__heap_end__ = __heap_start__ + SIZEOF(.heap);

2. I have a file called syscalls.c which provides the low level interface for the C library (malloc, printf etc etc).

It has the following within:

Code:

register char *stack_ptr asm (''sp'');

caddr_t _sbrk_r(void *reent, size_t incr)

{

extern char end asm (''end''); // Defined by the linker

//extern char end asm (''__heap_start__''); // Defined by the linker

static char *heap_end;

char *prev_heap_end;

if( heap_end == NULL )

heap_end = &end;

prev_heap_end = heap_end;

if(( heap_end + incr ) > stack_ptr )

{

/* Some of the libstdc++-v3 tests rely upon detecting

out of memory errors, so do not abort here. */

//write( 1, ''sbrk: Heap and stack collisionn'', 32 );

//abort();

uart_puts(''HALT - heap exhaustedn'');

exit(1);

//errno = ENOMEM;

return (caddr_t) -1;

}

heap_end += incr;

return (caddr_t) prev_heap_end;

}

Some Googleing in those topics should help.

But ST7 is right, why? I only have malloc() so I can use printf() for debugging.

Chris.

[st3]

Posted on May 17, 2011 at 13:34

Ah yes - the OP stated Keil, and I was also referring to Keil.

However, Raisonance do also provide a version of printf that doesn't use malloc...

[ This message was edited by: st7 on 18-12-2009 15:16 ]

[ccowdery9]

Posted on May 17, 2011 at 13:34

I suppose I should clarify and point out that I am using GCC and newlib. I'm not sure what toolchain you are using.

Chris.

[trevor1]

Posted on May 17, 2011 at 13:34

I can count on one finger the amount of times I've used malloc in an embedded application. Not using all the array is the same as not using all the heap. If you malloc too much you will overflow the heap size in the same way you can overflow the array size. The heap is just a fancy array with various interface functions. You might say that you can check the return value of malloc to avoid heap overflow but you can also check the space available in the array before using it. Malloc has its uses (I've used it often in PC applications) but my advise is don't use in embedded applications unless you have to and if you do you must test the application in ''worst case'' scenario.

Good luck

Trevor

[gvandenbosch]

Posted on May 17, 2011 at 13:34

Ok, I understand now I have to create a heap first and why.

The reason I want to use malloc is that I don't know how many I get, the other way around would be using a large array that can be filled with data but you will never use the whole array or if a mistake is made and the size of the array is too small the array will overflow.

Correct me if I am wrong(still a student) but in my opinion when there is a unknown amount of data to store malloc is used, if there is a specific amount of data then use a array.

I will look into the example, I think I can manage with that.

[st3]

Posted on May 17, 2011 at 13:34

Quote:

You might say that you can check the return value of malloc

It is (almost) certainly a failure to check the return value of malloc that is causing the OP's system to crash!

If you ever use malloc, you absolutely must check the return value from it!! :o

Quote:

if you do you must test the application in ''worst case'' scenario

The trouble is, how do you determine what will cause the ''worst case''...?!

That's another trouble with malloc - it makes things non-deterministic...

[st3]

Posted on May 17, 2011 at 13:34

Quote:

The reason I want to use malloc is that I don't know how many I get, the other way around would be using a large array that can be filled with data but you will never use the whole array or if a mistake is made and the size of the array is too small the array will overflow.

But malloc cannot magically create RAM from nowhere, can it?

malloc can only allocate memory from the heap - so you have to define the heap to be big enough for the maximum number of elements that you'll require, don't you?

So, if you have to define the heap anyhow, you might just as well define a fixed array, mightn't you?!

remember that dynamic allocation adds an overhead and can also lead to problems with fragmentation, memory leaks, etc - which is why it is generally best avoided in embedded systems.

Quote:

in my opinion when there is a unknown amount of data to store malloc is used

Actually, malloc is most useful when the amount of memory available is unknown at build time - as is generally the case with PC-type applications.

When the amount of memory is known at build time - as is typical with embedded systems - you have to fix your heap size within that limit anyhow - so there is little advantage over a fixed array, but still several disadvantages.