printf and heap_4

I use Freertos 9.0.0 with heap4, and I use printf function provided by newlibnano bunbled in GNU ARM Embedded Toolchain 5-2016-q3-update. My MCU is STM32F410RB. I note that when printf is called for the first time, _malloc_r() function is called (here the call stack): In this scenario I have two heap managment: one from heap4 and another from newlibnano. For the last one I don’t have a direct control. I wonder what is the right thing to do: make the newlibnano to call pvPortMalloc and vPortFree (Similar to what is described here), or I have to use heap3 memory manager best regards Max

printf and heap_4

Personally I would direct newlib memory allocation calls to the FreeRTOS equivalents. You have to be careful with functions like realloc though, for which there is no FreeRTOS equivalent. I normally define such functions in main.c and put an assert() in them to see if they ever get called.

printf and heap_4

unfortunately it doesn’t calls malloc. It calls _mallocr() that is not a weak function. I don’t know what are the differencies between _mallocr() and malloc() (and so pvPortMalloc()). Another point is that other *malloc* functions could be called best regards Max

printf and heap_4

I tried to link with this option: ~~~ –defsym=mallocr=pvPortMalloc ~~~ but I have this error: ~~~ gcc-arm-none-eabi-54-2016q3-20160926/src/newlib/newlib/libc/stdlib/nano-mallocr.c:239: multiple definition of `malloc_r’ ~~~ the same if I define _malloc_r() in my main o if I alias it best regards Max

printf and heap_4

I think C should only attempt to pull undefined symbols from the library – that is – the symbol is not in the application so look for it in the library. However GCC seems to want to complain when it seems the same symbol defined in both the application and the library unless you explicitly tell it not to, which you have to do using a command line option. Search the GCC manual for something like ‘multiply defined’ to find the necessary option.

printf and heap_4

If your implementation uses newlib-nano, another option is to look to see if they are using the RTOS compatible versions which call a __malloclock() and __mallocunlock(), which you can then define to call the FreeRTOS scheduler stop/restart functions like heap3.h does. Then malloc and family are as threadsafe as pvPortMalloc().

printf and heap_4

You could also use the ‘–wrap’ linker flag and provide the corresponding wrapper functions.

printf and heap_4

Hi Massimiliano, Like Richard, I also tend to avoid the clib or newlib heap functions ( and their reentrant equivalents _r ), by using the linker or a configASSERT(). The FreeRTOS+ library has its own task-safe implementation of all printf() functions, which: ● Does not use the HEAP ● Has a low usage of the stack ● May be called from within an ISR as well The module printf-stdarg.c needs two external functions, provided by you: ~~~ /* * ‘aAddress’ is a memory address. * Return 1 for readable, 2 for writeable, 3 for both. * Function must be provided by the application. */ extern BaseType_t xApplicationMemoryPermissions( uint32_t aAddress );
/*
 * vOutputChar() shall output a character to "stdout"
 * It is called in case a sprintf() function is called with
 * the NULL pointer.
 */
extern void vOutputChar( const char cChar, const TickType_t xTicksToWait  );
~~~ Note that this crash will be avoided if you implement xApplicationMemoryPermissions() : ~~~ int iNumber = 12; /* In the printf call %s is used in stead of %d, which may lead to a crash. The printf functions in printf-stdarg.c will print it as “INV_MEM” */ printf( “The answer is %sn”, iNumber ); ~~~ In case you do need a realloc() function, I attached a tested version in which it is called: ~~~ void *pvPortRealloc( void *pvAddres, size_t uxNewSize ); ~~~ It adds a new function uxPortGetSize() which returns the length of any pointer in the heap ( using heap4 or heap5 ). The length is rounded up to a multiple of e.g. 8 bytes, due to its allocation. See attachment realloc_and_printf.zip for both source files. Regards.