Problems with SimpleServer and SimpleClient Sketches

[MarkV]

I just purchased an AsyncLabs BlackWidow 1.0 WiFi board. I have
successfully connected it to a Verizon Actiontec MI242-WR wireless
router (with WPA2 security) using the both the WebServer and
SocketApp example sketches.

However, I have been unsuccessful in getting both the SimpleServer
and Simple Client WiServer example sketches to run properly.
Specifically, the sketches appear to successfully initialize the
connection (via WiServer.init()) and I get a blue connection light.
However, after about five seconds of looping in WiServer.server_task(),
the code appears to crash inside the zg_drv_process() function. The
process of connection initialization, 5 seconds of connection time, then
apparent crash repeats itself over and over. During the 5 seconds of
connection time, I am able to connect to the server (SimpleServer sketch)
using a web browser.

Does anyone have any idea what might be happening to cause the apparent
crash in the zg_drv_process() function?

How do I go about adding Serial.println() debugging statements to
the zg_drv_process() function in g2100.c to debug this function?
When I have tried to add Serial.println() statements to g2100.c,
I get "'Serial' undeclared (first use in this function)" compilation
errors. How do I get Serial.println() to work in g2100.c, i.e. what
header file(s) do I need to include?

Finally, is there some documentation available which describes how
ZeroG Wireless G2100 chip works, so that I can attempt to understand
what the c2100.c code is doing?

Thanks ahead of time for any help that can be provided!

Mark

[GregEigsti]

If you post a reproduce sketch it would be easier to make a guess. WiServer is a layer which makes it easier to create HTTP web server/clients - its possible that something bad is happening in WiServer if your socket/WebServer sample apps work.

Serial.print() won't work in .c files because it is a c++ object; the best you can try is to selectively move the code you want to debug into a .pde/.cpp file and wrap with "extern c" as needed. There are a couple of threads around here on doing that.

I believe that you can get the ZeroG docs on the ZeroG web site; at least I think I remember someone being pointed in that direction.

I've had SimpleServer running on a BlackWidow for 5-10 minutes and it is still working. Will leave it up overnight to see what happens...

Greg

[GregEigsti]

My BlackWidow + SimpleServer setup ran all night (and is still churning away). Ran a bash script which looped over a curl fetch to the BlackWidow and have received > 13K web pages - and climbing

Maybe your sketch has some funkiness?

Greg

[MarkV]

Greg,

Thanks for the replies.

I am just using the example SimpleServer sketch provided in the WiShield library. The only modifications are to the local_ip[] = {192,168,1,8}, ssid[] (changed to my network's SSID) , security_type = 3 (for WPA2), and security_passphrase[] (changed to my network's pass phrase). Even with just these basic changes, I see the problem. Later, I added some Serial.println() debugging statements and was able to determine that the code appeared to crash after entering, but not returning from the zg_drv_process() function while looping in the WiServer.server_task() method.

I assume that there must some funky interaction between my wireless router and the zg_drv_process() function. However, as I mentioned in my original post, I am able to run the example WebServer sketch (which uses the zg_drv_process() function) with no problems. So I don't know why it doesn't work properly in the SimpleServer sketch.

I will try to get debugging information from inside the zg_drv_process() function to find out what is happening.

Thanks again for your help!

Mark

[GregEigsti]

Have you tried with a different WiFi security type (or none)? Seems like this should be transparent to WiServer code but you never know...

[MarkV]

Greg,

I opened up the network and saw the same behavior. With the open security the board connects quickly to the network. However after about 5 seconds, the connection drops and the process repeats just like before with WPA2 security.

Mark

[GregEigsti]

Dunno what to tell you, maybe try another AP?

[MarkV]

Greg,

I was finally able to print degbuging statements from the G2100 functions by copying the entire g2100.c file into my SimpleServer.pde and enclosing the g2100 code in an extern "C" block.

I discovered in the void zg_process_isr() function, in the ZG_INTR_ST_RD_CTRL_REG case, the code was attempting to use spi_transfer() to transfer 1499 bytes to zg_buf, which is apparently only 400 bytes in size. This is apparently what is causing the crash.

Here is the debugging code fragment at case ZG_INTR_ST_RD_CTRL_REG in zg_process_isr()...

Code: Select all

      case ZG_INTR_ST_RD_CTRL_REG:
                Serial.println("case ZG_INTR_ST_RD_CTRL_REG:");
      {
                        Serial.println("case ZG_INTR_ST_RD_CTRL_REG: P1");
         U16 rx_byte_cnt = (0x0000 | (hdr[1] << 8) | hdr[2]) & 0x0fff;

                        Serial.println("case ZG_INTR_ST_RD_CTRL_REG: P2");

         zg_buf[0] = ZG_CMD_RD_FIFO;
                        Serial.print("case ZG_INTR_ST_RD_CTRL_REG: P3, rx_byte_cnt = ");
                        Serial.print(rx_byte_cnt);
                        Serial.println(" ");
                       
         spi_transfer(zg_buf, rx_byte_cnt + 1, 1);
                        Serial.println("case ZG_INTR_ST_RD_CTRL_REG: P4");


         hdr[0] = ZG_CMD_RD_FIFO_DONE;
                        Serial.println("case ZG_INTR_ST_RD_CTRL_REG: P5");

         spi_transfer(hdr, 1, 1);
                        Serial.println("case ZG_INTR_ST_RD_CTRL_REG: P6");

         intr_valid = 1;
                        Serial.println("case ZG_INTR_ST_RD_CTRL_REG: P7");

         intr_state = 0;
                        Serial.println("case ZG_INTR_ST_RD_CTRL_REG: P8");

         break;
      }


Here id the debugging output. After printing the size of rx_byte_cnt, garbage is printed to the screen.

case ZG_INTR_ST_RD_CTRL_REG: P1
case ZG_INTR_ST_RD_CTRL_REG: P2
case ZG_INTR_ST_RD_CTRL_REG: P3, rx_byte_cnt = 1499
[Garbage past this point...]
>1</NetConnectType>
<MocaNodeID>2</MocaNodeID>
<MocaVersion>02.69</MocaVersion>
<HmaAuth>Yes</HmaAuth>
<HmaContSupport>SDorHD</HmaContSupport>
<NumContSes>0</NumContSes>
</HmaDevice>
</HmaNetConfig>
2:
ID>2</MocaNodeID>

I found two buffer lengths, UIP_CONF_BUFFER_SIZE (line 90 in uip-conf.h) and UIP_BUFSIZE (line 414 in uipopt.h), which appeared to be related to the size of zg_buf. I changed them both from 400 to 2000 in attempt to get the code running. However, this didn't work (I could not even get a connection).

Any ideas on how the size of zg_buf can be increased so the code doesn't crash?

Mark

[GregEigsti]

I was finally able to print degbuging statements from the G2100 functions by copying the entire g2100.c file into my SimpleServer.pde and enclosing the g2100 code in an extern "C" block.

Been there, done that, feel for you Have not looked at the code but a 1499 byte spi tx does sound too large for anything in the uIP stack. Any idea why your sketch/browser are passing large "packets" around? The unchanged sample sketches all tx\rx much less data. But then again I have never debugged g2100.c so am just guessing

Whats all the xml looking stuff in your output (mocanode)?

Greg

[MarkV]

Greg,

MoCA stands for Multimedia over Coax Alliance, a new networking standard that allows digital entertainment and information to be transmitted and distributed to multiple devices over coax cables. I checked my Verizon ActionTec wireless router's users guide and discovered that it supports Moca. I also found a posting on another AV forum which suggested that Verizon FIOS uses MoCA is to support their Video on Demand function. Therefore, I assume that these long MoCA messages being broadcast through my wireless network are what is causing the apparent buffer overflow in the software.

Mark