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?
Eric,
I can confirm that replacing RTX driven even handling with the previous polling based code solved the above problem of the PC ending up in internal RAM. Later today I will report this issue with differences of the implicated files. I really did not do anything out of the ordinary - and this is not a wrong RTX API issue, as far as I can tell.
Ah, good luck with your USB woes!
I posted a thread with my SWI issues here: http://www.keil.com/forum/docs/thread15695.asp#msg79346
I'd love to hear your thoughts on this.
-Eric
just for everyone's information: I have seen the ARM profiler in action during a seminar and I have to tell you: it is an absolutely stunning piece of hardware/software. buy it, if you have the money...
Hello Eric,
Thanks for the information. The latest release of our software dies when polled via the USB CDC connection. The differences between the last two released are minor: I need to test that tomorrow (i.e I will update this thread, of course) but I suspect that the cause is a replacement of a polling based code with RTX event driven code, that causes my program counter to end up executing "instructions" from the RTX buffer 'mp_stk' in internal RAM (that happens at arbitrary moments)! I did not upgrade to 4.0 yet - but I guess the RTX timing problem is solved there. Do you always experience the failure you described or does it occur at arbitrary moments? I think that I will first solidify my suspicions before upgrading - ache, I wish I had a Cortex M3 or better plus a boss that is willing to pay 16000 dollars for an ARM profiler...!
Tamir,
I am very curious to hear the new way that you are killing RTX. I too am having a problem:
I just upgraded everything to 4.0 (RL-ARM & RVMDK), and now my software interrupt functions are not leaving supervisor mode upon returning. (ie I call a swi function, when it returns I expect it to be in user mode, but it is actually still in supervisor). This did not happen in 3.80. I am still looking into it, and if I can't figure out something stupid that I have done I will be creating a formal post.
P.S. Sorry to take this thread off topic...
As mentioned, most times when dynamic memory is considered, there are alternatives that doesn't make use of a heap.
Do you have more than one thread that performs allocations? May there be a problem with a resource lock either blocking malloc, or failing to block malloc or free, resulting in corrupted data structures?
Hello Stefan,
It is hard to tell what is wrong (as usual; I just found a new way kill RTX...!). But why do you use the heap in the first place? Why not use a static buffer mapped to the same region instead?
View all questions in Keil forum