Surprising official advice from Freescale Re: MQX

[geoffW]

Hello

 I would like to double check with Freescale that the following is the correct and official advice.

 I have been struggling all week with a linker error that is triggered by adding one line to my MQX example code

ptr = malloc(100);   // This is the std C library Malloc

 Here is the official reply from Freescale Tech Support when I asked about this link error.

"However, MQX can make use of any part of the memory. If you use the malloc() instead the _mem_alloc() you will have the risk that at some time MQX uses that memory and you can cause your application to crash or have a strange behavior. I strongly recommend to use only the _mem_alloc and do not use the malloc from the stdlib."

In other words, using MQX can put a potential timebomb bug into a fundamental C standard library function !

It is possibly even worse than this as the implication is that any C libary function that uses the Heap could also suffer this problem ?

For info:

 The reason I am needing to use the standard C library malloc is that I am porting thousands of lines of old code over to MQX and it is very hard to find every single C library function that is present that uses the heap and triggers this link error. After several hours of hunting I have still failed to find them all.

A second reason I need to use it is that my code uses realloc() which I think  is not available from the MQX memory pool functions.

Just to frustrate me even more, according to Freescale the linker errors relating to undefined "__mem_limit" and "__stack_safety" are new features in CodeWarrior 7.2.  But I am definitely using V7.1.2 and most definitely get the link error.

 Of course the document C:\Program Files\Freescale\CodeWarrior for ColdFire V7.2\Help\PDF\TN268.pdf that apparently explains what to do to define these variables I havent even got installed, so I cant read it !!  (Anyone know a web link to this document please ? I have been warned off installing V7.2 for other reasons so I cant get it that way.)

I would be very interested to hear Freescales comments on these issues. (Or anyone elses thoughts too)

Regards Geoff

[EAI]

Take a look at cw.c in your BSP, search for malloc.You will see malloc is redeined to use _mem_alloc_system. If you need realloc, define it in cw.c as well. So as long as your link order has the MQX libraryies before the standard libraries, there is no reason to replace all mallocs.

[admin]

Hello all,

are there any exmaple how to create the realloc function starting from the _mem_alloc_system and _mem_free ?

Thansk.

[Class_Five]

For what it's worth, I ran across issues with C++ operator new, which uses malloc. MQX tasks using new/delete crashed. Stepping with the debugger showed malloc using allocation code from MSL, and even though it had its own separate heap space, it would run into trouble.

I solved this by rebuilding the MSL C library C_4i_CF_StdABI_MSL.a (or whichever one you use) with #define _MSL_OS_ALLOC_SUPPORT 1 added to the preprocessor pane. Now malloc grabs MQX hooks for memory allocation. So far, it seems to be working properly.

[solarhawk]

There is still a problem though.  If one uses C++ and allocates memory in a constructor of an object, the alloc calls into the MQX alloc function by the runtime, BEFORE MQX has been initialized. This causes a crash.