So you have no advantage with dynamic allocation?
How do you cope with the 125K data size that you mentioned earlier?
You do have advantage when using dynamic allocation!
I was speaking specifically to chiduprakash - who said the maximum dynamic allocation size in the OS version that he is using is limited to 64K (due to using 16 bits for the size).
So he specifically has no advantage in using dynamic allocation in the OS version that he is using.
But, as noted, later versions remove that particular restriction - so there would be advantage to be gained there.
But you haven’t elaborated on what problems you saw with static allocation over ~60K 
But you haven't elaborated on what problems you saw with static allocation over ~60K :?:Sorry I’ve got no time to make proper tests for this case. I’ve just moved to dynamic allocation when found that I cannot get large static buffers.
Oh well, fair enough!
But is was Open-AT with GCC - yes?
Did you see any documentation to suggest that it’s a known limitation?
I am using two buffers each 64K. When data size reaches max size of buffer i am transferring remaining data to next buffer.
I guess so. It was M2M studio with default settings and OASIS 2.30 SDK.
I haven’t seen any mentions about memory allocation limits in wavecom documents.
i’ve just been able to statically allocate a char [128000]…
Q2686G FW7.4a
It’s not clear if blackyblack’s “problems” were in just allocating it, or actually using it…
Yes, I do not remember it too. 
I guess it was usage problems since it was hard to find that static allocation does not actually allows large buffers.
That figures - with static allocations, the tools should be able to report any fundamental problems at build time.
I’ve just checked, and the largest allocation (static or otherwise) that I’ve ever used in Open-AT is 64K.
So I would never have seen any issues related to sizes larger than that.
So maybe I’ve just been lucky… 8)
i’m running a little test now,
allocating 12800 bytes,
writing to them at startup,
after 3-minutes checking if the contents is still the same,
after 10 minutes running the same check again.
and i haven’t run into corruptions yet
in my experience when a statically allocated buffer gets corrupted, its usually from overrun in another allocation.
(or am i misunderstanding the problem right now?)
-edit-
by the way,
other processes are running in the background. so i’m testing in a dynamic environment
Or a bad pointer.
Well I’ve got no bad pointers for sure. 
How did you allocate the buffer? Is it char buffer[128000];?
How did you fill the entire buffer?
I used Q2686H (which differs in memory with Q2686G) and I used memcpy to cope with buffer. Probably it is the clue.
u8 *databuf;
u8 *databuf1;
u32 datalen;
databuf=adl_memGet(64000);
databuf1=adl_memGet(64000);
bool uart2DataHandler ( u16 DataSize, u8 * Data )
{
int i;
for(i=0;i<DataSize;i++)
{
if(datalen<64000)
databuf[datalen++]=Data[i];
else
databuf1[64000-datalen++]=Data[i];
}
return TRUE;
}u32 datalen;
u8 databuf[64000];
u8 databuf1[64000];
bool uart2DataHandler ( u16 DataSize, u8 * Data )
{
int i;
for( i=0; i<DataSize; i++ )
{
if( datalen<64000 )
databuf[datalen++]=Data[i];
else
databuf1[64000-datalen++]=Data[i];
}
return TRUE;
}Which takes us back to the question: Is the limit on the actual size of the array (eg, 64K bytes), or is on the number of elements in the array (eg, 64K elements).
It it’s the latter, you could use:
u16 databuf[64000];and write alternately to the low & high byte of each u16 element…
Or possibly even:
u8 databuf[64000][2];Is this question pertains to me?
Insofar as it could save you messing about with the two separate buffers, yes!
However, it was blackyblack who raised the issue of “something like 60 Kb” as a “limit” for static allocation: viewtopic.php?f=107&t=4635&start=15#p18804