iTest 3.3 serial port has problem !?

Question

question

jefflee asked Mar 4, '09 jefflee posted Mar 4, '09

iTest 3.3 serial port has problem !?

Hi,

I have been watching and waiting for some answer and still do not see one.

Can some one give me some hint?

I have been using serial port with older version of iTest which has other issues. iTest 3.3 provide its own serial port and fixes those issues. But, now it introduce this new issue and I did not any solution form fanfare yet.

When 1st connecting to a router (if the router is fresh boot, never have console interaction yet), the open serial device never got the prompt.

And if your use "auto or idle", it will come back. But the same thing happen to the next command too.

This must be some bug in the new iTest serial port. Can some fanfare engineers look into this?

-Jeffrey

iTest

10 |950

Attachments: Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Answer 1 · 2009-03-04T22:53:52Z

jefflee answered Mar 4, '09 jefflee posted Mar 4, '09

more detail info:

For a test case with

[1] open device:serialport

[2] command

[3] cloase

Normal response (if I manually do it first)

---------------------------------------------------------

(open)
UC520> (blank command)

Disconnected... (close)

Press ENTER key to start a new session in this window...

---------------------------------------------------------

Then I ran the test case again,

---------------------------------------------------------

UC520> (open)

UC520> (blank command)

Disconnected... (close)

Press ENTER key to start a new session in this window...

---------------------------------------------------------

hmm.... it seems like whatever in the buffer will be used as next (open). But the very 1st opne, has no prompt.

But, even it I made the complete to "auto or idle", the next blank command will have same problem.

Hope this info help.

-Jeffrey

7

10 |950

Attachments: Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

KumarS commented · Mar 04, 2009 at 11:31 PM

I do not think it has anything to do with iTest. Most serial port devices may require "newline" to get a prompt - either login prompt or whatever prompt the device was left in from the last login (if you did not logout).

It seems like in your case, once the a connection to the device has been opened once, next time it gives the prompt on "open". Again that is a device specific behaviour and iTest is not buffering that data and using it on the next run. Your device is sending "UC520>" on the subsequent opens.

0 ·

jefflee KumarS commented · Mar 05, 2009 at 12:12 AM

[1] The same serial connection was working before iTest 3.3.

[2] I am not saying that the there is a problem with buffering. I just tried to show the different case of working and not working cases.

For the not working case:

I simply stuck at

----------------------------------------------------------

(open)

----------------------------------------------------------

0 ·

KumarS jefflee commented · Mar 05, 2009 at 12:54 AM

If open step does not move forward, it is because prompt was not found in the data sent by the device. From your post, it is not obvious what the device is sending for open step. Can you send the text as you see in the terminal window?

If device does send data sometimes and not at other times (for open step or any other step), the completion rule for step should be: "auto or idle" or "idle" or "timed". You can pick these based on what you think would be the best for your device.

0 ·

jefflee KumarS commented · Mar 06, 2009 at 05:17 AM

[1] What I show is from the terminal windwo. It shows nothing.

[2] If I change it to "auto or idle" the open step will complete. But, the next step -- a bland comand will have the exact same problem.

0 ·

KumarS jefflee commented · Mar 06, 2009 at 06:54 AM

#1 is OK.

For #2, what is the "terminator" for your step. The command has to send at least a "return" to get the prompt on most serial devices. If you do not send a newline, you will not get a prompt.

If you are sending newline and not getting a prompt, it seems like your device may need multiple newlines to give a prompt or the device may simply be hung or stopped on a previous command. You may try sending "break" to see if you get a prompt.

0 ·

jefflee KumarS commented · Mar 06, 2009 at 07:27 PM

The terminator is "\r\n".

I have tried "\r", "\n" .... with no luck.

0 ·

KumarS jefflee commented · Mar 06, 2009 at 08:39 PM

You can leave terminator to "\r\n".

So now can you change the command step to "auto or idle" as well and add several of these empty commands and see at which step do you get a prompt from the device.

Can you also check if "HyperTerminal" application can connect to the device and it gets the same behaviour?

0 ·

question