107SR strange behaviour

#1

My 107SR module is most of the time in server mode. At every hour, I change it to client, manipulating hardware lines (HWTRIGG- low, RESET low, then later - high) and sending appropriate commands via serial line. Then RESET low
and HWTRIGG high. After releasing RESET, I wait for “introduction” string (…UDP:STARTED) and there sits breakpoint. Program always come there.
When imediatelly started Wiznet utility I noticed server mode, and 5 seconds later (aprox.) it goes to client - (program still doesn’t run).
Changed module- the same behavior. Any help ?

Regards

#2

Did you use ‘SV’ command at the last stage?
All command in serial command mode are temporary except ‘SV’ (Save setting message) command.
Even though you changed some setting with different value and you found it worked well, All changed setting will be disappeared after reboot if you didn’t give ‘SV’ command at the last state.

Try to ADD ‘SV’ command at the end of your command lists.
Then you may be able to get what you want.

Thank you.

James.

#3

Thank you javakys for your reply. This is my sequence of events: RES=0, HT=0 + 1ms- RES= 1, wait for “introduction” (…UDP:STARTED), then software sends series of commands:
OP0\r\n, LP3001\r\n, RH192.168.1.103\r\n (remote port- fixed via Wiznet utility), SV\r\n.
Between commands- 20ms and after SV\r\n - 70ms. Then HT=1, RES= 0 +1ms- RES=1, wait for “introduction”.
Server 192.168.1.103 is listening and after above- RES= 1, I expected connection inside 1-2 sec, because
"Reconnection interval" is default- 1000ms. However no connection inside 5 seconds , which program detects and blocks at breakpoint, and few seconds later (program still blocked), server (Hercules utility) reports connection.
Until the moment of connection Wiznet utility shows that module is in server mode, and after connection, of course in client mode (progam blocked all the time).

Thanks

#4

OK, I understood exactly what your problem is.
I’ll try to do with your sequence and check what made this problem happened.

Thank you.

James.

#5

I tried to do the same sequence from the program start, although I was already in client mode. I detected …UDP:STARTED (program blocks), both lines RESET and HWTRIGGER are high, and Hercules utility is listening. But the moment of connection can vary from 5 to 20 seconds (program blocked all the time).

Thanks

#6

And my last notice: 107SR is out of CPU board. Brought 3V3 to 107SR, and button switch to Reset pin (nothing else).
RS232 is connected to computer (Hiperterminal or Hercules) and Hercules utility is TCP listening part.
Module- configured via Wiznet utility - client mode …
Push and release Reset button gives …UDP:STARTED in Hiperterminal and connection is established (Hercules) after
3 to 12 sec.
Two modules with same behavior.

Thanks

#7

Hello,

I did test according to your sequence with WIZ107SR Rev 1.4 and FW ver 4.01.
I saw that it connected to the server at once after reset.
I guess there are something wrong in your test environment.

Which firmware version and hardware revision did you use for test?
And have you ever tested with different socket test program instead of Hercules?
In case of me, Hercules didn’t accept to WIZ107SR’s connection request when I used it as server program.
When I monitor ethernet packet using wireshark.exe, however, I could see WIZ107SR send the connection request packet.

I hope you test again with different program.

Thank you.

James.

#8

Firmware version 3.11. Module is still out of processor and I am using buttons for RESET and HWTrigger. Also using Hercules and Wireshark reports three stage connection (SYN, ACK …) just at the moment Hercules displays it. All three stages, once started, are within handred(s) of milliseconds, but all of them are few seconds (as I mentioned) later from the moment I released RESET button (HWTRIGGER also released).
I noticed that there is no such behavior if I use RT command (at the end of configuration), instead of manipulating RESET and HWTRIGGER lines. In that case connection is quick.
I changed my software to work that way and it is now satisfactory.

Thank you

#9

OK,
Anyway we will check again what made this problem.
I’ll post the result of our test as soon as possible.

Thank you.

James.