printf and heap_4

Kernel
1

mastupristi wrote on Monday, May 22, 2017:

I use Freertos 9.0.0 with heap_4, and I use printf function provided by newlib_nano 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 heap_4 and another from newlib_nano. For the last one I don’t have a direct control.
I wonder what is the right thing to do: make the newlib_nano to call pvPortMalloc and vPortFree (Similar to what is described here), or I have to use heap_3 memory manager

best regards
Max

2

rtel wrote on Monday, May 22, 2017:

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.

3

mastupristi wrote on Monday, May 22, 2017:

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

best regards
Max

4

mastupristi wrote on Monday, May 22, 2017:

I tried to link with this option:

--defsym=_malloc_r=pvPortMalloc

but I have this error:

gcc-arm-none-eabi-5_4-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

5

rtel wrote on Monday, May 22, 2017:

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.
6

richard_damon wrote on Tuesday, May 23, 2017:

If your implementation uses newlib-nano, another option is to look to see if they are using the RTOS compatible versions which call a __malloc_lock() and __malloc_unlock(), 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().

7

hs2sf wrote on Tuesday, May 23, 2017:

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

8

heinbali01 wrote on Tuesday, May 23, 2017:

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 %s\n", 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 heap_4 or heap_5 ). 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.

9

hi Hein, I ran into the compile error with using the printf-stdarg.c you provied due to the lack of implementation of both external functions. I cound not find the realloc_and_printf.zip file you mentioned above which would likely be helpful to resolve this compile error.

thanks
-Allen

10

There you are:

printf-stdarg_2020_02_14.zip (4.6 KB)

Note that it can not print floating point numbers.
It can be used ( if necessary ) in ISR code, and it has a very low usage of the stack.
It does not use the heap at all.
If you want that string pointers are checked for validity, make sure you define xApplicationMemoryPermissions(). Let it return 1 for readable, 2 for writable, 3 when both are allowed.