HeapBuf_alloc() fails after very few allocation

Eyal Lasko

Expert 2300 points

Other Parts Discussed in Thread: MSP430F5259, MSP430F5529

Hi,

I'm using HeapBuf_alloc(nHeapBuf, 1, 0, NULL) to allocate a single block (block size = 6 bytes).

It works well 2-3 times and then it return 0x0000 or 0xFFFFF or other unreal value.

ROV show that the buff still have unallocated free blocks for allocation

I tried static and dynamic creation - same results...

I run the allocation loop in the main() context prior to BIOS_start() though I've tried it in task context and it also fails...

I'm running MSP430F5259 platform.

Can anyone shed some light on this, since I've pretty much tried everything...

Thanks.

Also,

over 8 years ago

0 Eyal Lasko over 8 years ago

Expert 2300 points

I've run the following code on MSP430F5529 Launchpad :

    #define BLOCK_SIZE	2
    #define BLOCK_NUM	50

    static char TestBuff[BLOCK_SIZE*BLOCK_NUM];
    static HeapBuf_Handle hHeap;

    HeapBuf_Params heap_params;
    Ptr h;

    HeapBuf_Params_init(&heap_params);
    heap_params.blockSize = BLOCK_SIZE;
    heap_params.numBlocks = BLOCK_NUM;
    heap_params.buf = TestBuff;
    heap_params.bufSize = sizeof(TestBuff);
    hHeap = HeapBuf_create(&heap_params, NULL);

   int i;
   for(i=1; i<=BLOCK_NUM; i++){
   	h=HeapBuf_alloc(hHeap, 1, 0, NULL);
	System_printf("Block #%d=0x%x\n",i,h);
	System_flush();
	if(h==NULL)	{
		System_abort("aborting...");
	}
}

It runs well with BLOCK_SIZE = 8 , 10, 12 etc

It fails after looping 3 times with for BLOCK_SIZE < 8.

Isn't MSP430 MAU =2 ?

What am I missing here ?????

Thanks is advance

0 Eyal Lasko over 8 years ago in reply to Eyal Lasko

Expert 2300 points

anyone from TI ???

0 ToddMullanix over 8 years ago in reply to Eyal Lasko

TI__Guru* 96960 points

Hello,

There are a few issues here.

1. HeapBuf is really just an atomic linked list. More specifically it is a doubly linked list. So the minimum size of the block must be able to hold two data pointers (prev and next). The size of data pointer depends model you are building, but blocksize of 2 is not big enough for any model. The kernel has several assert checks in the HeapBuf_create, but we aren't checking this one. I'm going to open an enhancement request to add this check.

2. You should not use NULL for the Error_Block in the create and alloc functions. If there is a problem internally (e.g. out of memory) and you have a NULL Error_Block, the program will raise and error and terminate (it does call your Error_raiseHook if configured). If you pass a non-NULL Error_Block and an internal issue arises, the function does return. (with a filled in Error_Block and a return of NULL for the create and alloc functions).

3. We really don't recommend using the Heap functions directly. Instead you should use the Memory APIs instead (e.g. Memory_alloc). The Memory_alloc calls manages the alignment and Error_Block. The lower level heaps do not worry about this. For instance, in Memory_alloc the alignment of 0 gets converted to the maximum data type alignment requirement (e.g. a double needs alignment X). The lower level heaps do not know what to do with alignment 0 since they should never get it. If you want to still use HeapBuf directly, please pass a non-zero alignment.

Todd

0 Eyal Lasko over 8 years ago in reply to ToddMullanix

Expert 2300 points

Hi Todd,

Thanks for the explanation.

Do you mean that the block size definition and buffer size need to take into consideration these 2 linked-list pointers ? Isn't this handled by the kernel ?
If so, what would be the required overhead for each memory model (for MSP430F5259) ?
e.g. If my dynamically allocated structure is, lets say, 6 bytes long. Does block size has to be 6+2*sizeof(Ptr)
Regarding your comment #3 - Do I understand correctly that creation should be
```
hHeap=HeapBuf_create(&heap_params,&eb); 
```
while allocation should call
```
Memory_alloc(hHeap, 1, 0, &eb);
```
Do I get it correct ?

Thanks again for your support

0 ToddMullanix over 8 years ago in reply to Eyal Lasko

TI__Guru* 96960 points

No, you do not have to allocate extra space. When the block is not allocated, HeapBuf has a next and prev ptr at the beginning of the block. When the block is allocated, all the memory is now yours. If you look at a freshly allocated block, you see the prev and next values at the beginning of the block. Of course your application will over-write these with your data. When you free the block, HeapBuf again uses the first two words for the next and prev again.

Regards #2, yes. You'll need to cast the hHeap to a IHeap_Handle though (I expect your code would get a compiler warning). One nice thing about using Memory is that you can use a different heap (e.g. HeapMultiBuf) without changing the Memory_alloc/Memory_free calls then (just the heap creation code).

Todd

0 Eyal Lasko over 8 years ago in reply to ToddMullanix

Expert 2300 points

Hi Todd,

You've been very helpful.
THANKS !

Processors

Processors forum

HeapBuf_alloc() fails after very few allocation