Yes it WAS powered via the TI Board, but more or less suggested, I’ve changed to have it powered by the CerbuinoBee only and it still is running with ping times around 4 ms but they exceed far over 100 … sometimes …
Strange though, I’ve had the same software running and the cc3000 boost connected to a CerbuinoNet and it would not even deploy. Once disconnected the ti board than it deployed but failed as soon as I connected the ti board powering the CC3000 … now I can try something different … fails as well even with external power the CerbuinoNet … no deploy, VS freezes etc. … some other time …
@ mhectorgato - the cc3000 boost is powered from the cerbuinobee and still running a ping -t from my pc since more than 20 hrs now. Most of the pings are done in 3 - 9 ms with now and than a couple of exceptions running the web server example included with the software. This has to be started from VS in Debug though, starting in release mode and doing a power cycle did not return any replies not even after 5 mins. However once started in VS, VS can be killed and the device keeps on running just fine. At least for the last 20+ hrs.
I’ve quickly soldered a gadgeteer plug to a WRL-3000 without any additional stuff and changed the profile to socket one and got the following result:
CC3000 Wifi Network Discovery Example
Starting up CC3000...
Sending - Simple Link Start
Response Received -- Simple Link Start Confirmed
Setting Event Mask
Response Received -- Event Mask confirmed
Requesting SP Version
Response Received -- SP Version is 0.6.1.10
Warning: This firmware version is old and will not work correctly with most UDP and TCP communications operations.
Requesting Buffer Size
Response Received -- Buffer Available: 6, Size: 1500
Configuring DHCP
Response Received -- DHCP Configured.
The thread '<No Name>' (0x4) has exited with code 0 (0x0).
Found 1 WiFi Networks:
SSID - Signal Strength - Security
-----------------------------------
AK16-US 73 Secured
Well, in the end it succeeded to patch a WRL-3000, but had to try several times. Had to closed VS and disconnect the device several times. But it patced woohoo another on 24 cool this is through socket one … cool, next one is for the cerberus …
CC3000 Wifi Patch Programmer
Starting up CC3000...
Sending - Simple Link Start
Response Received -- Simple Link Start Confirmed
Setting Event Mask
Response Received -- Event Mask confirmed
Requesting SP Version
Response Received -- SP Version is 0.6.1.10
Warning: This firmware version is old and will not work correctly with most UDP and TCP communications operations.
Requesting Buffer Size
Response Received -- Buffer Available: 6, Size: 1500
Configuring DHCP
Response Received -- DHCP Configured.
The thread '<No Name>' (0x4) has exited with code 0 (0x0).
Shutting down CC3000...
Starting up CC3000...
Sending - Simple Link Start (2)
Response Received -- Simple Link Start Confirmed
FAT: 4C530000F301A0015100A0019303001093130010932300209343002093631000A1631000F3634000B3634000316400043368000200000000000000000000000000000000
Your MAC address is: 08002856E5DA
WRITE IT DOWN!!!!!!!!!!!!!!!!!!
If this patch fails, you may need to restore it manually!
If you lose your MAC address, it is gone forever!
Radio Stuff: 03000101101000272727272727272727272727272723252525252525252525232323230000000000000000000000000000000000000000005050505050505050505050505050505050505050505050505050505050505050505050017780501F22252527501F22252527501F222525271E2D01020202020011111511150F0EFF
**** PATCHING FIRMWARE NOW ***** -- PLEASE WAIT!
Writing File 4
Writing File 5
******* FIRMWARE UPDATE COMPLETE *******
Rebooting with new firmware (fingers crossed)
Shutting down CC3000...
Starting up CC3000...
Sending - Simple Link Start
Response Received -- Simple Link Start Confirmed
Setting Event Mask
Response Received -- Event Mask confirmed
Requesting SP Version
Response Received -- SP Version is 0.6.1.24
Requesting Buffer Size
Response Received -- Buffer Available: 6, Size: 1500
Configuring DHCP
Response Received -- DHCP Configured.
The thread '<No Name>' (0x5) has exited with code 0 (0x0).
WOO HOO, Firmware successfully patched!
The thread '<No Name>' (0x1) has exited with code 0 (0x0).
Done.
The major complaint the software reported that the irq was not responding in a timely fashion and an exception was raised. But after performing this several times and cleaning the complete solution it finally worked.
WOW, what a wiring job! splicing a gadgeteer cable is something I tried once and it ended very badly ;). But, this should be identical to the GHI module. How reliable is it?
P.S. After a few changes, the web server served a web page every 10 seconds for a total of 58 minutes! Getting better… Hopefully, the TCP stuff will be reliable within the next week.
@ Valkyrie-MT - Running the Discovery example at first gives:
CC3000 Wifi Network Discovery Example
Starting up CC3000...
Sending - Simple Link Start
Response Received -- Simple Link Start Confirmed
Setting Event Mask
Response Received -- Event Mask confirmed
Requesting SP Version
Response Received -- SP Version is 0.6.1.24
Requesting Buffer Size
Response Received -- Buffer Available: 6, Size: 1500
Configuring DHCP
Response Received -- DHCP Configured.
The thread '<No Name>' (0x4) has exited with code 0 (0x0).
Found 1 WiFi Networks:
SSID - Signal Strength - Security
-----------------------------------
AK16-US 83 Secured
and than the webserver immediately afterwards:
CC3000 Web Server Example Application
Starting up CC3000...
Sending - Simple Link Start
Response Received -- Simple Link Start Confirmed
Setting Event Mask
Response Received -- Event Mask confirmed
Requesting SP Version
Response Received -- SP Version is 0.6.1.24
Requesting Buffer Size
Response Received -- Buffer Available: 6, Size: 1500
Configuring DHCP
Response Received -- DHCP Configured.
The thread '<No Name>' (0x4) has exited with code 0 (0x0).
Resetting Connection before setting Policy.
Connection Disconnect.
Setting Connection Policy.
Response Received -- Connection Policy Set
Attempting Connection to AK16-US
WLAN Connection Established! Waiting for IP assignment from router...
IP Address Acquired => 192.168.39.25
Requesting Network Connection details...
Woot! We are now connected to Wifi!
Network Name: AK16-US
IP address: 192.168.39.25
MacAddress: 08002856E5DA
Gateway: 192.168.39.123
DNS Server: 192.168.39.123
Opening TCP Socket
Acknowledged Socket Command: 040110050000000000
Socket ID is 0
Acknowledged Bind Success
040510110000000000FEFFFFFF0200000000000000.
again, web page can be displayed in a browser once. Pressing F5 for Refresh makes the web page wait forever …
but the ping goes on … even with VS closed … it keeps on pinging … pretty much the same as with the boost.
I’ll let you know toomorrow CET, it’s midnight over here, so I’m hitting my pillow …
I let the webserver run for more than 17 hrs now and the ping times from pc to the WRL3000 device is more or less 3ms with now and than a couple of high peeks and that with normal work on the pc. I connected an ethernet cable and disconnected wifi didn’t give a … the ping went on as if nothing had happened. Looks stable to me …
Will be away from all this for at least a week now, 'til than … happy times … I know I will …
I am trying to post data to Azure via a web service that i have used with other devices.
Can the current driver send data over a socket ?
it looks like i am connecting but i never receive anything back and the data is never written to the database. also i am getting some odd double send messages
Opening TCP Socket
Acknowledged Socket Command: 040110050000000000
Socket ID is 0
Handling Response for OpCode: 1006, Payload: 040610050000000000
Sent 167 bytes on Socket 0
Sent 4294967295 bytes on Socket 0
Sent 64 bytes on Socket 0
Sent 4294967295 bytes on Socket 0
Handles: 1, buffers: 256, Released Packets: 2
Sent 119 bytes on Socket 0
Sent 4294967295 bytes on Socket 0
Sent 136 bytes on Socket 0
Sent 4294967295 bytes on Socket 0
Handles: 1, buffers: 256, Released Packets: 2
i don’t have any idea what that 4294967295 byte message is.
any pointers?
Yeah, I had to rewrite a bunch of stuff in the driver because of a deadlock that happened under heavy traffic. It’s mostly working again but I am trying to get TI to fix some issues in the firmware. But, that doesn’t explain your problem. A wireshark trace would be helpful, but I think TI reports a data length of -57 when the socket is closed. It may be that -57 cast as a uint is 4294967295 . The wireshark trace would show if the socket is getting closed.
I have integrated an automated system to detect problems with the cc3000 and automatically reset and restore preexisting listeners. With this feature, the web server is now very durable and recovers from burst of heavy traffic that normally crash the cc3000. Here is a demo of it automatically restarting itself after I held the F5 (browser refresh) for an extended duration.
I am trying to implement Local name resolution, but ran into another firmware bug (CC3000 combines data from multiple UDP packets that have different source ports! - Wi-Fi forum - Wi-Fi - TI E2E support forums). Hopefully TI will address the problem soon. I went ahead and implemented mDNS and LLMNR name resolution anyway and this is a screenshot of the first success. It shows how you can set the name and the browser will be able to resolve it and server the web page. My plan is to use 2 sockets for the webserver and 2 sockets for name resolution via LLMNR and MDNS. This should allow almost anything on the local network to open the web page…
This should all work with any .NET MF device + cc3000. I am just implementing the local name resolution through udp sockets. It has worked a few times, but is very inconsistent. However, I am optimistic because the Listener on the Multicast IP appears to work (other than combining packets), which was my biggest concern. The firmware bug can be worked around because Windows machines seem to send the IPv4 packet first, so the cc3000 response happens to have the port number I need. For machines other than Windows, they will resolve with mDNS, and it’s not an issue there. If that makes any sense.
The WebServerWithLocalName.cs implements the local name resolution. But, as I said, it’s very flakey right now, although the responses being sent look good, the client does not seem to work usually…
Updated the Cerberus HW V1.2 to the 4.2.6.1 = SDK R3. Worked like a charm, tinybooter first, firmware w/o ethernet second. Got the 29414 changeset, deployed to 4.2, changed the name to Peter.Local and used socket 6. First deploy got me a CC3000 and the normal interrupt issue as if the device is not connected, after a couple of shakes and another deploy (only stop and F5) Connected now:
CC3000 Web Server with Local Name resolution Example Application
Starting up CC3000...
Sending - Simple Link Start
06/01/2011 00:02:04 Sending (4000)
06/01/2011 00:02:05 New Response Received (4000)
Setting Connection Policy.
06/01/2011 00:02:05 Sending (0004)
Handling Response for OpCode: 4000, Payload: 0400400100
Response Received -- Simple Link Start Confirmed
06/01/2011 00:02:06 New Response Received (0004)
06/01/2011 00:02:06 Sending (2009)
Handling Response for OpCode: 0004, Payload: 040400050000000000
Response Received -- Connection Policy Set
06/01/2011 00:02:06 New Response Received (2009)
Requesting SP Version
06/01/2011 00:02:06 Sending (0207)
06/01/2011 00:02:06 New Response Received (0207)
Requesting Buffer Size
Handling Response for OpCode: 2009, Payload: 0409200100
Handling Response for OpCode: 2009, Payload: 0409200100
06/01/2011 00:02:06 Sending (400B)
06/01/2011 00:02:06 New Response Received (400B)
Configuring DHCP
06/01/2011 00:02:06 Sending (2001)
Handling Response for OpCode: 0207, Payload: 040702050000060118
Response Received -- SP Version is 0.6.1.24
Handling Response for OpCode: 400B, Payload: 040B40040006DC0500
Response Received -- Buffer Available: 6, Size: 1500
06/01/2011 00:02:06 New Response Received (2001)
The thread '<No Name>' (0x5) has exited with code 0 (0x0).
Handling Response for OpCode: 2001, Payload: 0401200100
Response Received -- DHCP Configured.
06/01/2011 00:02:15 New Response Received (8200)
and a never ending series of
Handling Response for OpCode: 8200, Payload: 0400820100
Keep Alive
*** Beat ***
*** Beat ***
06/01/2011 00:02:25 New Response Received (8200)
Handling Response for OpCode: 8200, Payload: 0400820100
Keep Alive
*** Beat ***
*** Beat ***
*** Beat ***
06/01/2011 00:02:35 New Response Received (8200)
*** Beat ***
Handling Response for OpCode: 8200, Payload: 0400820100
Keep Alive
*** Beat ***
*** Beat ***
06/01/2011 00:02:45 New Response Received (8200)
*** Beat ***
Handling Response for OpCode: 8200, Payload: 0400820100
Keep Alive
*** Beat ***
*** Beat ***
*** Beat ***
*** Beat ***
06/01/2011 00:02:55 New Response Received (8200)
Handling Response for OpCode: 8200, Payload: 0400820100
Keep Alive
*** Beat ***
*** Beat ***
*** Beat ***
Used a bonjour browser, received all my other stuff but NOT the CC3000 well actually Peter.Local … typing it in a browser got me a result though … from google
But as you stated it may work or not … I’ll keep on trying …
Well … at least the code, I think it was changeset 29096 does still run even being at the latest SDK and deploying to a lower version seems to work on a CerbuinoBee Socket 1 @
Loader (TinyBooter) version information:
4.2.6.1 on this computer.
4.2.6.0 on this device.
The Loader (TinyBooter) not up to date. <<<
Firmware (TinyCLR) version information:
4.2.6.1 on this computer.
4.2.6.0 on this device.
The Firmware (TinyCLR) is not up to date. <<<
Please wait for the device to reboot… Done.
This gets an IP, does show up in my router stats and sends packets.
Deploy the latest changeset to the CerbuinoBee gives the same result as mentioned in the previous topic, although some watchdog messages are showing …
....
Handling Response for OpCode: 2001, Payload: 0401200100
Response Received -- DHCP Configured.
06/01/2011 00:02:35 New Response Received (0002)
Setting Connection Policy.
06/01/2011 00:02:35 Sending (0004)
Handling Response for OpCode: 0002, Payload: 04020005007FFFFFFF
Connection Disconnect.
06/01/2011 00:02:36 New Response Received (0004)
Attempting Connection to AK16-US
06/01/2011 00:02:36 Sending (0001)
Handling Response for OpCode: 0004, Payload: 040400050000000000
Response Received -- Connection Policy Set
Handling Response for OpCode: 8200, Payload: 0400820100
Keep Alive
*** Beat ***
Watchdog Check
06/01/2011 00:02:50 Sending (400B)
06/01/2011 00:02:50 New Response Received (400B)
Handling Response for OpCode: 400B, Payload: 040B40040006DC0500
Response Received -- Buffer Available: 6, Size: 1500
*** Beat ***
...
This all done on a WRL3000 module similar to the GHI one. The last lines asof - keep alive, etc are repeated forever …
