Modem Auto Answer-Hanging for 1 min...

Trying to set up a modem, found that PIC 16F877 hangs for a minute or so when the program executes the Hserout ["ATS0=3",13,10] command. Monitoring the serial port I get:

ATS0=

and then the program freezes for a minute. After that, a string <00> follows!

ATX3
AT&K0
ATS0=<00>

Here is a snippet of the program:

hserout ["ATX3",13,10]
pause 500
hserout ["AT&K0",13,10] 'No Dial tone, no Flow Control
Pause 800
Hserout ["ATS0=3",13,10] 'Auto Answer in 3 rings
pause 500

If anyone has any idea what's going on here, please help!

Ioannis

P.S. I tried to send the commands as one like ATs=0x3&K0 and seems to work. I am just concerned about timing....

Have you tried issuing a single command string?

hserout ["ATX3 AT&K0 ATS0=3",13,10]

Just wondering if you are trying to stuff the next command into the modem whilst it's still trying to acknowledge the first one you gave it. So increase the pause also.

Your PIC's input buffer may be overflowing, which may cause the pic to 'freeze'.

Add the following line if you don't already have one in your program:

Code:

---

DEFINE HSER_CLROERR 1

---

Harrison

Thanks for the replies.

Melanie:

Yes I tried to send the commands all together and it seems to work OK. But I do not know why, since there is no check from the program if the module has accepted the previous string...

I was thinking that the problem might be from the PIC itself side.

harrisonsp:
The command suggested is always included in my programs. Also the response from the module is set to be in numeric mode rather than in ASCII, so the flow is reduced to a zero for "OK".

Still mystery covers the case....

Ioannis

No, I don't think it's the PIC. I would place money on it being the modem.

With a lot of modems with 'Hayes Style' command set, when you issue a command, the modem will reply (even if it's OK or just a plain CRLF).

It is possible that during this reply the PIC has issued the next command (intercommand Pause too short)... and in so doing the modem has lost part of the next command string receiving a corrupted sequence which in turn has caused it to timeout.

You could verify this by increasing the Pauses to something really long (eg PAUSE 5000 rather than 500) and see if it still hangs. If it doesn't, then that's the reason... your modem probably has poor firmware that can't simultaneously cope with a new command string whilst the reply to the previous one is still being processed.

Don't quote me, but I think there's a command to suppress these responses from the modem... you could always issue that first. That might also stop the problem.

Hmm, how much would you bed on it?? **smiles**!

The problem is still there. I just moved the sub's from top of program to the bottom of it and this part works OK now! Any explains? I usually put all sub's on top.

It is weird...

Ioannis

P.S. Of course half of the sub's do not work!!!

Is that an invitation?

Short of going through your program line by line I can't comment, but what version of PBP are you using? I do recall early versions of PBP did have some issues, and I do recall some strange things in 2.42... but ceratinly not now.

Just curious if when you send all commands at once are you certain that all commands are received and processed? The PIC might sending the info too fast and the modem is only responding to one of the commands when it replies "OK". This I think would be along the same lines as Melanie thoughts.

Thanks all. Well, Melanie of course it is! I do challenge you!

By no means I asked to go through line by line. Just for reference the code was included.

The version is latest. I had from time to time problems with subroutines and the way was to shorten the length of each one. Now, the symptom is quite strange and the program execution even more. As stated earlier the third Hserout executes to the point ats0= and then it stops for about a minute! This I saw with my eyes on a terminal program. By now there is no explanation as to what might happening.

If the three commands are joined then the execution flows like calm water.

About the modem, cocacolakid, the modem has no problem to process the commands, since the CR/LF has not arrived yet.

Ioannis

Download this free terminal program and try the
modem with the serial port of your PC.
(Just 3 wires, RX,TX,GND)

The program is only an EXE file, no setup.

With this program you can create 12 macros.

Example of macro:

AT#013#010
This will send AT and "CR" + "LF" (cariage return + line feed)

Terminal program home page:
http://bray.velenje.cx/avr/terminal/

File download link:
http://bray.velenje.cx/avr/terminal/dl.php

Luciano

Hi!

The problem is not with the modem. It is with the PIC code executing up to a point then stops for a minute or so and then resumes.

No interrupts or other source is envolved. The problem is on the 3 Hserout. If the 3 becomes 1 OR the LOCATION of the code changes, then it executes normally.

This is the problem!

I do not have to wait for the modem to respond. I just wait and give next command after a while.

I believe it is a problem related with the "code crosses boundary @ ..." that shows up 3 times since the code is long enough.

Ioannis

Hi,

I went quickly through your code.

What you can read here is based on what I understand from
the PicBasic Pro manual and the 16F877 datasheet.
(Not tested with real hardware and software).

==================================

DEFINE HSER_CLROERR 1

If you use "DEFINE HSER_CLROERR 1", PicBasic Pro
will generate the code that in background will take
care of the FIFO RX buffer overrun error. When you
send the AT commands with HSEROUT, the modem will
respond after each single AT command with "OK".
(In your case "0" + CR because of the use of "ATV0").
So while you send the second or third AT command, the
response of the modem to the first or second AT command
will cause an overrun error and therefore the background
code will be executed, which could be the cause of the problem.


What happen with your code:
(From the file you have previously attached).

i=rcreg:i=rcreg

Here you get (clear) the two bytes from the FIFO buffer.



HSerout ["ATV0",13]'Set Numeric Response

The modem sends back 2 bytes. (Ascii 48 and 13).



HSerin 250,no_modem,[i] 'Wait for 0 "zero" (OK)

You read the first byte (Ascii 48) of the two bytes
waiting in the FIFO but one byte will remain in the FIFO.



Hserout ["ats0=2",13,10]
pause 500

The modem sends back the 2 bytes response (Ascii 48 and 13)
and while the UART receives the second byte the overrun error
will occur. (One byte was already there before sending the AT
command so 1+2=3 and with 3 you get the overrun error).
The background code is executed to clear the error. At this
point the FIFO is full.(Two bytes).


hserout ["ATX3",13,10]
pause 500

The modem sends back the first byte of the two bytes response,
(Ascii 48 and 13) and while the UART receives this first byte
the overrun error will occur.
(Two bytes were already there before sending the AT command so
2+1=3 and with 3 you get the overrun error). The background
code is executed to clear the error. After the overrun error
is completed, the execution of your program will resume with the
next statement which is Hserout ["AT&K0",13,10]. The execution
will be interrupted by the overrun error caused by the second byte
of the previous modem response.


Solution 1:

Keep "DEFINE HSER_CLROERR 1" but use a longer pause
between the single AT commands and read the modem
response from the double buffered register RCREG.
This will ensure that the two bytes RX FIFO buffer is
empty before you send the next AT command.


Solution 2:

Remove "DEFINE HSER_CLROERR 1".

In order to be able to receive data in the UART you
will have first to manually clear the overrun error with:

RCSTA.4 = 0
RCSTA.4 = 1

================================

* * *

================================

Also a possible improvement:

Remove this line from your code.

DEFINE HSER_BAUD 9600
(Replaced by the 3 lines below).

Make sure these 3 lines are in your code.

DEFINE HSER_RCSTA 90h
DEFINE HSER_TXSTA 24h
DEFINE HSER_SPBRG 129 ' 9600 Bauds, error 0.16%

================================

* * *

================================

Small format errors:

SUB "continue"
pause 15000: (remove the colon : at the end of the line)

SUB "com_device"
i=rcreg:i=rcreg: (remove the last colon : at the end of the line)

================================

* * *

================================

Also a possible improvement:

In your code I see that you use everywhere only CR
after each AT command. Why do you use CR + LF now?

Is ATZ the right AT command?

ATZ means to reset the modem to the settings stored
by the user. You usually have at least one set of
registers for the user to customize their modem with.

AT&F means to reset the modem to the factory default settings.

A few modems take a moment to finish doing an AT&F and
may ignore the next thing sent to them, though not many.
Many will take quite a while to complete an ATZ, and will
ignore the next things sent to them. You really have to
wait for an OKAY response from the modem, before
doing anything after an ATZ or AT&F.
================================

* * *

Best regards,

Luciano

Luciano, thank you for your extensive reply. The corrections were made, ok.

As for the main problem, it has nothing to do with the external device. It's something related to the sub handling from PBP. Look at the following response taken from the Terminal program suggested earlier:

ATE0
ATV0 <-- at this point I am sending a 0 from the terminal
ats0=2 <-- response is as expected from the program
ATX3 <-- again as expected
AT<00> <-- upto this point, were the command freezes!
<-- then after a minute the <00> appears and execution
continues normally!

AT+CMGF=1
ATS37=9
ATS40=2

So the problem is inside the UART of the PIC as it may look...

Ioannis

If you disconnect the modem, and just monitor serial data the PIC is sending, what results do you get?

Hello,

My theory was wrong.

Bruce in the post #13 there is no modem connected.

The post #13 as I understand it:

The PIC sends "ATE0" to the RX pin of the PC. (The terminal program of the PC shows ATE0).

The PIC sends "ATV0" to the RX pin of the PC. (The terminal program of the PC shows ATV0).
Ioannis types "0" in the terminal program of the PC and the PIC gets this byte
otherwise no further AT commands are sent by the PIC.

The PIC sends "ats0=2" to the RX pin of the PC. (The terminal program of the PC shows ats0=2).

The PIC sends "ATX3" to the RX pin of the PC. (The terminal program of the PC shows ATX3).

The PIC sends "AT&K0" to the RX pin of the PC, but the PC terminal program shows only
AT and after a minute in addition to AT the PC receives also <00>. So after a minute
on the PC screen you will see AT<00> and the execution of the program continues normally
in the PIC. (So the PIC does not successfully send AT&K0 to the PC).

Ioannis please confirm that.

Luciano

Luciano yes. You are right. This is exactly the case. Bruce, sorry, in #13 I did not clearly stated that the device was disconnected.

Please also note that, if all the 3 Hserin commands are joined as one then there is NO problem in the transmitted string! (I do not know if there is other problem in some other subroutine though...)

So, as I can conclude up to this moment, there must be some difficulty from PBP to work with many and some long sub routines.

Also, if the subrounines are transfered from the top to the bottom then this problem disappears! (Others from other sub's are appearing then...)

Black Magic or what?

Ioannis

If I Copy the part of the program with the studied problem to a new fresh program, with no other commands, subroutines or whatsoever, then it runs normally!!

Ioannis

Hi Ioannis,

If you're using the MPASM assembler, can you post the .COD file? If using the PM assembler, then post the .HEX file. I can run it through MPLAB, and see if I can find where it's hanging. I'm curious.

Sure Bruce. I run it through PM. So .hex it is.

Ioannis

Check all your routines, and make sure you don't use a GOTO to reach any sub-routines that end with RETURN.

"EDIT"

After looking at PBP's DONE routine, I doubt that's it either. I don't see anywhere in code where a string being sent is spread across any page boundaries either so my 1st guess wasn't any good.

If shifting the routines around makes it work for the send part, are you sure everything else is working right after the shift?

It could be stack overflow if you have a ton of nested gosubs or calls?

Thanks Bruce for the look.

Well, I double checked for the points you made as it would be possible. I could not find anything suspicious.

Shifting the sub's around corrects one problem but creates another in another subroutine!

I suppose I cannot have all the sub's together!!!

Ioannis

I was wondering if there is a way to check if PBP Compiler changes the memory page where it should. Maybe we are missing a page boundary. Is it possible?

Ioannis