The Netduino forums have been replaced by new forums at community.wildernesslabs.co.
This site has been preserved for archival purposes only
and the ability to make new accounts or posts has been turned off.
Spark Core (TI CC3000) Porting for Super WiFI Mini?
Piwi, I have a NetduinoPlus. What firmware version are you using? I will try to match your firmware and hardware to see if I can reproduce this.
Also, one thing I can point out is make sure the CLK, MOSI, and MISO wires are as short as possible and exactly the same length. At high speeds, SPI becomes very sensitive to wire length.
I'm using the following:
HalSystemInfo.halVersion: 4.2.0.0HalSystemInfo.halVendorInfo: Netduino Plus (v4.2.0.1) by Secret Labs LLCHalSystemInfo.oemCode: 34HalSystemInfo.modelCode: 177HalSystemInfo.skuCode: 4097HalSystemInfo.moduleSerialNumber: 00000000000000000000000000000000HalSystemInfo.systemSerialNumber: 0000000000000000ClrInfo.clrVersion: 4.2.0.0ClrInfo.clrVendorInfo: Netduino Plus (v4.2.0.1) by Secret Labs LLCClrInfo.targetFrameworkVersion: 4.2.0.0SolutionReleaseInfo.solutionVersion: 4.2.0.0SolutionReleaseInfo.solutionVendorInfo: Netduino Plus (v4.2.0.1) by Secret Labs LLCSoftwareVersion.BuildDate: Sep 19 2012SoftwareVersion.CompilerVersion: 410894FloatingPoint: TrueSourceLevelDebugging: TrueThreadCreateEx: TrueLCD.Width: 0LCD.Height: 0LCD.BitsPerPixel: 0AppDomains: TrueExceptionFilters: TrueIncrementalDeployment: TrueSoftReboot: TrueProfiling: FalseProfilingAllocations: FalseProfilingCalls: FalseIsUnknown: False
For the wires they are the same long lengths, tried some short ones 7.5 cm (3") ... and am using external power supply for the CC3000 (LM1117T) should be enough. Did rerun the program and ...
CC3000 Example ApplicationCC3000 Driver: IRQ state = TrueStart: PowerUp enabledInterrupt!Sending Command: 4000Waiting for Response...Sending Command: 0008Waiting for Response...Interrupt!Sending Command: 0207Waiting for Response...Interrupt!Sending Command: 400BWaiting for Response...Interrupt!Interrupt!Sending Command: 2001Waiting for Response...The thread '<No Name>' (0x5) has exited with code 0 (0x0).Init: Completed = TrueSending Command: 0002Waiting for Response...Interrupt!Sending Command: 0004Waiting for Response...Interrupt!Sending Connect...!Sending Command: 0001Interrupt!Waiting for Response...
Sorry for the not so good news after all ....
Reported FW on stellaris ....
Example App:driver version 5.14.7.13027AK16-US0DONEIP:192.168.39.140
??? while playing I discovered that my lm1117 got kind of warm, just about touchable, so I took the vbat out and wanted to pin to another place on the breadboard. By accident, I replaced it back to 3.3V and a response came in, a bad one, but some response containing 10 times 0xFF causing an memory allocation failure ... btw ... I changed pin D4 into D10 ... don't know if that matters here though ... I did exchange the cc3000 module with the second one to verify if it's still working, and piggy bagged it back on to the stellaris board and got a network connection again ...
CC3000 Example ApplicationCC3000 Driver: IRQ state = TrueStart: PowerUp enabledInterrupt!Sending Command: 4000Interrupt!Waiting for Response...Sending Command: 0008Waiting for Response...Interrupt!Reading incoming message from CC3000 started ...Failed allocation for 5463 blocks, 65556 bytesFailed allocation for 5463 blocks, 65556 bytesA first chance exception of type 'System.OutOfMemoryException' occurred in Networking.WifiAdapter.dllAn unhandled exception of type 'System.OutOfMemoryException' occurred in Networking.WifiAdapter.dll
@piwi
Clean power to the CC3000 seems to be critical. A hot to the touch regulator doesn't sound right.
The LS Research TiWi-SL CC3000 module power requirements can be found here,
I think all of this difficulty with CC3000 modules must somehow be related to patches. It might be worthwhile to dig into Valkyrie-MT's code for wlan_start(0) and change the argument to 1.
From the TiWi-SL forum:======================="If you try and flash the SP and the TiWi-SL no longer boots successfully (patch may have gotten corrupted) you can use wlan_start(1) instead of wlan_start(0); wlan_start(1) functions tells the TiWi-SL to ignore the SP in the EEPROM because the host micro may load the patch instead. So if you brick the TiWi-SL by flashing a bad patch you can use wlan_start(1) to boot the module, flash the new SP, then go back to using wlan_start(0)."From the TI forum:=================="You can load new patches (driver and firmware, no boot loader patches needed) if you have an empty EEPROM. You can use our latest patch programmer utility version 1.10.2 which wake the device without patches by calling wlan_start(1) instead of wlan_start(0). If you are looking on the CC3000 init operation section on the wiki page you can see that in the first command: HCI_CMND_SIMPLE_LINK_START you can specify if patches are available from host or not. If not (0 value), CC3000 device will look for them in the EEPROM. If patches are available from host (value 1), CC3000 will assume there are no patches in the EEPROM and will start the device without patches. Starting the device without patch is a normal operation, the only affect is that the code fixes implemented in the patches won't apply. In a case like yours, where the patches in the EEPROM are corrupted or not present, you can start the device without patches (IRQ line will perform falling edge), burn the patches with the patch programmer utility, and then, after the patches are in the EEPROM, run your application with wlan_start(1).
?
EDIT:
Just bricked another CC3000 ... I was fooling with Valkyrie-MT's code and made an inappropriate change. Now, the CC3000 thinks it has been initialized and gives:
CC3000 Example ApplicationSending Command: 4000Waiting for Response...New Event: OpCode: 4000Handling Response for 4000Response Received -- Simple Link Start ConfirmedSending Command: 0008Waiting for Response...New Event: OpCode: 0008Handling Response for 0008Response Received -- Event Mask confirmedSending Command: 0207Waiting for Response...New Event: OpCode: 8001Handling Response for 8001WLAN Connection! New Event: OpCode: 0207Handling Response for 0207SP Version is 0.6.1.10.2New Event: OpCode: 8010Handling Response for 8010IP Address Acquired => 0.68.130.0 <--- IP address should be 192.168.0.130Sending Command: 2005Waiting for Response... <--- hangs
Before, the CC3000 would initialize properly. It is now crucial to find a way to re-program the EEPROM. I am going to give the patch programmer a try.
this.Send(new Command(HciCommand.HCI_CMND_SIMPLE_LINK_START, new Byte[1] {1}));
[font="verdana, geneva, sans-serif;"]and the result is a wunderful, very long log with responses but not as one would expect [/font]
CC3000 Example ApplicationCC3000 Driver: IRQ state = TrueStart: PowerUp enabledInterrupt!Sending Command: 4000Waiting for Response...Interrupt!Reading incoming message from CC3000 started ...New Event: OpCode: 0404Handling Response for 0404Interrupt!Reading incoming message from CC3000 started ...New Event: OpCode: 0000Handling Response for 0000Interrupt!Reading incoming message from CC3000 started ...New Event: OpCode: 0404Handling Response for 0404Interrupt!Reading incoming message from CC3000 started ...New Event: OpCode: 0000Handling Response for 0000Interrupt!Reading incoming message from CC3000 started ...
this goes on for a long time until it finally stops doing what so ever ....
However if I change the code line mentioned above into:
this.Send(new Command(HciCommand.HCI_CMND_SIMPLE_LINK_START, new Byte[1] {0}));
I get the old not so good response:
CC3000 Example ApplicationCC3000 Driver: IRQ state = TrueStart: PowerUp enabledInterrupt!Sending Command: 4000Waiting for Response...Interrupt!Init: Completed = False
and there it hangs again ....
if tried regular 0 and 1 as well, same story ...
maybe I should attend a couple of classes in C rather than solving this, it might be faster, at least less frustrating ....
but some response containing 10 times 0xFF causing an memory allocation failure ...
Failed allocation for 5463 blocks, 65556 bytesA first chance exception of type 'System.OutOfMemoryException' occurred in Networking.WifiAdapter.dllAn unhandled exception of type 'System.OutOfMemoryException' occurred in Networking.WifiAdapter.dll
A reason you might get an out of memory exception here is when it reads the response, it parses out the response size and allocates an array for the response. If this read has a small glitch, it could allocation a huge array and quickly run out of RAM.
I know the TI CC3000 uses an SPI mode called CPOL. I believe this requires a different setting in the
Attached is my current code. It is more explanatory in the output instead of dumping a bunch of codes. It opens a socket and repeatedly sends a UDP message. Note: you will have to open each project and switch to version 4.2 of the Framework, because I have switched to a custom 4.3 firmware to track down the memory leak. This is what the output looks like now:
CC3000 Example ApplicationSending - Simple Link StartResponse Received -- Simple Link Start ConfirmedSetting Event MaskResponse Received -- Event Mask confirmedRequesting SP VersionResponse Received -- SP Version is 0.6.1.7Requesting Buffer SizeResponse Received -- Buffer Available: 6, Size: 56325Configuring DHCPResponse Received -- DHCP Configured. The thread '<No Name>' (0x3) has exited with code 0 (0x0).Resetting Connection before setting Policy. Response Received -- Connection Disconnect.Setting Connection Policy.Response Received -- Connection Policy SetAttempting Connection to linksysWLAN Connection Established! Waiting for IP assignment from router... IP Address Acquired => 192.168.1.77Requesting Network Connection details...Woot! We are now connected to Wifi!Network Name: linksysIP address: 192.168.1.77MacAddress: 080028017XXXGateway: 192.168.1.254DNS Server: 192.168.1.254Opening UDP SocketResponse Received -- Socket Command: 040110050000000000Socket ID is 0Sending Message on socket 0 to 192.168.1.84:51000Sending Message on socket 0 to 192.168.1.84:51000Sending Message on socket 0 to 192.168.1.84:51000Sending Message on socket 0 to 192.168.1.84:51000
The problem is clearly in the BINARY_BLOB_HEAD, but I have no clue what that is... And it was a LOT of work to build a custom firmware just for that bit of info... ugh.
Update: Every time the garbage collector runs, BINARY_BLOB_HEAD adds 60 bytes. There seems to be no coorelation to actual execution of the code. Sometimes it sends 30 messages, sometimes it sends one, but when the GC happens, I tack on 60 more bytes... I will probably have to dissect my code and reconstruct until the leak reproduces... This will take some time
Well, I was able to recover my bricked CC3000 with the bad IP address. I went back to the MSP430G2553 and deployed the Basic WiFi Application with Code Composer. I then reprogrammed the IP address and gateway with the commands:
@Valkyrie-MT: Could your memory leak be possibly related to this,
...Waiting for Response...New Event: OpCode: 400BHandling Response for 400BBuffer Size is 115082496 <------pretty big bufferSending Command: 2001...
I tried to run your V3 code, but VS complained about MF4.3. I guess I must install it.
F:Visual Studio 2010CC3000 Managed WifiWiFiExample_V3ManagedCC3000WifiWifiExampleApp - 43 NewWifiExampleAppWifiExampleApp.csproj : error : Unable to read the project file 'WifiExampleApp.csproj'.
F:Visual Studio 2010CC3000 Managed WifiWiFiExample_V3ManagedCC3000WifiWifiExampleApp - 43 NewWifiExampleAppWifiExampleApp.csproj(32,3): The imported project "C:Program Files (x86)MSBuildMicrosoft.NET Micro Frameworkv4.3CSharp.Targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
I tried to run your V3 code, but VS complained about MF4.3. I guess I must install it.
Don't install 4.3 just for this. I will retarget to 4.2 and zip another copy to post. That buffer is actually not parsed correctly when it prints. I don't know what the format is and it was not a priority since it really isn't used for anything.
Don't install 4.3 just for this. I will retarget to 4.2 and zip another copy to post. That buffer is actually not parsed correctly when it prints. I don't know what the format is and it was not a priority since it really isn't used for anything.
Retargeted ur code to 4.2 and just let it run on my N+1 and it got a responseHeader back filled with 10 times 0xFF causing the payload size go to -1 at the statement below (519 in my code) in the Read() routine in CC3000Driver.cs ???
pktReadPayload = new byte[payloadSize];
A possitive thing is that you mentioned your sp version I modified the Stellaris Basic Wifi program a bit to show the MAC and the sp version.
The Boost without any patching:
Example App:driver version 5.14.7.13MAC 08:00:28:01:6F:DBSP: 0.6.1.7027AK16-US0DONEIP:50.50.50.50
Oops ... some strange IP
Let's go to the Boost with the patches:
Example App:driver version 5.14.7.13MAC 08:00:28:56:D3:81SP: 0.6.1.19027AK16-US0DONEIP:192.168.39.19
Now this one is ok and can be pinged:
C:UsersPeter>ping 192.168.39.19Pinging 192.168.39.19 with 32 bytes of data:Reply from 192.168.39.19: bytes=32 time=9ms TTL=64Reply from 192.168.39.19: bytes=32 time=4ms TTL=64Reply from 192.168.39.19: bytes=32 time=5ms TTL=64Reply from 192.168.39.19: bytes=32 time=3ms TTL=64Ping statistics for 192.168.39.19: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),Approximate round trip times in milli-seconds: Minimum = 3ms, Maximum = 9ms, Average = 5ms
But once attached to the N+1, even with the latest code still gives nothing, niente, nada, nichts, rien, niks .... as mentioned above ...
Ok Piwi. This one's for you. I pulled out my old Netduino Plus, reflashed to 4.2.0.1, and figured out the profile and debugged. First, in the wiring from post here I noticed that you do not have the power adapter plugged into the Boost module, but you do have a red wire plugged into J9-1. That looks to be right, but I always power the CC3000Boost through the power adapter. I have created a new "NetduinoPlusClassic_CC3000" interface profile. Before I created this profile, I got all 0xFF as a response because the CPU Pins are specific to each device. Also, I don't use the Netduino Hardware libraries because I want the end result to be usable on any .NET MF device without all the device specific libraries.
So, then it was still not working. I hooked up the logic analyzer and it looked like the CC3000 didn't like something because it was responding with strings of 0x04 repeated. So, then I added a 150 Ohm resistor in series to the SPI CLK D13 pin and everything worked. See picture below (ignore the attached probes).
I have attached the exact code I used, retargeted to .NET MF 4.2.
The red wire is (together with a blue one) connected to a seperate power supply -> 7805 -> LM1117. It maybe hard to see in the picture but it is the black box with the litle breadboard just under the green iPad that I had to borrow from my little daughter. She gets all the nice goodies and I have the play with this barebones MCUs ...
About your findings though, can't barely wait to try that one out when I get home from work. I've got a very simple logic analyser from http://www.ikalogic.com/scanakit/ as well, couldn't get it to work but I don't think I would 've spot the solution you made ...
Cool. I have the Scanalogic-2 myself. This is almost identical. I would recommend that you NOT use the V2 software. The original software is still better and the V2 is very "alpha" in my opinion. Also, when you setup the SPI decode part, use CPOL = 1 and CPHA = 0. Also, I usually trigger on the rising clock edge. If you combine breakpoints in visual studio with triggers in Scanastudio you can read any message you want.
I've checked the boost b4 and after, on stellaris stil doing fine but the n+ .... no response
I think I must consider I've got a broken n+
CC3000 Example ApplicationSending - Simple Link StartSetting Event MaskRequesting SP VersionThe thread '<No Name>' (0x3) has exited with code 0 (0x0).Resetting Connection before setting Policy. Setting Connection Policy.Attempting Connection to AK16-US
Changed the SPI clock, again no changes, same as above ....
Used my retargeted 4.2 of your yesterdays code, added a n+ profile changed the pins, the SPI clock to 100kHz and used the 150 resistor ....
CC3000 Example ApplicationSending - Simple Link StartSetting Event MaskConfiguring DHCPThe thread '<No Name>' (0x3) has exited with code 0 (0x0).Resetting Connection before setting Policy. Setting Connection Policy.Attempting Connection to AK16-US
Same kinda response ... none what so ever ...
Seems there is something not working optimal ...
If I want to use a cerbuinobee can I use the adhoc pin settings when using the arduino header pins i.e. the same as on the netduino headers ??
Just to rule out the netduino is the one causing this all, I know have two rule out all things not working in a ref setting. If ...
I've checked the boost b4 and after, on stellaris stil doing fine but the n+ .... no response
I think I must consider I've got a broken n+
If I want to use a cerbuinobee can I use the adhoc pin settings when using the arduino header pins i.e. the same as on the netduino headers ??
Just to rule out the netduino is the one causing this all, I know have two rule out all things not working in a ref setting. If ...
Why not try your logic analyzer to see what is going on?
Yes, the CerbuinoBee profile works, but for mine I had to use a 150 ohm resistor in series on MOSI and another on MISO. Very odd, but it did not work at all until I did that. Note: resistors should not be necessary at all for these SPI connections.
Well did some capturing MOSI and MISO are connected through a 150 Ohm resistor between cerbuino and cc3000boost. There is some signal but stops at 0.4ms ? And if I may believe the capture CS is always low ?
CH1=Blue=D13=Clock
CH2=Yellow=D12=MISO
CH3=Red=D11=MOSI
CH4=Green=D4=CS
Is this what is to expect ?
I have to look into this deeper, in the weekend and get some grip on the timing stuff .... should have gotten the 8 channel one ... need to see how the irq signal is inrelation to it, actually all signals .... any dox on how the lines should be ??
The Zip file I posted (#120) is the Saleae Logic LSR TiWi-SL(CC3000) Reference First Boot Trace for all lines. Go to the Saleae site and download their software and you should be able to view it.
@Valkyrie-MT:
I tried running "WifiExampleApp - 42 New" that you provided for piwi and I created a big problem. I first ran the code without looking at it and it completly trashed the Plus 2 firmware; stupid mistake on my part. I reloaded the firmware 4.2.2, set the network configuration and in main, changed to the Plus2 profile,
var wifi = new WifiAdapter("CC3000", InterfaceProfile.NetduinoPlus2_CC3000);
With my error fixed and then starting debug, the output shows,
[color=rgb(0,0,255);]CC3000 Example Application Sending - Simple Link Start[/color]
[color=rgb(0,0,255);]A first chance exception of type 'System.ArgumentOutOfRangeException' occurred in Networking.WifiAdapter.dll An unhandled exception of type 'System.ArgumentOutOfRangeException' occurred in Networking.WifiAdapter.dll
The error occurs in CC3000Driver.cs, private void Read() at pktReadPayload = new byte[payloadSize];[/color]
I then went back to your V2 software and ran it, but it hung. However, after power cycling the CC3000 , it re-ran successfully, obtained an IP address and ran to completion. I then returned to the above V3 software, re-ran it and it gave the same error. This time, after steping into the code and restarting from debug, it suddenly started working and gives the following output:
CC3000 Example ApplicationSending - Simple Link StartResponse Received -- Simple Link Start ConfirmedSetting Event MaskResponse Received -- Event Mask confirmedRequesting SP VersionResponse Received -- SP Version is 0.6.1.10Requesting Buffer SizeResponse Received -- Buffer Available: 6, Size: 56325Configuring DHCPResponse Received -- DHCP Configured. The thread '<No Name>' (0x4) has exited with code 0 (0x0).Resetting Connection before setting Policy. Response Received -- Connection Disconnect.Setting Connection Policy.Response Received -- Connection Policy SetAttempting Connection to tplinkWLAN Connection Established! Waiting for IP assignment from router... IP Address Acquired => 192.168.0.130Requesting Network Connection details...Woot! We are now connected to Wifi!Network Name: tplinkIP address: 192.168.0.130MacAddress: 08002801B2C1Gateway: 192.168.0.1DNS Server: 192.168.0.1Opening UDP SocketResponse Received -- Socket Command: 040110050000000000Socket ID is 0Sending Message on socket 0 to 192.168.0.130:51000Sending Message on socket 0 to 192.168.0.130:51000......
Restarting from the debug step sometimes works and somtimes gives this output which freezes at the last line,
[color=rgb(0,0,255);]CC3000 Example Application Sending - Simple Link Start Setting Event Mask Requesting SP Version Resetting Connection before setting Policy.[/color]
It seems the only way to get a successful deploy after a failed deploy is to power cycle both the Netduino and the CC3000 . Also, I started a Win UDP client listening on IPAddress.Any, port 5000 and changed your code to the broadcast address,
var ip = "192.168.0.255".ToBytes(); while (true) { s.Send(Encoding.UTF8.GetBytes("Hello from the CC3000!!!! Count: " + i++), ip, 5000);
However, I didn't receive anything. After a period of time output stops with the message, "Failed allocation for 17 blocks, 204 bytes". I guess this is the GC kicking in and blowing things up. After power cycling the Netduino and the CC3000, the output started up again. You are making great progress with your port. I need to start up Wire Shark to see where the UDP packets are going.
Well did some capturing MOSI and MISO are connected through a 150 Ohm resistor between cerbuino and cc3000boost. There is some signal but stops at 0.4ms ? And if I may believe the capture CS is always low ?
CH1=Blue=D13=Clock
CH2=Yellow=D12=MISO
CH3=Red=D11=MOSI
CH4=Green=D4=CS
Is this what is to expect ?
I have to look into this deeper, in the weekend and get some grip on the timing stuff .... should have gotten the 8 channel one ... need to see how the irq signal is inrelation to it, actually all signals .... any dox on how the lines should be ??
Actually, that looks good. The CLK definitely looks right. MOSI and MISO look like they are probably right. CS should only be low when there is communication happening, which is the case here. To see the byte values overlayed, after you have a trace like this, add a decoder for SPI. You'll have to configure it like this (colors and channels will differ for you):
I have attached a ScanaStudio file of the first command sent to the CC3000, simple Link Start.
I tried running "WifiExampleApp - 42 New" that you provided for piwi and I created a big problem. I first ran the code without looking at it and it completly trashed the Plus 2 firmware; stupid mistake on my part. I reloaded the firmware 4.2.2, set the network configuration and in main, changed to the Plus2 profile,
var wifi = new WifiAdapter("CC3000", InterfaceProfile.NetduinoPlus2_CC3000);
With my error fixed and then starting debug, the output shows,
[color=rgb(0,0,255);]CC3000 Example Application Sending - Simple Link Start[/color]
[color=rgb(0,0,255);]A first chance exception of type 'System.ArgumentOutOfRangeException' occurred in Networking.WifiAdapter.dll An unhandled exception of type 'System.ArgumentOutOfRangeException' occurred in Networking.WifiAdapter.dll
The error occurs in CC3000Driver.cs, private void Read() at pktReadPayload = new byte[payloadSize];[/color]
I then went back to your V2 software and ran it, but it hung. However, after power cycling the CC3000 , it re-ran successfully, obtained an IP address and ran to completion. I then returned to the above V3 software, re-ran it and it gave the same error. This time, after steping into the code and restarting from debug, it suddenly started working and gives the following output:
CC3000 Example ApplicationSending - Simple Link StartResponse Received -- Simple Link Start ConfirmedSetting Event MaskResponse Received -- Event Mask confirmedRequesting SP VersionResponse Received -- SP Version is 0.6.1.10Requesting Buffer SizeResponse Received -- Buffer Available: 6, Size: 56325Configuring DHCPResponse Received -- DHCP Configured. The thread '<No Name>' (0x4) has exited with code 0 (0x0).Resetting Connection before setting Policy. Response Received -- Connection Disconnect.Setting Connection Policy.Response Received -- Connection Policy SetAttempting Connection to tplinkWLAN Connection Established! Waiting for IP assignment from router... IP Address Acquired => 192.168.0.130Requesting Network Connection details...Woot! We are now connected to Wifi!Network Name: tplinkIP address: 192.168.0.130MacAddress: 08002801B2C1Gateway: 192.168.0.1DNS Server: 192.168.0.1Opening UDP SocketResponse Received -- Socket Command: 040110050000000000Socket ID is 0Sending Message on socket 0 to 192.168.0.130:51000Sending Message on socket 0 to 192.168.0.130:51000......
Restarting from the debug step sometimes works and somtimes gives this output which freezes at the last line,
[color=rgb(0,0,255);]CC3000 Example Application Sending - Simple Link Start Setting Event Mask Requesting SP Version Resetting Connection before setting Policy.[/color]
It seems the only way to get a successful deploy after a failed deploy is to power cycle both the Netduino and the CC3000 . Also, I started a Win UDP client listening on IPAddress.Any, port 5000 and changed your code to the broadcast address,
var ip = "192.168.0.255".ToBytes(); while (true) { s.Send(Encoding.UTF8.GetBytes("Hello from the CC3000!!!! Count: " + i++), ip, 5000);
However, I didn't receive anything. After a period of time output stops with the message, "Failed allocation for 17 blocks, 204 bytes". I guess this is the GC kicking in and blowing things up. After power cycling the Netduino and the CC3000, the output started up again. You are making great progress with your port. I need to start up Wire Shark to see where the UDP packets are going.
I have never seen it screw up the firmware, but I'll watch out for that.
Actually, you have it working there! That's all it does right now is connect and send a UDP packet. Once you have wireshark installed, I'm sure you'll see the packets. If you don't see packets, try turning off the private side of your windows firewall (or open the ports). Sometimes that can block the packets. You can also see a response in wireshark if you ping the cc3000.
The OutOfMemory error is what concerns me the most. That is the main test I am using, the repeating UDP send. If the memory leak can't be fixed, the driver is dead in the water. Having said that, my mip stack runs for weeks with all the same libraries, so I am hopeful we'll be able to figure this out. With respect to the remaining socket commands, those are probably trivial. The Socket Send command ended up being a single line and I expect the other commands to be similar. So, my only concern right now is fixing this leak. Once that is fixed, everything else will probably be done within a week or two.
One thing you noticed, is that if the CC3000 get bad commands, it has to be power cycled before it works again. The disappointing thing is that toggling the Power Enable pin does not seem to resolve this, which is VERY annoying. We really need a way to initialize the cc3000 with the connections we have.
One more thing, I have reproduced the Memory Leak on the NetduinoPlus, NetduinoPlus 2, and a CerbuinoBee with 4.2 and 4.3 firmware.
[/font]
