How many wires do you use in the UART of your sensor? 3 or 5?
Hi
the sensor need 2 wires for the UART connection and 2 for power supply.
Have you managed to make this example work in a q2686H? I followed your advice and i tried this example but it didn’t work.
As a matter of fact i have put traces in my application and the problem is that i cannot send data to the UART.
I put the adl_fcmsenddata command after the flow gets to the DATA state. But nothing happen.
Should i put it somewhere else?
Thanks
An RS232 link cannot use just 2 wires; there must be at least RX, TX, and Ground - a minimum of three
Of course, the Ground could be shared with the power supply - do you have a common ground reference between the sensor and the Wavecom unit?
Note that, by default, Wavecom requires some of the hanshaking signals to be active; eg, see: viewtopic.php?f=53&t=3081&p=11377&hilit=loopback+rts+cts#p11377
You either need to provide those signals (eg, by loop-backs), or disable hardware flow control.
Elesaq check the post of awneil, is faster than me typing. 
If you use a 3-wired interface (Rx, Tx, Gnd) you must deactivate the other signals Request To Send and Clear To Send. Sometimes it works with out doing it but sometimes it doesn’t. I take a quick look over your SW but I haven’t seen it, did you do this reconfiguration?
Hi guys!
fer.caballero, do you mean the command: AT+IFC=0,0 ? Although I have included that in my code, I think this is not the problem and let me explain why!
I wrote code to communicate via UART2 with a GPS module without using RTC and CTS. With the same code I ran my program hundred of times and it communicated just fine! I could read my data and everything was ok! But then, when I packed my development kit back to the suitcase to go to the lab, where I reconnected the cables and ran the SAME program, I got these:
Trace IP 1 Data:
Trace IP 1 Datasize: 21
Trace IP 1 Data:
Trace IP 1 Datasize: 23
and so on…
So I would like to say that probably the problem should be placed on hardware, something that has to do with the cables! I really don’t know! Otherwise can somebody explain my strange problem???
Best regards!
The traces looks like your are not receiving an ascii string. Datalength bigger than 0 an no data printed. Try to print each byte value as an integer, maybe this will give you some information…
jan saids:
Maybe he’s rigth.
The DUMP macro does this for you…
hi,elesaq
have u solved your problem? i guess i met the same situation ,that is ,the FCM problem is right ,but it didn’t send any data.
zhuzhiwei
What FCM problem?
How can a “problem” be “right”?! 
How have you verified that?
hi,awneil
my problem is described in detail in http://www.wavecom.com/modules/movie/scenes/forums/viewtopic.php?f=5&t=3652.Would you mind to take some time to read it?
Thanks a lot.
#include "adl_global.h"
#include "uart2.h"
bool newUart2Message_b = FALSE;
bool uart2Configured_b = FALSE;
ascii* BufCopy;
ascii* RecSigmaBuffer;
ascii* write_ptr;
static s8 fcmHandle;
bool isUart2Configured() {
return uart2Configured_b;
}
bool isUart2NewMessage() {
return newUart2Message_b;
}
void resetUart2NewMessageFlag() {
newUart2Message_b = FALSE;
}
ascii* getNewUart2Message() {
u16 i;
for(i=0;i<wm_strlen(BufCopy);i++) {
BufCopy[i] &= 0x7F;
}
return BufCopy;
}
void activate_UART2( void ) {
RecSigmaBuffer = adl_memGet ( (u16)512 );
BufCopy = adl_memGet ( (u16)100 );
write_ptr = RecSigmaBuffer;
adl_atCmdCreate( "AT+WMFM=0,1,2", FALSE, Res_WMFM1_Handler, "*", NULL ); //Activate UART2
}
/***************************************************************************/
/* Function : Handlers */
/*-------------------------------------------------------------------------*/
static bool Res_WMFM1_Handler ( adl_atResponse_t *paras ) {
adl_atCmdCreate( "AT+IPR=19200", ADL_AT_PORT_TYPE( ADL_AT_UART2, FALSE ),Res_IPR_Handler, "*", NULL );
return TRUE;
}
static bool Res_IPR_Handler( adl_atResponse_t *paras ) {
adl_atCmdCreate( "AT+IFC=0,0", ADL_AT_PORT_TYPE( ADL_AT_UART2, FALSE ),Res_IPR_Handler2, "*", NULL );
return TRUE;
}
static bool Res_IPR_Handler2( adl_atResponse_t *paras ) {
adl_atCmdCreate( "AT+ICF=3,4", ADL_AT_PORT_TYPE( ADL_AT_UART2, FALSE ),Res_IPR_Handler1, "*", NULL ); // 3,4 -> 8n1; 5,1 -> 7e1
return TRUE;
}
static bool Res_IPR_Handler1( adl_atResponse_t *paras ) {
TRACE (( 1, "(uart2.c) uart2 fcm handler create" ));
fcmHandle = adl_fcmSubscribe( ADL_FCM_FLOW_V24_UART2, (adl_fcmCtrlHdlr_f)fcmCtrlH, (adl_fcmDataHdlr_f)fcmDataH );
return TRUE;
}
/***************************************************************************/
/* Function : UART Control Handler */
/*-------------------------------------------------------------------------*/
static bool fcmCtrlH ( u8 Event )
{
bool bReturn = TRUE;
TRACE (( 2, "V24 event %d", Event ));
// Switch on event
switch ( Event )
{
case ADL_FCM_EVENT_FLOW_OPENNED :
adl_fcmSwitchV24State ( fcmHandle, ADL_FCM_V24_STATE_DATA );
TRACE (( 2, "UART2: activated" ));
uart2Configured_b = TRUE;
break;
case ADL_FCM_EVENT_RESUME :
TRACE (( 2, "Resume Data Flow"));
break;
case ADL_FCM_EVENT_MEM_RELEASE :
TRACE (( 2, "Data are sent"));
break;
}
return bReturn;
}
/***************************************************************************/
/* Function : UART Data Handler */
/*-------------------------------------------------------------------------*/
static bool fcmDataH ( u16 DataLen, u8 * Data )
{
ascii* temp;
TRACE (( 2, "V24DataHandler begin"));
wm_memcpy ( (ascii*) write_ptr, ( ascii * ) Data, DataLen );
write_ptr += DataLen;
*write_ptr = 0;
if((*(write_ptr-1)&0x7F) == 0x0A) {
wm_memcpy(BufCopy,RecSigmaBuffer, write_ptr-RecSigmaBuffer+1);
write_ptr = RecSigmaBuffer;
newUart2Message_b = TRUE;
}
/*
TRACE (( 1, "Dane z UART"));
DUMP ( 2, Data, DataLen);
TRACE (( 1, "Dane w RecSigmaBuf"));
DUMP ( 2, RecSigmaBuffer, 64); */
return TRUE;
}
u8 addparity(u8 data) {
u8 parity = 0x00;
u8 tmp = data;
tmp &= 0x7F;
while (tmp) {
parity = ~parity;
tmp = tmp & (tmp - 1);
}
parity &= 0x80;
return (data & 0x7F) | parity;
}
/***************************************************************************/
/* Function : SendString */
/*-------------------------------------------------------------------------*/
void SendString ( ascii * StringToSend )
{
unsigned short i;
adl_fcmDataBlock_t *BlockToSend;
s32 sReturn;
TRACE (( 2, "SendString "));
/* Build block to send */
BlockToSend = adl_memGet ( ( u16 ) ( sizeof ( adl_fcmDataBlock_t ) + wm_strlen ( StringToSend ) ) );
BlockToSend->DataLength = wm_strlen ( StringToSend );
wm_memcpy ( ( ascii * ) BlockToSend->Data, StringToSend, wm_strlen ( StringToSend ) );
for(i=0;i<BlockToSend->DataLength;i++) {
BlockToSend->Data[i] = addparity(BlockToSend->Data[i]);
}
/* Send Block */
sReturn = adl_fcmSendDataExt ( fcmHandle, BlockToSend );
TRACE (( 2, "Submit data : %d", sReturn ));
if ( sReturn == FALSE )
{
TRACE (( 2, "No more credit ; wait for resume" ));
/* Block sent, but flow not ready to send more data */
return;
}
else
{
// Wait for resume
TRACE (( 2, "String saved but not sent : wait for resume" ));
}
}Hi, here is my piece of code which works for UART2. Compare to yours.
“AT+IFC=0,0” command is for disable hardware handshaking.
PS.
Info: Due to bug in OAT, I set OAT to use 8n1 on UART2 and then by software function add_parity I change it to 7e1.
You don’t need to add manually parity!!!
Use FCM configuration.
I know, but it didn’t work (AT+ICF=5,1) - bug I suppose. Less time for me was to do it manually.
Use a osciloscope to check if any signal is going out. Remember that out going data goes through pin 73, not through 71.
Frames were going out but some of them had parity error - I have checked this by software serial monitoring tool.
Actually you are sending 7 data bits, 1 parity bit and 1 stop bit. Are you sure that is what you need?
If that’s correct review your parity calculation function. The bug may be hide there.
Yes, it’s correct - this is 7e1 scheme, which is used by device connected to my q2687.
Setting OpenAT to use 7e1 by “AT+ICF=5,1” causes that some (not all) of frames sending out have parity error, so I set OpenAT to 8n1 and manually set parity bit which gave me 7e1 connection. My code is ok - it’s running fine for few months already.
PS. Dear Admin, this is offtopic so please cut and paste it to my topic which was created for this problem:
viewtopic.php?f=3&t=2562 (7E1 UART2 mode problem - bad frames)
Unfortunately I can’t see this topic at moment - I suppose it has been moved to wrong sub-forum (“Global announcement”?)
It shows in the search but I can’t get there. Same thing for some other topics.
Summarizing, you have had problems with the “AT+ICF=5,1” configuration and you have checked it with a software serial monitoring tool.
To avoid it you tried to calculate parity bit your own, but it doesn’t work. If I have correctly understood, some time ago this trick has been working. What has changed?
Anyway, how does your “serial monitoring tool” filter incoming data? At first step I recommend connecting serial channels to an oscilloscope, to see waveforms if any. After this, you can connect your SW. Your SW probably would give you the same feedback if there is no wave, if the levels are not correct, if cables are crossed, if there is a capacitive charge in your lines… 
Tell us if you have any advance after this checks.
Good luck.
Yes.
No, with my workaround (software parity function which change 8n1 to 7e1) everything is OK 
The code above is working fine for few months.
Maybe my poor English caused this misunderstanding - sorry
This is old issue which I gave up when my workaround worked. Maybe I come back to this later.