rtel wrote on Thursday, July 10, 2014:
This depends on how the heap used by the standard malloc() function works. On many systems it does not use a defined size, but just grows until it hits something. In that case the technique described above to size the heap used by FreeRTOS is not helpful because it will prevent you from using the default C library’s malloc() all together.
If you are using both the default malloc() and FreeRTOS’s pvPortMalloc(), and you want to know how big the RTOS’s malloc can be, first you will need to find out how much space is needed by the default malloc() - then you can allow FreeRTOS to use whatever is left.
Alternatively you could use heap_3.c with FreeRTOS, then both malloc’s will use the same heap - but that might not be wise if you are rapidly allocating and freeing blocks (which is generally not a good idea anyway) because the default malloc() is likely to be slow, and if not slow, non deterministic. Consider allocating once, then just re-using the allocated blocks over and over rather than rapidly allocating and freeing.
The configASSERT() that is being triggered only tells you that something has overwritten the meta data between the block being allocated and the block being freed. It does not allow you to trap when the corruption actually occurred. To do that you may be able to use a watch point in your debugger though. If the corruption is repeatable, so you know which block is going to get corrupted, then break in the debugger when the block is allocated, set a break point on a data write to whichever byte in the metadata is being overwritten (you can see which memory the asserts are checking, xLink->xBlockSize or xLink->pxNextFreeBlock), start the program running again, and the debugger will break at the moment the data is overwritten. Whether that is possible or not depends your development environment.