Problem with switching to AT mode

Hi,
I have Fastract Xtend FXT002 with the following configuration:
“DWL”,“V08b0j”,"",“Wavecom”,54744,“022410 18:01”,“e9be6255”,“00010000”
“FW”,“FW_SRC_743_6.Q2687G”,“R7.43.0.201003261552.FXT002”,“Wavecom”,2139952,“032610 15:52”,“4aec2bbf”,“00020000”
“OAT”,"","","",201040,“021511 11:54”,“1f724cb1”,“00260000”
-“Developer Studio”,“1.1.2.201005261706-R4588”
-“Open AT Embedded Software Suite package”,“2.33.0.201004071659”
-“Open AT OS Package”,“6.32.0.03”
-“Open AT Firmware Package”,“7.43.0.201003261552”
-“WIP Open AT Plug-in Package”,“5.30.0.2040”

My application changes the baudrate to 300 and 7,Even,1 stop bit. It also switches to data mode with following line:

adl_fcmSwitchV24State(uart1Handle, ADL_FCM_V24_STATE_DATA);

When my module is in data mode, i can not switch it back to AT mode by +++. I use HyperTerminal to send +++ sequence.

How can i switch my module into command mode from data mode? What could be the possible reasons about this problem?

Thank you.

Your FCM Event handler has to specifically allow it - see the ADL User Guide

Hi Awneil,

I checked my FCM Event Handler. I also log some records when the event handler catches an event. According to the records the following sequence occurs:
1.ADL_FCM_EVENT_FLOW_OPENNED
2.ADL_FCM_EVENT_MEM_RELEASE
3.ADL_FCM_EVENT_FLOW_CLOSED
4.ADL_FCM_EVENT_V24_DATA_MODE_EXT or ADL_FCM_EVENT_V24_DATA_MODE
5.Then i send “+++” but the event handler doesnt catch any event. Also my hyperterminal freezes for a time.

How can i detect the error or what else should i control?

You also need to check the ADL User Guide - what does it say about allowing/preventing the switch to AT mode on +++ :question:

Hi awneil,

The ADL User Guide gives the information below. This is what we know and expect but the module doesn’t behave like that. An other thing, my Fastract Supreme modules with the same code switch to AT mode successfully. But Fastract Xtends (FTX002) can not switch to AT mode externally. What else could i check to find reason of the problem?

I’ve had the same problem.
https://forum.sierrawireless.com/t/control-is-not-going-to-data-handler-in-fcm-uart1/4689/1

Hyperterminal doesn’t work since R7.43
PuTTY does.
I haven’t worked out what the signaling difference between the two is yet. Or why not everyone is report the same problem. Perhaps is something about our specific settings.

You missed the bit about how the return value from your handler affects things…

Presumably, there’s not that many people actually using this feature?

It’s had a few bugs for ages; eg, the +++ shouldn’t be echoed - but it is.

I’m not convinced that the 1s “windows” are properly observed, either…

Or was it that the +++ should not be passed through - but they are?

Something like that, anyhow - I’ll have to check…

Hi ,
I am happy that i am not alone! But there must be a reason when putty works while hyperterminal doesnt. My external application written by .NET doesnt work either. I want to share my code flow:

  1. uart1Handle = adl_fcmSubscribe(ADL_FCM_FLOW_V24_UART1 | ADL_FCM_FLOW_V24_MASTER, uart1_CtrlHandler, uart1_DataHandler );
  2. adl_fcmSwitchV24State(uart1Handle, ADL_FCM_V24_STATE_DATA);
  3. AT+ICF=5,1
  4. AT+IPR=300
  5. AT+IFC=0,0

Do you think it could be beacuse of the order of these steps? If you find a solution and share here, i will be very happy.

Thank you

You’ve got to issue AT Commands while the Flow is AT Command mode - the clue is in the name! :wink:

Hi awneil,
You are right. I should not switch data mode before completing all AT commands. But after switching to data mode, should i switch back to AT command mode to execute any spesific AT commands by adl_atCmdCreate?
For example should i always switch back to AT mode to execute AT+CREG? command or AT+IPR=9600 command?

And hi Ben,
Did you try HyperTerminal with Flow Control is NONE?

Commands like AT+ICF, AT+IPR, AT+IFC are directed specifically to the UART - so the UART needs to be in AT Command mode for them to be effective.

Commands like AT+CREG are not directed to a UART - so they don’t care what state the UART’s in (but, of course, you can only forward the responses when the UART is available)

I’ve tried Hyperterminal in all modes. I had shortcuts that worked with R7.4 they stopped working for R.7.43.

PuTTY works everytime. The signals look the same between Hyper and PuTTY on my RS232 LED block, so there must be something in the data itself.

I’d have thought timing is more likely?

Maybe SiWi have messed-up the timeouts somewhere, but they happen to just work with PuTY, but not Hypoterminal?

Are you typing the +++ manually? What happens if you paste it in…?

I have been doing it manually and tried pasting it too, but no luck. Good thought.

You can monitor the serial traffic between the hyperterminal and the remote device with all details via something like “Eltima Serial Port Monitor” ( eltima.com/products/serial-port-monitor/ )

It’s very handy for these occasions, you can see the exact hex string that you are sending.

But what I have seen when we monitored HyperTerminal, It sends character by character to the port on every keypress. Other clients generally don’t do that.

And if echo is on, the log looks like this on HyperTerminal:

S: sent
R: received

S:+
R:+
S:+
R:+
S:+
R:+

I can check this at work (where I have a serial port and some Q2687) and send you the log.

I have checked and saw that the sent data is exactly same as putty as with HyperTerminal. The only difference I see is about the Serial connection settings:

HyperTerminal: 115200,8,N,1 - Hardware flow control
Putty: 115200,8,N,1 - (RTS/CTS) [there is no (DSR/DTR) option in HyperTerminal]

This is the output for Putty:

3210	16/02/2011 12:04:13	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_BAUD_RATE)	DOWN	STATUS_SUCCESS		
3211	16/02/2011 12:04:13	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_BAUD_RATE)	UP	STATUS_SUCCESS	00 c2 01 00 	
3212	16/02/2011 12:04:13	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_LINE_CONTROL)	DOWN	STATUS_SUCCESS		
3213	16/02/2011 12:04:13	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_LINE_CONTROL)	UP	STATUS_SUCCESS	00 00 08 	
3214	16/02/2011 12:04:13	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_CHARS)	DOWN	STATUS_SUCCESS		
3215	16/02/2011 12:04:13	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_CHARS)	UP	STATUS_SUCCESS	00 00 00 00 11 13 	
3216	16/02/2011 12:04:13	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_HANDFLOW)	DOWN	STATUS_SUCCESS		
3217	16/02/2011 12:04:13	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_HANDFLOW)	UP	STATUS_SUCCESS	09 00 00 00 80 00 00 00 00 08 00 00 00 02 00 00 	
3218	16/02/2011 12:04:13	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_BAUD_RATE)	DOWN	STATUS_SUCCESS		
3219	16/02/2011 12:04:13	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_BAUD_RATE)	UP	STATUS_SUCCESS	00 c2 01 00 	
3220	16/02/2011 12:04:13	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_LINE_CONTROL)	DOWN	STATUS_SUCCESS		
3221	16/02/2011 12:04:13	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_LINE_CONTROL)	UP	STATUS_SUCCESS	00 00 08 	
3222	16/02/2011 12:04:13	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_CHARS)	DOWN	STATUS_SUCCESS		
3223	16/02/2011 12:04:13	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_CHARS)	UP	STATUS_SUCCESS	00 00 00 00 11 13 	
3224	16/02/2011 12:04:13	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_HANDFLOW)	DOWN	STATUS_SUCCESS		
3225	16/02/2011 12:04:13	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_HANDFLOW)	UP	STATUS_SUCCESS	09 00 00 00 80 00 00 00 00 08 00 00 00 02 00 00 	
3226	16/02/2011 12:04:13	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_SET_BAUD_RATE)	DOWN	STATUS_SUCCESS	00 c2 01 00 	
3227	16/02/2011 12:04:13	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_SET_BAUD_RATE)	UP	STATUS_SUCCESS		
3228	16/02/2011 12:04:13	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_SET_DTR)	DOWN	STATUS_SUCCESS		
3229	16/02/2011 12:04:13	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_SET_DTR)	UP	STATUS_SUCCESS		
3230	16/02/2011 12:04:13	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_SET_LINE_CONTROL)	DOWN	STATUS_SUCCESS	00 00 08 	
3231	16/02/2011 12:04:13	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_SET_LINE_CONTROL)	UP	STATUS_SUCCESS		
3232	16/02/2011 12:04:13	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_SET_CHARS)	DOWN	STATUS_SUCCESS	00 00 00 00 11 13 	
3233	16/02/2011 12:04:13	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_SET_CHARS)	UP	STATUS_SUCCESS		
3234	16/02/2011 12:04:13	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_SET_HANDFLOW)	DOWN	STATUS_SUCCESS	09 00 00 00 80 00 00 00 00 08 00 00 00 02 00 00 	
3235	16/02/2011 12:04:13	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_SET_HANDFLOW)	UP	STATUS_SUCCESS		
3236	16/02/2011 12:04:13	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_SET_TIMEOUTS)	DOWN	STATUS_SUCCESS	01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 	
3237	16/02/2011 12:04:13	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_SET_TIMEOUTS)	UP	STATUS_SUCCESS		
3238	16/02/2011 12:04:13	IRP_MJ_READ	DOWN	STATUS_SUCCESS		
3239	16/02/2011 12:04:19	IRP_MJ_WRITE	DOWN	STATUS_SUCCESS		
3240	16/02/2011 12:04:19	IRP_MJ_WRITE	UP	STATUS_SUCCESS	2b 	
3241	16/02/2011 12:04:19	IRP_MJ_READ	UP	STATUS_SUCCESS	2b 	
3242	16/02/2011 12:04:19	IRP_MJ_READ	DOWN	STATUS_SUCCESS		
3243	16/02/2011 12:04:19	IRP_MJ_WRITE	DOWN	STATUS_SUCCESS		
3244	16/02/2011 12:04:19	IRP_MJ_WRITE	UP	STATUS_SUCCESS	2b 	
3245	16/02/2011 12:04:19	IRP_MJ_READ	UP	STATUS_SUCCESS	2b 	
3246	16/02/2011 12:04:19	IRP_MJ_READ	DOWN	STATUS_SUCCESS		
3247	16/02/2011 12:04:20	IRP_MJ_WRITE	DOWN	STATUS_SUCCESS		
3248	16/02/2011 12:04:20	IRP_MJ_WRITE	UP	STATUS_SUCCESS	2b 	
3249	16/02/2011 12:04:20	IRP_MJ_READ	UP	STATUS_SUCCESS	2b 	
3250	16/02/2011 12:04:20	IRP_MJ_READ	DOWN	STATUS_SUCCESS		
3251	16/02/2011 12:04:20	IRP_MJ_WRITE	DOWN	STATUS_SUCCESS		
3252	16/02/2011 12:04:20	IRP_MJ_WRITE	UP	STATUS_SUCCESS	0d 	
3253	16/02/2011 12:04:20	IRP_MJ_READ	UP	STATUS_SUCCESS	0d 	
3254	16/02/2011 12:04:20	IRP_MJ_READ	DOWN	STATUS_SUCCESS

and this is for HyperTerminal:

3260	16/02/2011 12:05:44	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_SET_QUEUE_SIZE)	DOWN	STATUS_SUCCESS	00 20 00 00 00 20 00 00 	
3261	16/02/2011 12:05:44	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_SET_QUEUE_SIZE)	UP	STATUS_SUCCESS		
3262	16/02/2011 12:05:44	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_CONFIG_SIZE)	DOWN	STATUS_SUCCESS		
3263	16/02/2011 12:05:44	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_CONFIG_SIZE)	UP	STATUS_SUCCESS	00 00 00 00 	
3264	16/02/2011 12:05:44	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_BAUD_RATE)	DOWN	STATUS_SUCCESS		
3265	16/02/2011 12:05:44	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_BAUD_RATE)	UP	STATUS_SUCCESS	00 c2 01 00 	
3266	16/02/2011 12:05:44	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_LINE_CONTROL)	DOWN	STATUS_SUCCESS		
3267	16/02/2011 12:05:44	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_LINE_CONTROL)	UP	STATUS_SUCCESS	00 00 08 	
3268	16/02/2011 12:05:44	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_CHARS)	DOWN	STATUS_SUCCESS		
3269	16/02/2011 12:05:44	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_CHARS)	UP	STATUS_SUCCESS	00 00 00 00 11 13 	
3270	16/02/2011 12:05:44	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_HANDFLOW)	DOWN	STATUS_SUCCESS		
3271	16/02/2011 12:05:44	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_HANDFLOW)	UP	STATUS_SUCCESS	09 00 00 00 80 00 00 00 00 10 00 00 00 04 00 00 	
3272	16/02/2011 12:05:44	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_BAUD_RATE)	DOWN	STATUS_SUCCESS		
3273	16/02/2011 12:05:44	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_BAUD_RATE)	UP	STATUS_SUCCESS	00 c2 01 00 	
3274	16/02/2011 12:05:44	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_LINE_CONTROL)	DOWN	STATUS_SUCCESS		
3275	16/02/2011 12:05:44	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_LINE_CONTROL)	UP	STATUS_SUCCESS	00 00 08 	
3276	16/02/2011 12:05:44	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_CHARS)	DOWN	STATUS_SUCCESS		
3277	16/02/2011 12:05:44	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_CHARS)	UP	STATUS_SUCCESS	00 00 00 00 11 13 	
3278	16/02/2011 12:05:44	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_HANDFLOW)	DOWN	STATUS_SUCCESS		
3279	16/02/2011 12:05:44	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_HANDFLOW)	UP	STATUS_SUCCESS	09 00 00 00 80 00 00 00 00 10 00 00 00 04 00 00 	
3280	16/02/2011 12:05:44	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_SET_BAUD_RATE)	DOWN	STATUS_SUCCESS	00 c2 01 00 	
3281	16/02/2011 12:05:44	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_SET_BAUD_RATE)	UP	STATUS_SUCCESS		
3282	16/02/2011 12:05:44	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_SET_DTR)	DOWN	STATUS_SUCCESS		
3283	16/02/2011 12:05:44	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_SET_DTR)	UP	STATUS_SUCCESS		
3284	16/02/2011 12:05:44	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_SET_LINE_CONTROL)	DOWN	STATUS_SUCCESS	00 00 08 	
3285	16/02/2011 12:05:44	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_SET_LINE_CONTROL)	UP	STATUS_SUCCESS		
3286	16/02/2011 12:05:44	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_SET_CHARS)	DOWN	STATUS_SUCCESS	00 00 00 00 11 13 	
3287	16/02/2011 12:05:44	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_SET_CHARS)	UP	STATUS_SUCCESS		
3288	16/02/2011 12:05:44	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_SET_HANDFLOW)	DOWN	STATUS_SUCCESS	09 00 00 80 80 00 00 80 50 00 00 00 c8 00 00 00 	
3289	16/02/2011 12:05:44	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_SET_HANDFLOW)	UP	STATUS_SUCCESS		
3290	16/02/2011 12:05:44	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_SET_TIMEOUTS)	DOWN	STATUS_SUCCESS	0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 88 13 00 00 	
3291	16/02/2011 12:05:44	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_SET_TIMEOUTS)	UP	STATUS_SUCCESS		
3292	16/02/2011 12:05:44	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_SET_WAIT_MASK)	DOWN	STATUS_SUCCESS	a0 00 00 00 	
3293	16/02/2011 12:05:44	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_SET_WAIT_MASK)	UP	STATUS_SUCCESS		
3294	16/02/2011 12:05:44	IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_WAIT_ON_MASK)	DOWN	STATUS_SUCCESS		
3295	16/02/2011 12:05:44	IRP_MJ_READ	DOWN	STATUS_SUCCESS		
3296	16/02/2011 12:05:47	IRP_MJ_WRITE	DOWN	STATUS_SUCCESS		
3297	16/02/2011 12:05:47	IRP_MJ_WRITE	UP	STATUS_SUCCESS	2b 	
3298	16/02/2011 12:05:47	IRP_MJ_READ	UP	STATUS_TIMEOUT	2b 	
3299	16/02/2011 12:05:47	IRP_MJ_READ	DOWN	STATUS_SUCCESS		
3300	16/02/2011 12:05:48	IRP_MJ_WRITE	DOWN	STATUS_SUCCESS		
3301	16/02/2011 12:05:48	IRP_MJ_WRITE	UP	STATUS_SUCCESS	2b 	
3302	16/02/2011 12:05:48	IRP_MJ_READ	UP	STATUS_TIMEOUT	2b 	
3303	16/02/2011 12:05:48	IRP_MJ_READ	DOWN	STATUS_SUCCESS		
3304	16/02/2011 12:05:48	IRP_MJ_WRITE	DOWN	STATUS_SUCCESS		
3305	16/02/2011 12:05:48	IRP_MJ_WRITE	UP	STATUS_SUCCESS	2b 	
3306	16/02/2011 12:05:48	IRP_MJ_READ	UP	STATUS_TIMEOUT	2b 	
3307	16/02/2011 12:05:48	IRP_MJ_READ	DOWN	STATUS_SUCCESS		
3308	16/02/2011 12:05:49	IRP_MJ_WRITE	DOWN	STATUS_SUCCESS		
3309	16/02/2011 12:05:49	IRP_MJ_WRITE	UP	STATUS_SUCCESS	0d 	
3310	16/02/2011 12:05:49	IRP_MJ_READ	UP	STATUS_TIMEOUT	0d 	
3311	16/02/2011 12:05:49	IRP_MJ_READ	DOWN	STATUS_SUCCESS

Thank you for your investigation hecatomber. If the data is the same, then as awneil says, it must be in the timing.

Now here’s a thing. If Hyperterminal is opened when the port is in Command mode, you can then switch back and forth between Data Mode and Command Mode OK. If you open Hyperterminal when the port is in Data mode you can’t get back to Command Mode. Curiouser and curiouser.

awneil’s COMLED and PuTTY can work when opened on a Data Mode port and switch it back to Command Mode. Hyperterminal and ClearTerminal can’t.

A limitation of any software “sniffer” is that it cannot show the actual timing on the wire - especially when there’s hardware FIFOs, USB, etc involved…

It shows the timing at the interface with the Windows software driver.

Another possibility could be with the handshake lines…

Maybe there’s some difference in the handshake line states, and that affects Hypoterminal…

COMLED just displays the states of the incoming control lines - it doesn’t use them for flow control, or anything else.