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?
This probably does not belong in this forum but since you're using one as a model for a working CC3000MOD I take my changes here after half a day search for a solution.
Got a stellaris EK-LM4F120XL, connected it to my PC and installed the drivers, all looks fine in my device manager of win7-64 but now it comes when I start compiling/building the basic wi-fi apps, I take the host driver as a first one and first what is noted is all red crosses for all project parts (host driver, spi driver, terminal and basic wifi). When building the host driver f.e. it runs into a build error which I can't resolve ... could you give a tip on what I do wrong here.
The build output:
**** Clean-only build of configuration Debug for project CC3000HostDriver ****"C:ticcsv5utilsbingmake" -k clean DEL /F "CC3000HostDriver.lib"Could Not Find C:tiCC3000SDKCC3000 SDKLM4F120H5QRBasic WiFi ApplicationBasic WiFi SourceBasic WiFi Application CCSCC3000HostDriverDebugCC3000HostDriver.libDEL /F "cc3000_common.pp" "evnt_handler.pp" "hci.pp" "netapp.pp" "nvmem.pp" "security.pp" "socket.pp" "wlan.pp" Could Not Find C:tiCC3000SDKCC3000 SDKLM4F120H5QRBasic WiFi ApplicationBasic WiFi SourceBasic WiFi Application CCSCC3000HostDriverDebugcc3000_common.ppDEL /F "cc3000_common.obj" "evnt_handler.obj" "hci.obj" "netapp.obj" "nvmem.obj" "security.obj" "socket.obj" "wlan.obj" Could Not Find C:tiCC3000SDKCC3000 SDKLM4F120H5QRBasic WiFi ApplicationBasic WiFi SourceBasic WiFi Application CCSCC3000HostDriverDebugcc3000_common.obj'Finished clean'' '**** Build Finished ****Buildfile generation error occurred..This project was created for a device that is not currently recognized: Cortex M.LM4F120H5QR. Please install the device descriptor, or migrate the project to the closest match from the supported devices by adjusting project properties.Build stopped..
The stellaris launchpad is running just smoothly with the provided RGB LED cycle demo, buttons do work as expected.
This probably does not belong in this forum but since you're using one as a model for a working CC3000MOD I take my changes here after half a day search for a solution.
Got a stellaris EK-LM4F120XL...
That is exactly what I have. First, I followed these instructions: http://processors.wi...laris_Launchpad Following the instructions for Code Composer Studio 5.4.0.00091 (90-day trial). BUT, Make sure you install the Stellarisware also, which has critical required libraries (http://www.ti.com/tool/sw-ek-lm4f120xl). After that, there were a few small compilation errors because of some compile time options I could never find, so I just commented out the offending line
in the end it was the missing compiler for the stellaris .... had to incrementally install ccs again ... won't happen again..I hope...
after some compiler version settings and indeed commenting out some grlib.h statements I recon it won't be used. Had some path to change for spi.c to find it kind a got lost, the 3 lib projects just compiled ok ... cool !!
.. but for the basic wifi project I stumbled, in the end, over a malfunctioning target_config.ccxml, just deleted it, added a new one and the project builded and deployed to the stellaris .... since the RBG LED stopped with illuminating I guess there is some new SW running...
..debugging the stellaris with the CC3000 hangs on the wlan_init() line in the initdriver() routine ????
... I guess the first CC3000 is kind of gone ... no terminal messages anymore ... well let's wait for the next one ...
Hooking it up and running Valkyrie-MT version 2 software gives the following,
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: 0207Handling Response for 0207SP Version is 0.6.1.10.2Sending Command: 400BWaiting for Response...New Event: OpCode: 400BHandling Response for 400BBuffer Size is 115082496Sending Command: 2001Waiting for Response...New Event: OpCode: 2001Handling Response for 2001The thread '<No Name>' (0x4) has exited with code 0 (0x0).Sending Command: 0002Waiting for Response...New Event: OpCode: 0002Handling Response for 0002Sending Command: 0004Waiting for Response...New Event: OpCode: 0004Handling Response for 0004Sleeping for 8sSending Connect...!Sending Command: 0001Waiting for Response...
However, I don't know what I am seeing here. The CC3000 doesn't show up as a client in my router. I don't know the IP address to ping it. About the only thing I know is that the code stops at this line in main,
while (true) System.Threading.Thread.Sleep(5);
and there is no output from, wifi_Connected(WifiAdapter wifiAdapter). Perhaps the firewall is blocking something. Valkyrie-MT maybe we could establish a baseline case.
@Baxter, except for the handling of responses my first generation netduino plus comes with all the same commands and stops at the point in code as you reported.
I'm trying the arduino way of things ... until my new boost comes in .... I've got a feeling though that the netduino can't handle the timing adequately. Are you running from a NP2 or a NP1 ?
Sending Connect...!
Sending Command: 0001
Waiting for Response...
Wow, that's great! It's totally communicating and responding appropriately. Now, that 0001 command is the actual connect command where it uses the provided SSID and password to connect. The lack of a response indicates that it is not connecting.
Try this... in the cc3000driver.cs file, there is a Connect method. In this method, there is a SetConnectionPolicy(false, false, false). This sets up the rules for which access points it should connect to. I would try disabling security on your wifi, then change the parameters to (true, false, false). This will allow it to connect to Open access points. Once it connects, it will report the IP in the output window.
Or turn your security on and change to SetConnectionPolicy(false, false, true); Although, I am less sure about this.
Nice find piwi ... A direct competitor for the Spark Core on Kickstart (or maybe they are reselling it). Let's see if it can maintain the $39 price point. I am usinng a Netduino Plus 2. Valkyrie-MT proved that his code runs on a Plus 2. Suspecting that my router was somehow rejecting the CC3000, I changed this line of code to an open access point,
var ap = new AccessPoint() { Ssid = "tplink", Key = "", Security = WifiSecurityType.Open };
and now it [color=rgb(255,0,0);]SUCCESSFULLY [/color]connects
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: 0207Handling Response for 0207SP Version is 0.6.1.10.2Sending Command: 400BWaiting for Response...New Event: OpCode: 400BHandling Response for 400BBuffer Size is 115082496Sending Command: 2001Waiting for Response...New Event: OpCode: 2001Handling Response for 2001The thread '<No Name>' (0x4) has exited with code 0 (0x0).Sending Command: 0002Waiting for Response...New Event: OpCode: 0002Handling Response for 0002Sending Command: 0004Waiting for Response...New Event: OpCode: 0004Handling Response for 0004Sleeping for 8sSending Connect...!Sending Command: 0001Waiting for Response...New Event: OpCode: 0001Handling Response for 0001New Event: OpCode: 8001Handling Response for 8001WLAN Connection! New Event: OpCode: 8010Handling Response for 8010IP Address Acquired => 192.168.0.130Sending Command: 2005Waiting for Response...New Event: OpCode: 2005Handling Response for 2005Woot! We are now connected to Wifi!Network Name: tplinkIP address: 192.168.0.130MacAddress: 08002801B2C1Gateway: 192.168.0.1DNS Server: 192.168.0.1
The TP-Link is TL-WR702N pocket router configured as an access point with an IP address of 192.168.0.254 and a SSID of "tplink". Its gateway address is 192.168.0.1 which is the address of the main router. The TP-Link shows up as a client in the main router and and by wireless SSID in my iPad. It is a mystery why the main router would not accept the CC3000 as a client. It may have something to do with the security key. I am using WPA2-Personal/AES and perhaps the CC3000 is using something different.
The CC3000 is now showing up as a client in the main router with MAC, 08:00:28:01:B2:C1 and IP address, 192.168.0.130. It is curious that the CC3000 has taken the name "tplink" because the TP-Link access point also has the SSID "tplink". I can ping the CC3000 and it is also listed in the arp table,
C:UsersbebDesktop>arp -a
Interface: 192.168.0.106 --- 0xb Internet Address Physical Address Type 192.168.0.130 08-00-28-01-b2-c1 dynamic
edit:
Wow, that's great! It's totally communicating and responding appropriately. Now, that 0001 command is the actual connect command where it uses the provided SSID and password to connect. The lack of a response indicates that it is not connecting.
Try this... in the cc3000driver.cs file, there is a Connect method. In this method, there is a SetConnectionPolicy(false, false, false). This sets up the rules for which access points it should connect to. I would try disabling security on your wifi, then change the parameters to (true, false, false). This will allow it to connect to Open access points. Once it connects, it will report the IP in the output window.
Or turn your security on and change to SetConnectionPolicy(false, false, true); Although, I am less sure about this.
I didn't do any of this. I am going to try my CC3000 Boost and maybe it will also work.
I discovered a memory leak in the driver . After 960 UDP messages it runs out of memory. I spent all evening on this, but I believe I have it fixed. The bad news is that the driver is somewhat broken now as I tore everything apart to find the leak. So, it will be a bit longer before the receive is done...
It is more breadboard friendly than the Boost with a 0.1" male header (not 2mm female). It has 6 pins plus 3.3V and Gnd. He also demonstrated that it works. I also forgot to mention that I dasabled DHCP on the TP-Link access point so that the main router would give the IP address to the CC3000 and thereby put it on the network.
Hi guys, I'm back from my holiday now and was looking forward to work on the PCB that I set out to do in Eagle, but...
While I was gone, my commercial IO board launched so I need to attend to that in improving the software, writing docs, creating sample projects and so on. This means I won't have time to work on the PCB for a good while.
I'll be happy to see someone else pick it up instead and since I didn't get farther than removing the mosfets, there's little point in me posting the Eagle files.
..... well finally there is some positive news for and from me !!!
Since my second boost did not work either, I got me an FRAM board (FR5739) and the CC3000EM, downloaded the sensor app to it, did some smartconfig from an ipad to an open AP. Did not work, but after stopping the ipad app it began to start to burn the leds 2, then 3 and finally number 4 .... aha ... it does work ... without any patches made. Now launching the PC sensor app turned into a nice window where the acceleration, temp and vcc were displayed just nicely and tilting the board was reflected in the planet as well, that looked quit cool compared to the bummers I had with the boost stuff.
The FR5739 board with six leds burning communicating over sockets against
Cool sensor app.
Now the boost with the stellaris keeps freezing in the smartconfig section after issueing command 01 the led start with blinking red and stays there, no matter what smartconfig app I run from (tried pc and ios) stays blinking and no change in my ap's dhcp clients.
Hyperterminal is reporting 5.14.7.13 ....
Next will be to connect the CC3000EM to the netduino and get it to work as well .... at least now we've got a working model with sockets ...
I couldn't believe my eyes ... both the boosts I have do seem to work just fine ...
The following I did:
Get the basic wifi apps downloaded, start a terminal (I used hyper terminal), perform a reset to see the application string with the version, 5.14.7.13 by me. Type command 01 no answer on the terminal but after a reset the red led should start blinking. Directly after the reset and the welcome message I did a simple command 027AK16-US0 to issue a 02 command with my details and voila the red blinking led turns in a permanent on green led and the answer on the terminal screen is a valid IP address. Tried one... succeeded and changed the one with the first boost I got did do exactly the same and voia got a new ip address.
Example App:driver version 5.14.7.1301Example App:driver version 5.14.7.13027AK16-US0DONEIP:192.168.139.101
and the client list ... now it seems I've got three to play with ....
I've got to hook up one to see how n+ is doing but first some sweet dreams ... it's the middle of the n8 here ...
That is good news. I think the key here is that you are using the Fram board and it has enough resources for the CC3000, but the MSP430G2553 is marginal. In all my searching, I could not find any issues about connecting with the FRAM board. I received a new free CC3000 Boost from Ti under warranty after complaining that my first one was defective. The one I am using now is the Parallax I cited earlier and it is working just fine. I will try my new Boost with the N +2.
man this is really kicking my brains out ... if any left ...
I've got one boost board on the stellaris, does not matter which one both the boost boards just are pingable only need to do a 027AK16-US0 in the terminal and the network is working (at least the ping from my laptop. I've got the fram board (with cc3000em) on another usb port and that's pingable as well. Different ip addresses, checked that !!!
Now it comes just connected the third boost board, previously checked and pinged on the stellaris, wired it to my N+, run the program and still no response and hanging on the 0001 command. Does raise interrupts but does not handle them .... ????? connected the boost back on the stellaris, performed a 02 command in the terminal to connect to the network, just working fine .... I'm suspicious about the N+ being able to handle this stuff, I mean if the same code is working at Valkyrie-MT's on a boost module why not mine the only difference I can spot at the moment is I'm using N+ and you guys are using a N+2 ... rather strange if you ask me ... maybe something stupid ...
CC3000 Example ApplicationCC3000Driver: 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>' (0x4) has exited with code 0 (0x0).Init: Completed = TrueSending Command: 0002Waiting for Response...Interrupt!Sending Command: 0004Waiting for Response...Interrupt!Sending Command: 0001Interrupt!Waiting for Response...
I feel your pain. I have used three different platforms (Arduino pro Micro 3.3v, MSP430G2553, and Netduino plus 2) with my original boost and none worked. I first used the Boost with the MSP430. I think this is the key; when a CC3000 module is used with a TI platform and a TI program, the CC3000 EEPROM is somehow being programmed to associate with a TI application. Maybe it's relative to SPI or an interrupt. A CC3000 that is untouched by TI software seems to work ok.
Your wiring looks ok. I am using a separate 3.3V power supply for the CC3000 and one GND from the Netduino to the power supply GND. All other connections are directly, Netduino <--> CC3000. I have read that it is very important to supply at least 300mA to the CC3000 and I am not certain that a Netduino can do this directly. I haven't tried my new boost with netduino yet.
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.
While browsing the LSR TiWi-SL(CC3000) forum I came across the attached reference First Boot Saleae Logic trace. LSR responses relating to problems of first boot are referred to this file as a successful boot sequence.
. After 960 UDP messages it runs out of memory. I spent all evening on this, but I believe I have it fixed. The bad news is that the driver is somewhat broken now as I tore everything apart to find the leak. So, it will be a bit longer before the receive is done... 
