2009-12-18 04:36 AM
stm32 hangs on malloc
2011-05-17 04:34 AM
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.2011-05-17 04:34 AM
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?2011-05-17 04:34 AM
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.2011-05-17 04:34 AM
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...?2011-05-17 04:34 AM
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.2011-05-17 04:34 AM
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 ]2011-05-17 04:34 AM
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.2011-05-17 04:34 AM
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 Trevor2011-05-17 04:34 AM
ST7, not sure who your comments are aimed at but to be clear I never said you shouldn't check the return value of malloc. The reason I put worst case in quotes was to highlight that this was not easy too define and yes using malloc makes testing (and especailly debugging) more difficult.
Regards, Trevor.