Problem with switching to AT mode

My app uses no flow control, so I just switched it to IFC=2,2 and I get the same problem. I did think this would be the difference to everyone else on this problem. Ah well.

Your app might not use it, but there might still be something that happens on the lines unrelated to your app…

You are right awneil.
The handshake lines are set up differently in the different firmware.
Using Hyperterminal:
Pre R7.43 In Data Mode
CTS On (response to Hyperterm “+++”)
Post R7.43 In Data Mode
CTS Off (no response to Hyperterm “+++”)

The CTS Off is stopping Hyperterminal working.
COMLED shows the CTS low quite nicely. Can anyone else confirm this?

If Hyperterm is set to Hardware flow control, then it should not send anything - including the +++ - when CTS is off.

I have set it too No Flow Control in this case.
So it looks like a change in behaviour of R7.43 revealing a bug in Hyperterm (which I’m not surprised at!). :unamused:

Hi,
i want to share my COMLED printscreens with both R7.1b and R7.43.



And i want to tell you that my application using R7.43 can now switch into AT mode successfully without any problem. I don’t know what helped hyperterminal achive this. I continue developing my application and i have made some changes in code expecially uart part. These changes may solve the problem but i dont really know what i did actually.

Finally my FXT002 with R7.43 can successfully switch into AT mode from data mode. Is this a miracle or am i too early to be happy?

I think you must somehow have got it into Hardware flow control mode: as I said, Hyperterminal will not transmit anything - including the +++ escape sequence - when CTS is off.

PS
I’m glad that you found COMLED useful!
antronics.co.uk/downloads/comled.htm

Zafer: I found Hyperterminal can work occasionally, espcially if it was opened when CTS was ON. So be careful still. As I said I think its a change in behavior of the firmware revealing a bug in Hyperterminal, so Hyperterminal is still the weak-link.
Are you using flow control on your port? If so then the CTS should be set, in that case there is a bug in R7.43/4.

Awneil: Yes, COMLED is handy, thanks!

Hi Ben,
Now my hyperterminal works everytime i try. I open hyperterm after data mode and before datamode, it makes no difference. First, i open COMLED to verify that CTS is ON. Then i closed COMLED and open hyperterminal. At last, i send “+++” sequence and it works to switch into AT mode.
My application executes AT+ICF=5,1 AT+IPR=300 AT+IFC=0,0 one by one if it gives any idea. I dont know wheather i will have the same problem in the feature.

Hi Awneil,
COMLED is useful but terminal screen doesn’t display any messages catched by modem. Also i get an error message like in the attachment below. I get this error message after i powered on my modem. Dont have any idea about the reason. I use WIN XP SP3.
And can we change character farming, stop bits an other parameters on COMLED?


Zafer:
“I open hyperterm after data mode and before datamode, it makes no difference. First, i open COMLED to verify that CTS is ON. Then i closed COMLED and open hyperterminal.”
Have your code changes meant that CTS is now ON in Data Mode? Your COMLED picture showed it as off above.
Have you tried it without opening COMLED before using Hyperterminal, although I don’t think COMLED changes any handshake signals?

I’ve switched back to IFC=2,2 and CTS is ON now. So the firmware is doing something sensible, its just changed behavior from something that was not required (CTS with No Flow Control).

Hi Ben,
I think i misunderstood colors of COMLED. I thought Green color means is ON. But i think i was wrong, Green color means OFF. So in my modem uses FW R7.43, CTS is OFF in data mode. I tried without opennig COMLED first, still i can switch my modem to AT mode. I use “No Flow Control” option in my hyperterminal settings. Sorry for insufficent feedback, it is just because i dont know much about CTS and other signal states.

Sorry - could you explain that?

As the screenshot shows, it should display anything it receives from the modem:

Are you using the modem’s USB connection?

I know that COMLED does not cope well when the COM port it’s using “disappears” - eg, because it’s a USB device that gets removed…

I think some USB-Serial devices get a bit upset if you power-up a modem while connected…

Hi Awneil,
I dont use UST-to-Serial devices. I use 2 port PCI serial port.
i can not see any messages on the screen while modem is 300 baud, 7,even,1. But RX, TX, leds shows me that modem gives responses. It may be because of character farming difference. I also can not write anything on the screen of COMLED. So i use AT and other buttons to send commands.
The error is also received when modem first starts in 19200 baudrate. My application sends some messages by adl_atSendResponse at the beginning. I suspect that COMLED fails just the time when my application sends that message.