vApplicationMallocFailedHook() function redefinition problem

claudiorossi wrote on Monday, November 19, 2018:

Hi

I’am developing a FreeRTOS application on Zynq7000 with SDK 2018.2 and I have problem with vApplicationMallocFailedHook function.

I have defined my own function but the standard function present in portZynq7000.c is always called.
I have defined my own vApplicationAssert function too, but in this case the redefinition works fine.
The two standard functions are defined in the same portZynq7000.c file so I don’t understand the
different behaviour.

In source file I get the following comment:

/* This default malloc failed hook does nothing and is declared as a weak symbol
to allow the application writer to override this default by providing their own
implementation in the application code. */
void vApplicationMallocFailedHook( void )
{
xil_printf( “vApplicationMallocFailedHook() called\n” );
}

Someone have suggestions? Do I need to set some different?

Thanks for help

richarddamon wrote on Monday, November 19, 2018:

If it is defined as a weak symbol as the comment says (but I don’t see the directive that makes it a weak definition, maybe you trimmed that directive off) then if you define you version as non-weak it will over-ride the weak definition. If you copied the weak definition directive into your code, then deending on the order the files are processed will control which definition gets used.

claudiorossi wrote on Monday, November 19, 2018:

Hi Richard

The weak attribute is defined at top of PortZynq7000.c file:

void vApplicationAssert( const char *pcFileName, uint32_t ulLine ) attribute((weak));
void vApplicationTickHook( void ) attribute((weak));
void vApplicationIdleHook( void ) attribute((weak));
void vApplicationMallocFailedHook( void ) attribute((weak));
void vApplicationStackOverflowHook( TaskHandle_t xTask, char *pcTaskName ) attribute((weak));

I only rewrite the function without add any directives.
I tried to redefine the vApplicationIdleHook function too, but the standard function is always called.

In Xilinx SDK the FreeRTOS is compiled as a standalone library. May be this the problem?

claudiorossi wrote on Monday, November 19, 2018:

I have solved the problem.
I need to insert the functions prototype (without weak attribute) in FreeRtosConfig.h file.
Unfortunately this file is automatically generated by Xilinx SDK tool so I need to modify
the tcl script file used by the tool.

richard_damon wrote on Monday, November 19, 2018:

Is your code using C++? It might be that you need the extern “C” part of the decleration, that might get automatically added in the FreeRTOSConfig.h file

richard_damon wrote on Monday, November 19, 2018:

Is your code using C++? It might be that you need the extern “C” part of the decleration, that might get automatically added in the FreeRTOSConfig.h file

claudiorossi wrote on Wednesday, November 28, 2018:

Yes, is a C++ code, but compilation work even if i do not add extern “C” to FreeRTOSConfig.h file.

richarddamon wrote on Wednesday, November 28, 2018:

The symptoms sound like the need to mark the file as extern “C”. It may be that by putting the decleration in FreeRTOSConfig.h it is getting wrapped in the extern “C” automatically. It could be that the tool’s autogenerated header wraps most of FreeRTOSConfig.h in an extern “C” section, which could be it being helpful as you often end up declaring function there for use as call backs for FreeRTOS.

The solution to the regeneration is to not add the decleration to FreeRTOSConfig.h, but to add the extern “C” lines in the file where you define the function, either wrapping a pre-decleration or the definition.

I often have a ‘hooks’ file for the various FreeRTOS hooks that has near the beginning

extern “C” {

then has the various hook functions for FreeRTOS

and then the section ends with
}

Note, the functions in between are still C++ functions, but use the C linkage rules so they internally use the C linkage nameing rules, not the C++ rules that support overloading, so FreeRTOS can call them.

claudiorossi wrote on Friday, November 30, 2018:

Hi Richard

Your solution is correct. Adding extern “C” {…declaration…} to the file where I have my functions solve the issue.

Thank you