I currently need to check the current value of free bytes remaining in the heap.

I defined the heap size in FreeRTOSConfig.h like this "#define configTOTALHEAPSIZE ( ( size_t ) ( 6 * 1024 * 1024 ) )"

the .map file generated indicate that this configuration is correct and 6 MB are "locked" for heap_4. But when the program is running, when I read the variable xFreeBytesRemaining, I have strange value (greater than 6 MB, sometimes a lot more, almost 7MB). Is anybody know how this is possible ?

At which point do you see the erroneous value? Before the heap has been used, after the first allocation, after the application has been running for a while, etc.

I just tried this and, initially at least, got the expected value.

Regards.

Thanks for this quick answer.

At the start, the value is as expected. In fact, I take the value to store min and max. After the application has been running for a while, max has a value around 7MB, and the current value is around 6MB (sometimes a little less, sometimes a little more). Regards.

Could you put a break point on the point that the max goes over the expected maximum to see if the system state at that point can offer any clues?

Note heap_4.c also has a xPortGetMinimumEverFreeHeapSize() function.

Regards.

I use the 7.5.3 version of FreeRTOS (no xPortGetMinimumEverFreeHeapSize() in heap_4).

I have a visual studio project which give me memory consumption on windows of the application I put in the micro (Renesas RZA1, ARM Cortex A9 core). I assumed that the "real" memory consumption in the micro is the differance between xFreeBytesRemaining minimum and maximum. To be sure, I compared the data from visual studio and from heap_4. The results make me think I'm right (because the values are friendly). If I am, it seams to mean that my problem is an offset problem. Do you know if it's possible and from where it could come?

I don't really understand what you are saying here - but if you mean it could be an offset problem, then an offset from what? The memory comes from a static array, the start of which is always in the same place.

I have strange value of xFreeBytesRemaining.

My application should use 2302112 bytes (peak value) (result I got from Visual Studio profiling of my application). The maximum value of xFreeBytesRemaining is 7003384 bytes and the minimum is 4745648 (value from hardware debug). 7003384-4745648 = 2257736. The memory consumption peak seems to be ok. But I defined the heap size to 6MB : "#define configTOTALHEAPSIZE ( ( size_t ) ( 6 * 1024 * 1024 ) )" So, the value of xFreeBytesRemaining should never be above 6291456. That's why I think of an offset problem. Like if the value of xFreeBytesRemaining the value goes awry at some point.

Hi Louis,

A few months ago I have tested heap_4.c thoroughly for several hours in a simulator. I was amazed by its simpleness and its speed. The test was randomly allocating memory and returning other memories. As long as my testing program was well-behaving, it didn't encounter any problem.

There are two obvious rules for "good behaviour":

• Never write outside the allocated space
• Only call vPortFree() once for each memory pointer

The heap_x.c modules do have a bit of error checking but it's very minimal to save CPU time.

I hope you have configASSERT defined:

~~~~ void vPortFree( void pv ) { ... / Check the block is actually allocated. */ configASSERT( ( pxLink->xBlockSize & xBlockAllocatedBit ) != 0 ); configASSERT( pxLink->pxNextFreeBlock == NULL ); } ~~~~~

I once added an extra field to check the validity of the memory blocks:

~~~~

/* Define the linked list structure. * This is used to link free blocks in order * of their memory address. */ typedef struct ABLOCKLINK {

uint32_t ulStamp;

struct A_BLOCK_LINK *pxNextFreeBlock; /* The next free block in the list. */
size_t xBlockSize;           /* The size of the free block. */

} BlockLink_t; ~~~~~

Find attached a version of heap_4.c which has such extension. You might want to have a try with it.

Regards.

Another rule for good behavior: NEVER use malloc/free from an interrupt! (so that means timer tick too, right?)

Replying to two posts:

I hope you have configASSERT defined:

His version pre-dates that, and several other recent debug assisting asserts, which may help identify the problem.

so that means timer tick too, right?

Definitely right. The allocation schemes could be altered to make them interrupt safe, but as delivered they are not (because to do so would mean interrupts would have to remain off for a non-deterministic time, and that is something FreeRTOS just does not allow).

You could of course have two memory allocation regions, one for tasks and one for interrupts.

Only call vPortFree() once for each memory pointer

Do you think that if vPortFree() is called more than once time for a mem pointer, it could result that xFreeBytesRemaining exceeds the initial (and logicaly maximum) value?

In up to date versions it would cause an assert() failure. I don't know about in old versions.

Regards.