Shop OBEX P1 Docs P2 Docs Learn Events
Question about Wiz820io (from Post #3) — Parallax Forums

Question about Wiz820io (from Post #3)

twctwc Posts: 107
edited 2012-11-01 06:30 in Accessories
I'm just checking out some of these demos and having some problems. I noticed there are netparms (ip, gateway, mask) etc. defined in DAT section of W5200. And I also see wiz.SetIp and wiz.SetMac at the beginning of TCPSocketClientDemoDhcpDns. I substituted my own netparms in both places. I thought you wouldn't need any of this (except Mac) by virtue of using DHCP. The failure mode is a second or so after "Requesting IP..." appears, the program just prints garbage infinitely. With DHCPDemo.spin it displays a buffer, and then ends up bytes received = -1 fail safe.
«13

Comments

  • Mike GMike G Posts: 2,702
    edited 2012-10-08 20:31
    The values in W5200 are defaults (place holder) and could very well be 0. The DHCP object will overwrite the default values provided the configuration is correct. MAC Address. The IP could be 0.0.0.0.

    If the DhcpDemo returns (-1) it timed out. Please, verify your configuration.

    Do you have the SPI I/O setup correctly? 
       ' SPI pins
  SPI_MOSI          = 1 ' SPI master out serial in to slave
  SPI_SCK           = 0 ' SPI clock from master to all slaves
  SPI_CS            = 3 ' SPI chip select (active low)
  SPI_MISO          = 2 ' SPI master in serial out from slave
  • twctwc Posts: 107
    edited 2012-10-09 04:18
    Hey Mike:

    First, thanks for your most excellent support for everyone Mike, definitely above and beyond!

    Below you can see output from 1. TCPSocketClientDemoDhcpDns and 2. DhcpDemo. The garbage seems endlessly repeating in both cases.

    I have confirmed the wiring. I should mention this Prop+Wiz820io setup is working with another program I wrote using PropGCC. I'd used different pins (and my own SPI driver), but I changed the PropGCC program to use the same pins as your demo and it is working. I'd wondered about nRESET and PWDN (which I control in my PropGCC program) but indeed my program works without them too (i.e. PWDN=GND, nRESET=floating)..

    I'd thought about SPI/speed issues so I a) tried slowing the clock (pll8x) and b) using spi.spin - behavior same, just slower.

    Does the progress of the programs before they 'crash' (infinite repeating garbage display) give you a clue whether the SPI is working? Is the 'ungraceful' (infinite loop) failure mode consistent with any path in your program, or I'm really in the weeds (ex: stack corruption)? The fact the error is consistent and my PropGCC program works would seem to rule out some issues. If you think the SPI is still a suspect can you suggest a simple test program (ex: RAM test Txbuffer).

    Thanks again!

    1.
    Initialize W5200
    Getting network paramters
    Requesting IP.....1$&?@HAI I
  • twctwc Posts: 107
    edited 2012-10-09 04:44
    Hmm...I'd composed a long reply, but when I posted it got a message it would appear after the moderator checked it?

    Anyway, if it doesn't appear in awhile I'll retry...
  • twctwc Posts: 107
    edited 2012-10-09 05:11
    Apologies if duplicate messages...
    First, thanks for your wonderful support for everyone Mike,
    definitely above and beyond the call of duty!

    Let's start with DhcpDemo, you can see display below. It seems to kind of work. I thought error was perfectly
    repeatable, but sometimes bytes to read & amount of buffer displayed varies. But always ends up with infinite repeating
    garbage display (as does TCPClientSocketDemoDhcpDns).

    I should mention this Prop+Wiz820io setup has been working with a PropGCC program I wrote (my own SPI driver). I changed the pin
    definition in my program to match yours and the PropGCC program is still working.

    I was wondering about nRESET and PWDN (which I control in my PropGCC program) but my program works without them too (i.e. PWDN=GND,
    nRESET floating).

    With possible SPI issues in mind I did try a) slowing down the clock (pll8x) and b) using spi.spin, same result just slower.

    Does the progress made by the program seem to indicate the SPI is basically working? Is there any path in your program
    that would account for the infinite garbage loop, or I'm really in the weeds (ex: stack corruption or ?).
    Could you suggest a simple way I can do a SPI test (ex: RAM test W5200 Txbuffer) exercising your code
    to rule out SPI issues?

    Thanks again Mike!

    Initialize
    00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
    -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    0000 01 01 06 33 DA 32 26 00 00 00 00 00 00 00 00 00
    0010 00 00 00 00 00 00 00 00 00 00 00 00 00 08 DC 16
    0020 F8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00E0 00 00 00 00 00 00 00 00 00 00 00 00 63 82 53 63
    00F0 35 01 01 32 04 0A 00 00 24 37 04 01 03 06 2A 0C
    0100 0C 50 72 6F 70 4E 65 74 5F 35 32 30 30 FF 00 00
    0110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    0120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    0130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    0140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    0150 00 00 00 00 00 00 00
    Start: 157 Len: 342
    Send Bytes: 342
    Open
    Send Message
    Bytes to Read: 256

    UPD Header:
    0.0.0.0
    3
    0
    00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
    -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    0000 00
    Start: 165 Len: 0

    Bytes to Read: 0
    Done
    Disconnect
    0.0.1.55
    -2
  • Mike GMike G Posts: 2,702
    edited 2012-10-09 08:23
    Thanks for the feed back. It's not the SPI driver. The Discovery packet was prepared and sent but an offer did not return form the DHCP server. Then all hell broke loose because of poor validation.

    I was able to reproduce the error by firing the Discover packet to 0.0.0.0 port 67. From there I better handled unexpected or no return packets.

    Please give the DhcpDemo a try and let me know if it works any better.
    http://forums.parallax.com/showthread.php?142166-Trouble-getting-W5200-connected-HELPPPPP-newbie&p=1123195&viewfull=1#post1123195
  • twctwc Posts: 107
    edited 2012-10-09 11:10
    I made quite a bit of progress in a roundabout way, just not exactly sure why :=)

    Coincidentally DynamoBen just released W5200 Driver Demo 2.1 so I thought I'd use that to test. I had some problems but got it working. Still not totally clear, but seems possibly interrelated issues of power/hard/soft RESET, fixed/cached/colliding/mismatched MAC&IP settings confusing router, or? Right now I've got your DhcpDemo working, but seems like that's only if I comment out the wiz.SetIP statement? Sorry this is so vague, I'll need to study further before I can contribute anything useful.

    For the moment why don't we move on to TCPSocketClientDemoDhcpDns. After commenting out the wizSetIP stmt it runs reliably...up to a point. DHCP response seems good and I checked DNS resolved IP seems OK, but guess then it got stuck in the loop waiting for sock.Connected. Is this a clue, perhaps related, some kind of 'address' issues?
    Initialize W5200
    Getting network paramters
    Requesting IP.....10.0.0.25
    DNS...............10.0.0.1
    DHCP Server.......10.0.0.1
    Router IP.........10.0.0.1
    Resolve domain IP
    74.125.224.134
    Initialize
    Begin Client Web request
    Open
    Connect
  • Mike GMike G Posts: 2,702
    edited 2012-10-09 12:51
    What port are you using and is your router setup to port forward?

    What was the IP set to with wiz.SetIP? Was it within the subnet?

    Try wiz.SetIp(0, 0, 0, 0)
  • Mike GMike G Posts: 2,702
    edited 2012-10-09 13:29
    My ISP blocks port 80 traffic. If I try to use port 80 I get the exact symptom you described, waiting for a connection.

    This can also happen if port forwarding is on. The same port is used in the W5200 setup but the IP changed due to DHCP. The port did not change but the IP did.

    Set the port argument to -1 to auto-increment the port number. The port parameter is static and starts at 10,000.
    sock.Init(0, TCP, -1)
  • twctwc Posts: 107
    edited 2012-10-09 14:48
    Just tried it with wiz.SetIP(0,0,0,0) and that 'works' (i.e. gets as far as connect). If I use something like wiz.SetIP(10,0,0,40) it crashes.
  • Mike GMike G Posts: 2,702
    edited 2012-10-09 14:54
    Just tried it with wiz.SetIP(0,0,0,0) and that 'works' (i.e. gets as far as connect). If I use something like wiz.SetIP(10,0,0,40) it crashes.
    What does crashes mean?
    Did you grab the latest code? I created a few validation checks that will report errors with the DHCP conversation.
    What port are you using?
  • Mike GMike G Posts: 2,702
    edited 2012-10-09 15:00
    Also make one more code check. This piece of code gets some financial stuff from Google
      pst.str(string("Resolve domain IP", CR)) 
  dns.Init(@buff, 6)
  'remoteIP := dns.ResolveDomain(string("www.agaverobotics.com"))
  remoteIP := dns.ResolveDomain(string("finance.google.com"))
  remoteIP := dns.GetResolvedIp(1)
  PrintIp(remoteIP)
  pst.char(CR)

    Be careful with this line of code remoteIP := dns.GetResolvedIp(1) This will grab the second DNS IP. If a second IP does not exist then the connection will hang.
  • twctwc Posts: 107
    edited 2012-10-09 15:05
    I did try the sock.Init(0,TCP,-1), no change.

    I confess I'm not following you on possible port forwarding issue. My Netgear router has port forwarding and port triggering radio buttons, one has to be on. But there are no 'services' (port mappings) defined for either. Thought port forwarding took incoming from WAN and mapped to LAN? My PropGCC program can access webpages like finance.google.com. so I don't think it's due to router or ISP? With that program, the source ip port doesn't seem to matter at all, can be anything.

    Thanks for bearing with me Mike.
  • Mike GMike G Posts: 2,702
    edited 2012-10-09 15:20
    I mentioned port forwarding because I use port forwarding to hit several different internal network devises from the Internet. Sometimes I forget and configure a W5200 with a port that is forwarded to another IP. For example, DHCP assigned a new IP but I used a forwarded port. Well, in this case you get an outgoing request but the response goes to the wrong IP and the connection hangs.
  • twctwc Posts: 107
    edited 2012-10-09 16:00
    Just tried TcpSocketClientDemoDns (i.e. no DHCP) and it works to access google. Add DHCP (i.e. TcpSocketClientDemoDhcpDns) and it hangs trying to connect. So I can imagine a scenario like you say - client (i.e. W5200) sends connection request to google, but somehow google's response gets misdirected on the way back. But I'm not using any port forwarding as best I can tell. Notice this seems kind of like the issue Igor in the other thread is having (but he's a server) i.e. need wiz.SetIP(0,0,0,0), works ok without dhcp, etc. Seems like a good clue - why would the TSCDD demo work and TSCDDD not? I'll try to poke at it some more. Made a lot of progress today, 90% there, thanks for your support!
  • Mike GMike G Posts: 2,702
    edited 2012-10-09 17:15
    Download wire shark if you don't have it already. It's free and invaluable network troubleshooting tool. You can filter by port or IP. Maybe you'll see something incorrect with the W5200 config after invoking the DHCP. Unfortunately, it works on my end.

    I could be 0.0.0.0 works because the default 192.168.1.107 is not a valid IP on the network.

    I really appreciate the testing help! We'll figure it out eventually.
  • twctwc Posts: 107
    edited 2012-10-10 04:33
    I've definitely got more homework to do, check out all the demos etc. I'll get back when (if :=) I come up with useful input. Thanks a lot for your support Mike and please forgive my noobness!
  • twctwc Posts: 107
    edited 2012-10-10 07:38
    Just noticed running DhcpDemo - it prints 'Initialize' and then 'RemoteIP: 0.180.196.4'. This is just after the call to 'sock.RemoteIP (255,255,255,255)'. Anyway, the program works (subject to aforementioned wiz.SetIP(0,0,0,0) caveat) - just wondering if the displayed RemoteIP is expected behavior.
  • Mike GMike G Posts: 2,702
    edited 2012-10-10 20:49
    That does not look like a good IP. I'll look into it...

    For now here is the latest code. The unit test code can be incomplete.
    Google code repository. This is where you can find all updated code.
  • twctwc Posts: 107
    edited 2012-10-11 04:05
    As an experiment I tweaked TCPSocketClientDemoDhcpDns by adding 'PrintIP(wiz.GetRemoteIP(0))' after the 'PrintIP(RemoteIP)'...there the mystery 0.180.196.4 is again. I would guess the two PrintIP stmts. should show the same value, but that's just a guess. The 0.180.196.4 (also seen in DhcpDemo as mentioned previous post) doesn't appear to cause a problem for DHCP, but maybe an issue for subsequent attempt to connect to google?

    Resolve domain IP // find google IP
    PrintIP(remoteIP): 74.125.224.32 // this is google IP
    PrintIP(wiz.GetRemoteIP(0)): 0.180.196.4 // this IP is ???
  • Mike GMike G Posts: 2,702
    edited 2012-10-11 06:33
    W5200.GetRemoteIp had a bug in it that I fixed a few days ago. Please make sure the GetRemoteIp method returns the temp workspace buffer.
    PUB GetRemoteIp(socket)
  Read(GetSocketRegister(socket, S_DEST_IP0), @workspace, 4)
  return @workspace

    I'll try to do a much better job of documenting bugs on the code repository. Also I'm adding more validation and error messages so we can get better insight to what's happening.
  • twctwc Posts: 107
    edited 2012-10-11 06:38
    I added a diagnostic tweak to TcpSocketClientDemoDhcpDns (sorry, can someone refresh me how to make a 'code' window)...

    pst.str(string("Initialize", CR))
    buffer := sock.Init(0, TCP, 8080)
    sock.RemoteIp(byte[remoteIP][0], byte[remoteIP][1], byte[remoteIP][2], byte[remoteIP][3])
    pst.str(string("PrintIP(wiz.GetRemoteIP(0)): "))
    PrintIp(wiz.GetRemoteIP(0))
    sock.RemoteIp(74,125,224,34)
    pst.str(string("PrintIP(wiz.GetRemoteIP(0)): "))
    PrintIp(wiz.GetRemoteIP(0))
    pst.char(CR)
    sock.RemotePort(80)

    ...and when it runs...

    Initialize
    PrintIP(wiz.GetRemoteIP(0)): 0.180.196.4
    PrintIP(wiz.GetRemoteIP(0)): 0.180.196.4

    I would have thought that after 'sock.RemoteIp(74,125,224,34)' that 'PrintIp(wiz.GetRemoteIP(0))' would display '74.125.224.34'? Anyway, if the remote IP is really the mystery 0.180.196.4 that would explain why it can't connect.

    PS: I'm having trouble to download the newest code...

    http://propeller-w5200-driver.googlecode.com/svn/trunk/propeller-w5200-driver-read-only

    ...gets page not found.

    Sorry to be such a bother Mike, thanks for your support!
  • Mike GMike G Posts: 2,702
    edited 2012-10-11 07:36
    I'll look into it a bit more after work. Please make sure wiz.GetRemoteIP is returning the workspace pointer.
    PUB GetRemoteIp(socket)
  Read(GetSocketRegister(socket, S_DEST_IP0), @workspace, 4)
  return @workspace

    This is the home page of the code repository
    http://code.google.com/p/propeller-w5200-driver/

    If you can get there then click the "Source" tab followed by the browse sub-tab.

    If you can't get there then I must have to configure Google code to allow all anonymous users.
  • twctwc Posts: 107
    edited 2012-10-11 11:24
    ...as for the code, at the checkout...

    http://code.google.com/p/propeller-w5200-driver/source/checkout

    ...it shows an http: link for anonymous download. But if I type (it's not clickable) it in (with or without the 'blank' near the end of URL) I get page not found. I can't recall having complicatons last time I downloaded (nor exactly how I did it :=)

    'return @workspace' did make a big improvement. And I remembered a headscratcher I'd solved before: writes to the W5200 DestinationIP registers aren't reflected until the subsequent CONNECT command is issued...

    Initialize W5200
    *** wiz.GetRemoteIP(0) after wiz.Init: 74.125.224.78
    10.0.0.146
    10.0.0.1
    10.0.0.1
    10.0.0.1
    *** remoteIP from DNS: 74.125.224.67
    *** wiz.GetRemoteIP(0) after sock.RemoteIP(remoteIP): 74.125.224.78
    *** wiz.GetRemoteIP(0)) after sock.Init: 74.125.224.78
    *** wiz.GetRemoteIP(0)) after OPEN: 74.125.224.78
    *** wiz.GetRemoteIP(0)) after CONNECT: 74.125.224.67

    ...but nevertheless TSCDDD still can't connect and GET the webpage - can't catch a break :=)

    I went back to TSCDD (i.e. with DNS, without DHCP) to confirm that it does work i.e. can connect and GET the webpage. While there I noticed the hardwired DNS server address...

    dns.SetDnsServerIp(68, 105, 28, 12)

    ...so just for kicks I copied that into TSCDDD to use the hardwired DNS server instead of the one returned by DHCP. But if I do that...

    Initialize W5200
    *** wiz.GetRemoteIP(0) after wiz.Init: 74.125.224.37
    10.0.0.146
    10.0.0.1
    10.0.0.1
    10.0.0.1
    *** remoteIP from DNS: 0.180.196.4
    *** wiz.GetRemoteIP(0) after sock.RemoteIP(remoteIP): 74.125.224.37
    *** wiz.GetRemoteIP(0)) after sock.Init: 74.125.224.37
    *** wiz.GetRemoteIP(0)) after OPEN: 74.125.224.37
    *** wiz.GetRemoteIP(0)) after CONNECT: 0.180.196.4

    ...lo and behold there's the mystery ip again! And it still can't actually connect and GET. I just confirmed the hardwired DNS (68, 105, 28, 12)works fine in TSCDD (i.e. returns a proper google ip address). So why does (68, 105, 28, 12) return the mystery IP in TSCDDD? Just feels like DHCP and DNS work individually, but somehow aren't playing nice with each other in the demo. I'll keep poking at it, probably turn out to be something simple.

    Wireshark is cool but I guess I'd have to setup my PC as a webserver (or use port forwarding?) to really see what's going on. I was able to see the DHCP broadcasts and also (by hardwiring destIP to my PC instead of google) see that the W5200 is attempting to connect i.e. sends SYN until timeout.

    I'll try to get the updated code and test more, thanks for your support Mike.
  • Mike GMike G Posts: 2,702
    edited 2012-10-11 21:46
    ...as for the code, at the checkout...

    http://code.google.com/p/propeller-w...ource/checkout

    ...it shows an http: link for anonymous download. But if I type (it's not clickable) it in (with or without the 'blank' near the end of URL) I get page not found. I can't recall having complicatons last time I downloaded (nor exactly how I did it :=)
    No "Browse" link? One link to the right of the "Check Out" link?
    ...lo and behold there's the mystery ip again! And it still can't actually connect and GET. I just confirmed the hardwired DNS (68, 105, 28, 12)works fine in TSCDD (i.e. returns a proper google ip address). So why does (68, 105, 28, 12) return the mystery IP in TSCDDD? Just feels like DHCP and DNS work individually, but somehow aren't playing nice with each other in the demo. I'll keep poking at it, probably turn out to be something simple.
    Well, 68, 105, 28, 12 my ISP's DNS server. I probably did an injustice by defaulting network parameters. With that said, I set the default DNS to 0.0.0.0 but it stills works in my environment.

    This weekend I'll add demos that show how to set the network parameters. I'll also take a look a the exception handlers and add more serial debug output so we can better identify issues.
  • twctwc Posts: 107
    edited 2012-10-12 03:51
    Yes, I can browse the files, but seems like the only way to get them is click on each one, then right-click/save-as on the 'view raw file' link to download & save each one individually, can't see how to download the entire batch at once (which isn't a big problem).

    The point I was trying to make about using your ISP DNS server (68.105.28.12) was, while it worked (i.e. returns proper address for google) with some of the simpler demos, it returns an odd address in the problematic one (TSCDDD) - and that odd address (0.180.196.4) had been seen before the 'return @workspace' fix - maybe a clue.

    *** remoteIP from DNS: 0.180.196.4

    I'll monitor the forum, get updated code and keep working at it.

    Thanks for your support Mike.
  • Mike GMike G Posts: 2,702
    edited 2012-10-12 07:00
    0.180.196.4 means that a null pointer was returned. You get the same results with PrintIp(0). I suspect it has something to do with the DHCP or DNS process. I can only speculate at this point but I believe it has to do with parsing a return packet

    This week end I'll tighten up the code and add more error traps. This should help identify the code block causing the problem in your environment. Most likely I'll need you to supply a dump of the packets received.
  • Mike GMike G Posts: 2,702
    edited 2012-10-12 07:17
    Make sure you have the latest DHCP and TcpSocketClientDemoDhcpDns.spin. If DHCP is throwing an error and you are not seeing it then you might have an older version.

    If TcpSocketClientDemoDhcpDns.spin does not contain the following code block in Main then you do not have the latest version. 
      pst.str(string("Getting network paramters", CR))
  dhcp.Init(@buff, 7)
  pst.str(string("Requesting IP....."))
  ifnot(dhcp.DoDhcp)
    pst.str(string(CR, "Error Code: "))
    pst.dec(dhcp.GetErrorCode)
    pst.char(CR)
    pst.str(dhcp.GetErrorMessage)
    pst.char(CR)
    return
  else
    PrintIp(dhcp.GetIp)
  • Mike GMike G Posts: 2,702
    edited 2012-10-13 09:08
    Please get the latest Socket.Spin from the code repository. I fixed a timeout bug.

    Plus I removed the default values form the W5200, DNS, and DHCP objects. The demos were also updated accordingly.
  • Mike GMike G Posts: 2,702
    edited 2012-10-13 13:26
    After working with Igor, I have a very good idea what's going on. The Gateway address is not being assigned. I have to go through Igor's packet dump to figure out why the server IP is blank in the Offer packet. The server IP is probably in another location.
  • twctwc Posts: 107
    edited 2012-10-13 17:38
    Other than the problem with TSCDDD the new codes are working well, no crashes. And the HTML Graphing demo is great, I had it going on my PC and iPad. Very impressive work Mike.
Sign In or Register to comment.