I’m doing what most people end up doing, which is trying to manage memory with pvPortMalloc and the like.
I’ve trapped out the malloc failed hook, which is informative, but not quite so much as I’d like. Rather than modify the code (at this time), I’d like to see the heap information return the size of the memory request that failed in addition to the current heap statistics. Granted, I can figure it out, but why figure out what the program knows?
One option would be to add it to the heap information structure. Another would be to add it to the error call, or add another function to retrieve the data.
Thanks
I’d agree, some more details about the current failed allocation request like the size could be helpful.
Heap statistics might not be applicable in a generic way since it’s coupled with the heap implementation which could be custom 
One option is to run under a debugger and set a breakpoint in the malloc-failed hook. Then you can review the call stack and see the parameters of the call, and where in the code it came from.
At times you just need to put a breakpoint (or some form of logging) at pvPortMalloc and look at all the calls to see what is happening.
True enough, but I want the program to do the work for me. I’ve just tried the following:
in the main program:
void vApplicationMallocFailedHook( size_t shortfall )
{
HeapStats_t heap_status;
size_t needed;
// record heap size.
vPortGetHeapStats(&heap_status);
needed = shortfall;
__disable_irq();
while (1)
{
#if (defined _LED) && (defined _DIRECT_LED) && (defined RED_LED_Pin)
if (RED_ON_HIGH)
{
HAL_GPIO_WritePin(RED_LED_GPIO_Port, RED_LED_Pin, GPIO_PIN_SET);
}
else
{
HAL_GPIO_WritePin(RED_LED_GPIO_Port, RED_LED_Pin, GPIO_PIN_RESET);
}
#endif
#if (defined _LED) && (defined _DIRECT_LED) && (defined AMBER_LED_Pin)
if (AMBER_ON_HIGH)
{
HAL_GPIO_WritePin(AMBER_LED_GPIO_Port, AMBER_LED_Pin, GPIO_PIN_SET);
}
else
{
HAL_GPIO_WritePin(AMBER_LED_GPIO_Port, AMBER_LED_Pin, GPIO_PIN_RESET);
}
#endif
}
}
/* USER CODE END 4 */
and then modify (in heap4.c):
#if( configUSE_MALLOC_FAILED_HOOK == 1 )
{
if( pvReturn == NULL )
{
extern void vApplicationMallocFailedHook( size_t );
vApplicationMallocFailedHook(xFreeBytesRemaining - xWantedSize);
}
else
{
mtCOVERAGE_TEST_MARKER();
}
}
Oh, and there's a problem that you may want to fix (unless I'm putting the code in the wrong place) in app_freedos.c, I added the __weak attribute to the function so I could put my code where convenient:
/* USER CODE BEGIN 5 /
__weak void vApplicationMallocFailedHook(void)
{
/ vApplicationMallocFailedHook() will only be called if
configUSE_MALLOC_FAILED_HOOK is set to 1 in FreeRTOSConfig.h. It is a hook
function that will get called if a call to pvPortMalloc() fails.
pvPortMalloc() is called internally by the kernel whenever a task, queue,
timer or semaphore is created. It is also called by various parts of the
demo application. If heap_1.c or heap_2.c are used, then the size of the
heap available to pvPortMalloc() is defined by configTOTAL_HEAP_SIZE in
FreeRTOSConfig.h, and the xPortGetFreeHeapSize() API function can be used
to query the size of free heap space that remains (although it does not
provide information on how the remaining heap might be fragmented). /
}
/ USER CODE END 5 */
With the existing code, I put a breakpoint on the loop (before the lights go on) and I know exactly how much more memory I need. Convenient. Loop is in main.c, BTW, in a user section
On the other hand, there are NO user areas in your code, so every time I regenerate anything in the ST micro .ioc file, I’ll have to fix the code each time, although perhaps not in app_freertos.c