Generate a user code area in heap4

Kernel
1

I need a modified heap4 in one section. This particular section handles malloc failed. I want the heap 4 to return to the calling program the amount of memory not provided, i.e. how much did not get allocated.

One way might be to keep the changed code in a user section, another would be to locate the source of the heap4 code.

Using CubeMX for ST Micro processors, any change to the .ioc file (by editing the processor configuration, as in changing timer settings) will cause the CubeMX program to regenerate the entire code, and in particular (here) regenerating the heap4 code. I’m getting tired of changing that.

Any ideas?

Harvey

2

Are you asking to pass a parameter to vApplicationMallocFailedHook?

What do you want to do with that information?

3

I would just put the modified version of the heap code outside the auto-generated folder, and add it to the project. At worse that says you need to remove the file from the project if you regenerate.

In fact, it sounds like you really want a fully custom heap implementation (likely based on heap4) that does what you want, and if you can tell the Cube that, then it won’t try to rebuild.

It is never good to modify “auto-built” code in place. The tool has special provisions to allow you to customize the code it generates, but that method is platform specific, so can’t really be put into FreeRTOS itself, except maybe in port code, but since the STM parts are standard Arm Cortex parts, they use more generic port code.

4

In the neverending struggle to adjust the FreeRTOS parameters, I want the MallocFailedHook to return a parameter telling me how much didn’t get allocated so I can adjust heap sizes to accommodate that.

to do that, I revise heap4.c as follows:

	#if( configUSE_MALLOC_FAILED_HOOK == 1 )
	{
		if( pvReturn == NULL )
		{
			extern void vApplicationMallocFailedHook( size_t );
			vApplicationMallocFailedHook(xFreeBytesRemaining - xWantedSize);
		}
		else
		{
			mtCOVERAGE_TEST_MARKER();
		}
	}
	#endif

which has a vApplicationMallocFailedHook which looks like:

void vApplicationMallocFailedHook( size_t shortfall )
{
	HeapStats_t					heap_status;
	size_t						needed;
	char						text[30] = {0};
	char						numstr[10];

	// record heap size.
	vPortGetHeapStats(&heap_status);
	needed = shortfall;
	strcpy(text,(char*)"MALLOC FAILED HOOK ");
	itoa(shortfall & 0xFFFF, numstr,10);
	strcat(text,numstr);
	ERROR1(__FILE__, __LINE__, text);
}

The call to get heap stats lets me look at parameters, and the ERROR1 routine flashes an on-board red LED (common to my hardware designs). and looking at the call stack leads me to where the error is called, and how much I need to adjust things.

As you see, this is not a major change to heap4.c.

5

It’s only one section in heap4.c. I may just replace heap4 code, which is easier than replacing a section, but marginally so.

However, I’m of the mindset that the system needs to adapt to me, to make my life easier. So I’d like to have that part of heap4 permanently modified.

I don’t want a custom heap implementation, I already have one. I add QSPI memory to my projects (has to do with graphics, virtual screens and the like). I have a memory allocator based in concept (but not in code) on heap4. It is in an area of QSPI memory assigned just to it.

As you can see by my previous post, nothing is processor specific in what I’m doing with heap4. ’

In terms of design, I’m not sure why this little bit of code isn’t in FreeRTOS. (I’m using 10.3.1).

What I’d like to do is modify the source that heap4 is built from, so the system automatically does the housekeeping as needed.

In fact, I already do that very heavily with the main.c code. The trick there is to generate (using CubeMX) the base code, which sets up all the processor systems. Then replace the base code with your modified code from another project (which puts all your modifications in, but trashes all the customization by CubeMX). Next, go back to the customization routine (editing the .IOC file), which regenerates the non-custom code according to your settings.

However, in main.c; the code is liberally sprinkled with user sections….

6

That is the wrong mindset. The software exists, with MANY users. Unless you are willing to put up the money to pay for the continuing support for your modification, you really don’t get to “demand” that the software change.

And you are wrong about nothing being system specific, the is NO “ISO Standard C” construction that can be put in the code to tell the IDE not to change your section when the Cube regenerates the system. CubeMX has its own PRIVATE method for marking the code for changes. If anything, you should be asking STMicro to implement something like this, as it is the behavior that needs to be changed.

That is why I say you want a “Custom” heap, because you don’t want a standard heap. Part of the reason that the heap functions can’t just be changed is that means that EVERYONE else who is using vApplicationMallocFailedHook needs to change THEIR code to match your request, as you are making a breaking signature change.

And another point is that you failure message may not be accurate, as if the heap has been fragmented, then there may be enough total free space, but not enough free space in one chunk. If you aren’t actually freeing memory so that doesn’t happen, much better would be to be creating all the object statically, so you get the error at link time that you ran out of memory. I personally try to make as much of my allocations “static” as I can. That also allows you with a bit of work put different things into different speed memories based on your needs.

7

I was making a request, nothing more.

This was the first choice, go to the manufacturer of the software. ST micro is the second choice.

In this particular use, none of this happens during program run, it happens when the system is being set up. As a sidenote, the system does not, unless someone snuck it in there, release memory.

There is a static build option, though. Just haven’t fully implemented it.

Thanks for the time, though

8

Changing the signature of vApplicationMallocFailedHook is difficult as it will break existing applications. We can consider adding a trace macro which you can define as per your needs. Something like the following:

    #if ( configUSE_MALLOC_FAILED_HOOK == 1 )
    {
        if( pvReturn == NULL )
        {
            vApplicationMallocFailedHook();
            traceMALLOC_FAILED();
        }
        else
        {
            mtCOVERAGE_TEST_MARKER();
        }
    }
    #endif /* if ( configUSE_MALLOC_FAILED_HOOK == 1 ) */

You can then define traceMALLOC_FAILED in your FreeRTOSConfig.h:

#define traceMALLOC_FAILED() \
{ \
    extern void vCustomMallocFailedHook( size_t );  \
    vCustomMallocFailedHook( xFreeBytesRemaining - xWantedSize );  \
}

And change your malloc failed hook name:

void vCustomMallocFailedHook( size_t shortfall )
{
	HeapStats_t					heap_status;
	size_t						needed;
	char						text[30] = {0};
	char						numstr[10];

	// record heap size.
	vPortGetHeapStats(&heap_status);
	needed = shortfall;
	strcpy(text,(char*)"MALLOC FAILED HOOK ");
	itoa(shortfall & 0xFFFF, numstr,10);
	strcat(text,numstr);
	ERROR1(__FILE__, __LINE__, text);
}

Would this work for you?

9

it would work quite well, thank you.
I’m all for making debugging easier.

instead of vCustomMallocFailedHook, perhaps we might consider vDebuggingMallocFailedHook. but it doesn’t make much difference as long as it’s there.

Thanks

10

That is part of your application and therefore, you are free to name it whatever you want. The only code that goes in heap_4 implementation is a call to traceMALLOC_FAILED which is defined to nothing by default. Would you like to raise a PR for this change?

11

Please do, and thank you for the effort.