I wrote a simple tcp_server and tcp_client with fcm to handle input/output to the serial socket.
I am running the server in a debug session, and the client runs and connects to the server ok.
Now I am trying to send a string from hyper terminal with the option: Transfer->Send text file.
The server recieves only one character/byte why?
I assumed that every thing that is sent goes to the DATA buffer in the datahandler and not only one char.
any idea?


Everything that is received will go into the data buffer(s) of one or more calls to the datahandler - you cannot assume that the entire message will be delivered in a single call.


try first to see if data handler is called more than once .


Thanks guys for your help,
I am adding the code (the client and server look the same)

bool FCM_V24_data_Handler(u16 datalength, u8 data)
int cx;
TRACE (( 1, “V24 Data Event Handler : %d”, datalength ));
wip_debug ("[SAMPLE] V24 Data Event Handler : %d\n", datalength );
Copy the recieved data to the Send buffer */
CopyDataToSendBuffer(datalength, data);
cx = 0; //snd_offset
g_ev.kind = WIP_CEV_WRITE;
evh(&g_ev, (void *)(&cx));

return TRUE;


The client sends one word (david)
The server recieves only the the character ‘d’, the server will not recieve anymore later.

need some light on the matter


Why are you assuming that the problem lies in the FCM data handler?

Have you checked that calling your WIP event handler like this actually works?

cx = 0; //snd_offset
g_ev.kind = WIP_CEV_WRITE; 
evh( &g_ev, (void *)(&cx) );



This is my first time to work with open-at so everything is trial and error.
From what I understood, when ever the snd_buffer contains some data, the system will trigger the event to send it to the other side. But that did not happen, so I had to use a gloval event g_ev and to pass to it the data of the actual event, so after I am copying the UART buffer (DATA) to the snd_buffer I am triggering the write event myself, and it works (maybe). my problem is that only the first char of the word i am trying to send is actually succceds to pass.


Is it also your first time with embedded programming?
It helps to know your background…

Before “trial and error”, you should make a careful study of the ADL and WIP manuals.

Also look at the supplied samples.

U think you are unnecessarily complicating the issue by trying to use both FCM and WIP together before you’re familiar with using them separately.

I suggest that you go back to the basic WIP socket sample, and see how that works.

You might also want to go back to a basic FCM sample, and see how that works.

Once you’ve got these working independently, then you can think about bringing them together

See this similar thread: https://forum.sierrawireless.com/t/fcm-datahnadler-again/4381/1


What is the “snd_buffer” :question:

What do you mean by “the system” - WIP? FCM?

Which particular event?
The FCM and WIP events are described in their respective documentation…


Hi Awneil,
Yes it is my first time with embedded applications.
I read carfully the manuals about the fcm service, but i could only assume that the whole message that was sent to the uart port was comletely recieved.
I think that I understand now the FCM issue. The fcm service triggers an event (the data handler) for each byte recieved in the data buffer, so i need to check when the last byte arrived before copying the complete message to the send buffer.
Thanks for the leads and threads


No, that is not a valid assumption at all.
FCM does not know what constitutes a “message” according to your rules - so it cannot tell where you think the message should end.
It therefore gathers bytes according to its own rules - which are the only ones it can know - and it tells you how many bytes it has collected.
It is up to you to interpret those “chunks” according to your own message rules.

No - not necessarily.
The FCM data handler tells you precisely how many characters it is passing to you - you have to design your handler to accept one or more bytes at a time.



Hi Awneil,
I hope the manual could be clear as your explanations.