Hi, I currently encounter problems with malloc. I use microlib and configured the heap to be 32MBytes (0x02000000 bytes). Under some special circumstances (depending on the image date we get from a CMOS) malloc fails somwhere in my image analysis when trying to allocate memory of e.g. 0x1000 bytes. I tracked the total amount of allocated memory and found out, that only 0x19000 bytes has been allocated until the call of malloc. After each call to the image analysis functions, all allocated memory is freed, thus it should not be caused by fragmentation.
How can it be possible, that malloc fails? May it be possible - because of a programming error -, that overwriting some data malloc uses to determine the free amount of memory, will cause such problems?
Where can I get informations on how microlib implements malloc?
The memory they are pointing to is changed. And there is no other code executed than the code to call the function.
I just made a test, I put all the parameters into a struct and the behavior is quite curious.
typedef struct { Type_t1 *p_para1; int para2; float para3; float para4; int para5; int *para6; int *para7; } function_params_t; /* inside the calling function */ function_params_t params; params.p_para1 = p_para1; params.para2 = para2; params.para3 = para3; params.para4 = para4; params.para5 = para5; params.para6 = para6; params.para7 = para7;
When this code is executed, the address where params is located (¶ms) changes! What is happening?
If the variable "params" is a global variable, it should always have a fixed address.
If the variable "params" is an auto variable, the address will depend on the current stack depth when reaching the function that contains the variable.
But the variable should not move if you continue deeper in your call tree.
How do you deduce that the variable moves? Looking at a named variable in the debugger? Looking at the contents of an absolute address in the debugger? Some other method? Note that auto variables are often problematic for a debugger when you continue to call new functions, since the currrent stack frame gets replaced with the new stack frame for the called function. But looking at a memory dump for an absolute address should still show the contents of the "params" struct, unless "params" happens to be located in a position where it may either be overwritten by a DMA transfer, or may be damaged by a stack overflow.
I think the stack gets corrupted. When I make the variable global, this problem disappears - and others come up...
Something else to consider is the implications of having assembler-written ISR that fails to save one or more registers. Depending on what registers that gets trashed in the ISR, large parts of the main application can continue to work.
A x86 processor has quite few registers, so a corrupted register quickly kills a program. The ARM has a lot of registers so in some situations you can have large code blocks that rely on the contents of a specific register.
I do not have assembler written ISRs, all ISRs are written in C.
-> To exclude this as the reason, I may just disable all interrupts and try to run the program - right?
btw: Where does RTX place the stack of each task?
_I think_ there is a global container called 'mp_stk', unless the task provides its own memory. Look in your .map file.
In an RTOS environment, it is often hard to turn off interrupts, since the main goal of the application is to multitask.
I just found it in the sources of RTX. There is memory defined with _declare_box8 and as you said, it's called mp_stk.
MicroLib + RTX + A function with 7 parameters.
It seams like the problem is solved. I printf-ed the values inside the function and saw, that the values were right. So the debugger fooled me and showed me the wrong values.