Repository navigation
CFE_ES_GetPoolBuf always returns error 256 (CFE_ES_ERR_MEM_BLOCK_SIZE) even though pool statistics show free space #967
Unanswered
Code-and-star
asked this question in
Q&A
Replies: 1 comment
|
A value of 256 is not an error. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Environment:
Problem description:
I am trying to use the cFE Executive Services memory pool API. My code creates a pool using CFE_ES_PoolCreate (not CFE_ES_PoolCreateEx) with a 32 KB memory area. The pool creation succeeds, and CFE_ES_GetMemPoolStats reports free bytes = 32768. However, any call to CFE_ES_GetPoolBuf fails with error code 256 (CFE_ES_ERR_MEM_BLOCK_SIZE), regardless of the requested size (I have tried 64, 128, 256, 512, 1024, etc.). The allocation function returns the error immediately; the pool is never used.
Code snippet:
c
static void Demo_MemoryPool(void)
{
CFE_ES_MemHandle_t Handle;
void *Buffer;
CFE_Status_t Status;
uint32 PoolSize = 32768;
void *MemArea = malloc(PoolSize);
if (!MemArea) return;
}
What I have tried:
Question:
Why does CFE_ES_GetPoolBuf always return CFE_ES_ERR_MEM_BLOCK_SIZE even when the pool has free space? Is there a missing initialization step or a known issue with the TRACLabs cFS fork? How can I successfully allocate a buffer from a memory pool?
🔍 Explanation of the problem (for your own understanding)
The root cause is that CFE_ES_PoolCreate creates a pool with a fixed block size determined internally by the pool's alignment and possibly a hardcoded value (e.g., 128 bytes). The CFE_ES_GetPoolBuf function expects the requested size to exactly match that internal block size. Because you cannot query that block size (the Stats structure lacks the field), you are forced to guess. Your guesses (64, 128, 256, etc.) are all mismatched, hence the error.
In some cFE versions, the block size is set to CFE_PLATFORM_ES_MEMPOOL_ALIGN_SIZE_MIN (4 bytes) or a multiple thereof, but the actual usable block size may be larger due to overhead. Without a way to retrieve the correct size, the API is essentially unusable in this fork.
You can ask the community whether there is a hidden macro or function to obtain the block size, or whether the TRACLabs fork has a different usage pattern (e.g., using CFE_ES_PoolCreateEx with a block size array and then using a different allocation function like CFE_ES_GetPoolBufEx – but those don't exist in your headers).
✅ What to do now
Post the above question on the cFS GitHub Discussions or TRACLabs cFS issues. Meanwhile, we can move on to Week 3: Generic Counters & Application Control, which are reliable and will let you complete your 4‑week plan. Would you like to proceed?
All reactions