Main Site Documentation

Problem with Ethernet communication


#1

Hi,
I am a little bit lost right now. I’ve got a Panda II and the Connect shield. I want to use the Panda as a TCP server and it should synch its time with a NTP server once a day.

I am using the code from the examples to synch the time and it works great. I also use a modified version of the TCP server example to create the TCP server which accepts incoming clients asynchronously. This also works w/o any problems.

But once a client was connected to the server I cannot synch the time with the NTP server anymore. There is no socket exception. The poll method simply times out.

This is what is working right now:

start TCP Server
synch with NTP

This is what is not working:

start TCP server
accept client connection
close client connection
synch with NTP — > timeout

The TCP server runs fine. It can accept any client connection, as long there is no other client connnected allready (only one client allowed).

The only way to be able to synch with the NTP server again is to restart the Panda II…

Does anyone have an idea if I miss something important here? Or it is generally impossible to use TCP server and UDP client sockets at the same time?


#2

Sockets are notorious for not working as you think - there’s lots of risk of dropping sockets and losing them, leading to unexpected periods of nothing working :slight_smile:

The good think is Nicholas has spent a lot of time working on this kind of thing on the low-memory devices, so hit code.tinyclr.com and search for his code there - it’ll be a huge help for your specific purpose!


#3

I am using the NTP code from Nicolas. I get an answer from the NTP server and I can update the clock on my Panda II.

But as I said, only until some client connects to the server that is also running on the board. From that moment on the poll method is timing out after 30secs when I want to synch my time again. Even when there are no clients connected anymore :frowning:
Aborting the server thread also doesn’t help.


#4

“it’s your code”.

Sorry, I think it’s your code. I don’t think there’s anything fundamentally wrong with the hardware, so the problem comes down to code - if you used all of Nicolas’ code do you get a different experience?


#5

Yeah, I really hope that I did something wrong. If I made a mistake I can correct it with some help of you guys :wink:

Tomorrow I gonna strip my code of all unnecessary lines and post it here!


#6

Hi :wink: It looks like you are running out of sockets, maybe because your are not properly closing the one for your TCP server.

You have to understand that you have only have 4 sockets with that shield.

  • One is most likely reserved for the DNS and DHCP requests if you used “true” in your Wiz5100.Enable function for the “reservedsocket” param
  • If you have a TCP server, one socket is reserved for listening, and you are adding one more for each new connection coming in.
  • So you have only one left, let’s say for your NTP requests.

The only reason I see for missing it would be that at least one TCP socket was not closed properly. Maybe an exception was not properly catched, leaving it virtualy “open”

You may set up a counter, increasing it by one everytime you accept a TCP connection and decreasing after closing it. And watch this value…

The thing with working sockets with NETMF and WIZ5100 is that it is very easy to make something work; however it sometimes takes a lot of time to make it bulletproof and stable.

Just keep trying again. I have some code (netconfig for an example, you’ll find in on code.tinyclr.com) that has been running fine for months without a board restart, leaking sockets or memory. However for greater code stability and avoiding the WIZ5100 internal bugs, and also the GHI DHCP bug (not renewing) I usualy set up an automatic reset of the shield every x days or hours or at specific times (I have a prototype at a customer premises resyncing the WIZ5100 every day at 1am…).

Have fun :smiley: !