eheap supports basic heap allocation and free operations, but with more parameters:
eh_Malloc (u32 sz, u32 an=0, u32 hn=0)
eh_Calloc (u32 num, u32 sz, u32 an=0, u32 hn=0)
eh_Realloc (void* bp, u32 sz, u32 an=0, u32 hn=0)
eh_Free (void* bp, u32 hn=0)where an is block alignment, as a power of 2, hn is the heap number, sz is the block size, and bp points at the block to reallocate or to free.
Four types of block allocation strategies are supported:
- Standard
- Aligned
- Cortex v7M MPU Region
- Block Pool
Standard Allocations
For a block allocation, bins are first checked, then the top chunk, TC [Ref 1]. An optional donor chunk, DC, can be enabled for small chunks. It fits between the start chunk, SC, and TC as shown in the following diagram for an initial heap structure:
where CCB is a chunk control chunk and EC is the end chunk. If DC is present and a small chunk cannot be allocated from its SBA bin, it is taken from DC. This serves two purposes:
- Reduced fragmentation caused by small inuse chunks being caught between larger free chunks, thus preventing them from being merged. DC helps to segregate small chunks from large chunks that are taken from TC.
- Localization of small chunks to increase cache hits for them. This is useful for C++, which may be frequently allocating and deallocating small objects.
For standard allocations, blocks are aligned on 8-byte boundaries, so an = 0, 1, and 2 are treated as equivalent.
Aligned Allocations
The an parameter determines a power of two alignment. For example an = 5 means 32-byte alignment, which is required for Cortex-v8M MPU regions. An aligned allocation proceeds as follows:
- Find a large enough chunk for sz.
- Find the first 2^an boundary inside the chunk’s block.
- Determine if the space from it to the end of the chunk is at least sz bytes.
- If so, the block is allocated and a pointer to it is returned. If not, continue to search.
- If there is remaining space after the block and the next chunk is free, merge it with that chunk. If not and size is >= 24 bytes, split off a new free chunk. Otherwise, leave at the end of this chunk as spare space.
If there is space in the chunk ahead of the block, there are two possibilities:
- Ignore it.
- Use it.
Since memory in embedded systems is limited, eheap does the latter. To do so, the inuse chunk control block, ICCB, is moved up below the data block. This puts the free space between it and the chunk below. If that chunk is free, the free space is merged into it. Otherwise, if the free space plus any spare space at the end of the inuse chunk is >= 24 bytes, the combined free space is made into a new free chunk. If not, the combined free space is appended to the end of the inuse chunk and a pointer, SSP, is put at the end of it that points to the start of it as follows:
If the preceding inuse chunk is freed, the resulting free chunk will include the spare space. Similarly if the aligned inuse chunk is freed, it will include the spare space from the preceding inuse chunk. Managing free space like this helps to mitigate memory loss caused by allocating aligned blocks.
Cortex-v7M MPU Region Blocks
A Cortex-v7M MPU region must be a power of two in size and aligned on its size. Cortex-v7M regions are divided into 8 equal subregions, each of which may be disabled, if not needed. Hence a region block (i.e. the block actually allocated) need be aligned only on a subregion size. So, for example, if 2400 bytes is needed, the closest larger power of two is 4096 bytes for the region size and 512 bytes for the subregion size. The desired block must fit within the smallest of 5, 6, 7, or 8 subregions (4 or less would be require a smaller region). In this case, 5 x 512 = 2560, so 5 is the right number of subregions for the needed region block.
The region block search proceeds the same as for a block of 2560 bytes aligned on 512 bytes. When such a block is found, the next step is to find the preceding 4 KB boundary. Then if the region block is totally with the 4 KB block that starts at the 4 KB boundary, the search is over and the region block is allocated, as follows:
Notice that the initial free space started a little after the subregion 1 boundary, so the region block was started at the subregion 2 boundary and the preceding free space became a new free chunk. Also note that the initial free space extended beyond the end of the subregion 6 boundary, so the leftover also became a new free chunk. Therefore, allocating a region block has potentially not wasted any heap space except the unneeded 2560 – 2400 = 160 bytes at the end of the region block.
Region blocks are primarily used for protected blocks, pblks, and protected messages, pmsgs, in SecureSMX. These are dynamically allocated during run time.
Integrated Block Pools
Since the smallest heap block is 16 bytes, two optional block pools have been added to eheap for 8- and 12-byte blocks. These integrated block pools use the same eh_Malloc() and eh_Free() as normal heap operations. If sz <= 8, an 8-byte block is allocated from the 8-byte pool; if the pool is empty, a 12-byte block is allocated from the 12-byte pool; if it is empty, a 16-byte, or larger, block is allocated from the heap. Similarly, for 12-byte blocks. When a block is freed, it goes back to where it came from.
The advantage of integrated block pools is that if they become empty, a block is taken from the heap. Thus, integrated block pools can be sized to meet average demands with the heap providing blocks for peak demands. When a peak demand is over, the heap blocks are freed and operation continues with block pool blocks. Thus, during peak demand, small block allocations may be slower, but the system keeps running.
The two block pools act like downward extensions of the SBA [Ref 2] and have comparable performance to it. They are useful for small C++ and other objects.
Conclusion
eheap provides a variety of block allocation strategies to meet the needs of secure embedded systems. The full source code for eheap can be found in eheap.c and eheap.h at www.github.com/Micro-Digital/SecureSMX.
References
1. “Portals Isolate Partitions”, Ralph Moore, LinkedIn, February 2026.
2. “eheap, Part 2: Bins”, Ralph Moore, LinkedIn, April 2026.