Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training




Loading

heap_4 strange xFreeBytesRemaining

Posted by louispesteil on December 16, 2014

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 ?


heap_4 strange xFreeBytesRemaining

Posted by rtel on December 16, 2014

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.


heap_4 strange xFreeBytesRemaining

Posted by louispesteil on December 16, 2014

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.


heap_4 strange xFreeBytesRemaining

Posted by rtel on December 16, 2014

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.


heap_4 strange xFreeBytesRemaining

Posted by louispesteil on December 16, 2014

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?


heap_4 strange xFreeBytesRemaining

Posted by rtel on December 16, 2014

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.


heap_4 strange xFreeBytesRemaining

Posted by louispesteil on December 16, 2014

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.


heap_4 strange xFreeBytesRemaining

Posted by heinbali01 on December 16, 2014

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 INTEGRITYSTAMPTAKEN 33333
define INTEGRITYSTAMPFREE 11111

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

if( HEAPINTEGRITYTEST != 0 )
uint32_t ulStamp;
endif
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.

Attachments

heap_4_checking.c (17427 bytes)

heap_4 strange xFreeBytesRemaining

Posted by bowerymarc on December 16, 2014

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

Attachments

alternate (4124 bytes)

heap_4 strange xFreeBytesRemaining

Posted by rtel on December 16, 2014

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.


heap_4 strange xFreeBytesRemaining

Posted by louispesteil on December 17, 2014

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?


heap_4 strange xFreeBytesRemaining

Posted by rtel on December 17, 2014

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

Regards.


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists