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?
Wow, that is just so cool, you are a wizard!
That was using the managed driver, yes?
Yes, this is all managed. Actually, I've written a really good SPI command constructor that has made implementation of most functions a single line of C#! So, at this point, I am spending most my time trying to figure out the command argument format from whatever I can find because I have not found a document that lays out all the SPI command arguments. I think TI expects everyone to just use their code as-is, but that is not useful for me.
At this point though, things are moving very quickly. I am very optimistic that it will be fully working (UDP and TCP) within a few weeks. And we'll end up with a managed wrapper that will be WAY easier to maintain and debug going forward. Also, I don't think there are any performance implications to doing managed in this case because the heavy lifting is being performed on the CC3000.
One more thing. My goal is to make this thing super easy to use, with sensible defaults that get things working quickly. I want it to be just a few lines to connect and send a message.
One thing that needs to be looked at is the SmartConfig stuff. Supposedly the default access point can be setup somehow from an iOS or Android device. I looked in the Google Play store, but I don't see any TI config app. I'm thinking that I might have to setup for Android development just to deploy the app, just so I can test that...
SmartConfig is rather nice. I got a couple of AirportExpress units and I could configure those from my iPhone without having them wired or even being on my wireless network. I'm not sure that is the exact same thing but I guess in essence.
Finding that iOS app was almost too good, sometimes you are either lucky or happen to think the same way as others did. Ruling the universe is no biggy, it's simply a matter of wanting for the right things to happen :-)
The header is a nice touch to sniff SPI. I did my first reflow today on one of the OSH Park boards. I regenerated some solder paste with new flux and it wasn't very succesful. I got some solder bridges on the 0402 parts and they are just too small to rework by hand so I am revising the board with 0805 and 1206. Of course, no way to tell if the CC3000 went ok. The problem without a stencil is that the pad doesn't want to grab a glob of paste from a toothpick. Hopefully, I can get this right before I run out of CC3000s.
@Valkyrie-MT: I tried the iPad App and the Java applet, but neither worked. But then of course, my CC3000 Boost is flakey. I am going to try to downgrade the firmware as hanzibal suggested. You are making wonderful progress. I just wish I could follow along with a working CC3000 module.
Actually, I am using a CC3000EM with the Netduino and the CC3000Boost with the Stellaris Launchpad. Having said that, I can tell you how to connect the CC3000Boost to the Netduino, because I have it wired up for the Logic Analyzer. This should work:
Using the Netduino SPI1 Profile.
SPI CLK == Netduino D13 => J9-Pin 7 on CC3000Boost => J4-Pin 12 on CC3000EM
SPI Data1 == Netduino D12 => J10-Pin 7 on CC3000Boost => J4-Pin 9 on CC3000EM
SPI Data2 == Netduino D11 => J10-Pin 6 on CC3000Boost => J4-Pin 11 on CC3000EM
SPI Chip Select == Netduino D4 => J10-Pin 3 on CC3000Boost => J4-Pin 8 on CC3000EM
Wifi Power Enable == Netduino D5 => J9-Pin 2 on CC3000Boost => J5-Pin 5 on CC3000EM
Interrupt == Netduino D6 => J10-Pin 2 on CC3000Boost => J4-Pin 10 on CC3000EM
For CC3000EM ONLY (Boost uses a dedicated Power adapter):
Ground => J4-Pin 7 and J5-Pin 10
3.3V DC Power (you may need an external supply because Netduino may not have enough current) => J5-Pin 8
CC3000EM jumpers: J3 should always have a jumper. J2 should always be user mode, jumper on 2-3
CC3000Boost jumpers: J2 should be 2-3, J13 should be 2-3, J15 should have a jumper
....
Hi Valkyrie-MT,
could you let me know the firmware version your working CC3000Boost has ?
I probably have the same 'unflavourable' behavior as Baxter. After updating to the latest firmware I am out of having a working model/reference
In addition, could you provide me with your code, I'm trying to get the CC3000 connected and working with an N+
could you let me know the firmware version your working CC3000Boost has ?
I probably have the same 'unflavourable' behavior as Baxter. After updating to the latest firmware I am out of having a working model/reference
In addition, could you provide me with your code, I'm trying to get the CC3000 connected and working with an N+
TIA
On my working CC3000 Boost, it start up with this "Example App:driver version 5.14.7.13"
That version string represents PALTFORM_VERSION, APPLICATION_VERSION, SPI_VERSION_NUMBER, DRIVER_VERSION_NUMBER
One thing... I have not updated the firmware on either of my devices, this despite the warnings from TI to make sure you are up to date. My reasons are:
1. If I use this device in a project that goes to production, I don't want to have to update the firmware for every device. So I want my code to work with older versions.
2. It will be a while before the patch programmer works from the managed code because it does not look easy and I may have one shot to get it right. That is just too risky for me... and it may be hard to get replacements because of limited supply...
3. If you can successfully load the new firmware, the managed code is almost certain to still work (probably better).
4. It is TI's responsibility to release a working product... if the thing needs a firmware update to function, IMO, TI should recall the thing or they can implement an automated firmware patcher that retrieves the patch from the internet automatically.
Having said that... I have implemented the NVRAM reader and the writer may be similar. But again, I won't even try that until I have everything else working because it could wreck the device and stop all progress.
Ok, I have another code drop for anyone interested. This one connects to your wifi. Once connected, you can ping the ip to confirm the connection. Note: it uses DHCP by default, static IP may work, but I have not tried it. If someone could test static IP, that would be great. If you do static, read the intellisense for the wifi.IPAddress property for details. Also, if someone can test WEP and unsecured to make sure those work, that would be great. Right now I am trying to get the Sockets coded up, but I am having trouble capturing a valid command exchange on my Stellaris because their example app is such a piece of garbage. Also, SmartConfig and NetworkScan are not coded yet. If someone wants to take a crack at those, that would be great.
Here is the end of the output from running the example:
Woot! We are now connected to Wifi!Network Name: linksysIP address: 192.168.1.77MacAddress: 080028010000Gateway: 192.168.1.254DNS Server: 192.168.1.254
On my working CC3000 Boost, it start up with this "Example App:driver version 5.14.7.13"
That version string represents PALTFORM_VERSION, APPLICATION_VERSION, SPI_VERSION_NUMBER, DRIVER_VERSION_NUMBER
One thing... I have not updated the firmware on either of my devices, this despite the warnings from TI to make sure you are up to date.
My CC3000 Boost module (updated to V1.11, latest) after a reset says:
Example App:driver version 2.13.7.12
It appears that updating moves the Driver_Version_Number back by one.
I went through the archived firmware, applied the patch programmer and still no connectivity. I inspected the board with a 60x microscope and L1 is unpopulated. The solder joints are very dull in appearance. Silkscreen is unreadable without a magnifing glass. In short, a very unprofessional build. I contacted TI for a replacement. The reference design specifies L1 as NL, but L2 is given as 2.2nH. I have no idea what the designation NL means.
The antenna coupling reference design apparently varies across the Boost/EM modules and is a source of confusion,
I have no way to tell, but I think my CC3000 Boost is not broadcating because the board is bad. All of this seems to be a royal screwup by TI.
They are working on the CC3000 over in the Parallax forum and a member is selling a breakout (Post #17). I took a chance and ordered his generic version,
In post #35, he is talking about a C# or VB Gui to interact with the module, but I assume that is a UART interface to the Spin driver. From the pictures of the breakout, note that he has L1 and L2 in the antenna coupling. I think the key to all of this is DON'T update as you suggest (and perhaps the antenna coupling is flawed).
Ok, I have another code drop for anyone interested. This one connects to your wifi. Once connected, you can ping the ip to confirm the connection. Note: it uses DHCP by default, static IP may work, but I have not tried it. If someone could test static IP, that would be great. If you do static, read the intellisense for the wifi.IPAddress property for details. Also, if someone can test WEP and unsecured to make sure those work, that would be great. Right now I am trying to get the Sockets coded up, but I am having trouble capturing a valid command exchange on my Stellaris because their example app is such a piece of garbage. Also, SmartConfig and NetworkScan are not coded yet. If someone wants to take a crack at those, that would be great.
Here is the end of the output from running the example:
Woot! We are now connected to Wifi!Network Name: linksysIP address: 192.168.1.77MacAddress: 080028010000Gateway: 192.168.1.254DNS Server: 192.168.1.254
Thx 4 the SW.
After some adding a profile for the N+ (I've still got the old one)
case InterfaceProfile.NetduinoPlus_CC3000: // Let's try this one wifi = new CC3000Driver((Cpu.Pin)SecretLabs.NETMF.Hardware.NetduinoPlus.Pins.GPIO_PIN_D6, (Cpu.Pin)SecretLabs.NETMF.Hardware.NetduinoPlus.Pins.GPIO_PIN_D4, (Cpu.Pin)SecretLabs.NETMF.Hardware.NetduinoPlus.Pins.GPIO_PIN_D5, SPI.SPI_module.SPI1); break;
there is some response but it seems it never gets handled ???
From the output window:
CC3000 Example Application
IRQ state = True
PowerUp enabled
Interrupt!
Instance thread procedure. Command = 16384
SPI Lock done!
IRQ state = False
Sending Command: 4000
Waiting for Response...
Instance thread procedure. Command = 8
SPI Lock done!
Sending Command: 0008
Waiting for Response...
Interrupt!
Instance thread procedure. Command = 519
SPI Lock done!
Instance thread procedure. Command = 2
After the "2" command it locks and waits forever ?
Activated/Added some debug.prints to clear the cloud but it hangs on the lock spi stmt when sending a command to the cc3000.
Any ideas ?
Addendum:
In the SWRU331 CC3000Boost manual there are two WL_SPI_CLK inputs specified one on J9-P7 and one on J10-P7 this is somewhat misleading.
In the SWRU331 CC3000Boost manual there are two WL_SPI_CLK inputs specified one on J9-P7 and one on J10-P7 this is somewhat misleading.
So you are really not getting any response... I am wondering if you have MOSI and MISO hooked up right. Because J10-P7 is not the SPI Clock, it should be MOSI or MISO... Yes, the spec sheet has a typo. If you look at the spec sheet for the CC3000 boost, it is missing either MOSI or MISO in the pinout I think. Let me look into it further to be sure.
What pins are MOSI and MISO connected to on the Netduino to CC3000 Boost?
Good News! I finally got a logic analyzer capture of a successful UDP socket. So, it should not take much longer before sockets are working to some extent!
// Manually specify a network
var ap = new AccessPoint() { Ssid = "tplink", Key = "", Security = WifiSecurityType.Open};
The TPLINK is a TL-WR702N pocket router configured as an access point on the LAN with an address,
192.168.0.254. The TPLINk appears as a client on my main router (ASUS RT-N56U). The SSID shows
up as "tplink" on my iPad as open security and I can access the Internet.
If I run your version 2 program, I get the following:
CC3000 Example Application
Sending Command: 4000
Waiting for Response...
Sending Command: 0008
Waiting for Response...
I tried with the SSID of my main router and WPA2 security, but I get the same response.
I am not sure what the response should be, but it is clear that my Boost has been rendered
I think we have got the same version of the beast, eh boost I mean, after my last try with msp430g2 the following was logged:
=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2013.07.14 05:08:30 =~=~=~=~=~=~=~=~=~=~=~=Example App:driver version 2.13.7.12010aExample App:driver version 2.13.7.120aDONE09DONE080000000000000000DONEExample App:driver version 2.13.7.1201
After using Valkyrie's code, I needed to re-activate some commented debug.prints to get some more feedback.
AND after checking multiple times, I still found that J9-P6 I used had to be J10-P6. Corrected that and I got some more feedback:
The thread '<No Name>' (0x2) has exited with code 0 (0x0).CC3000 Example ApplicationIRQ state = TruePowerUp enabledInstance thread procedure. Command = 16384SPI Lock done!Interrupt!IRQ state = FalseSending Command: 4000Waiting for Response...Instance thread procedure. Command = 8SPI Lock done!Sending Command: 0008Waiting for Response...Interrupt!Instance thread procedure. Command = 519SPI Lock done!Sending Command: 0207Waiting for Response...Interrupt!Sending Command: 400BWaiting for Response...Interrupt!Instance thread procedure. Command = 8193SPI Lock done!Sending Command: 2001Waiting for Response...Interrupt!The thread '<No Name>' (0x5) has exited with code 0 (0x0).Instance thread procedure. Command = 2SPI Lock done!Sending Command: 0002Waiting for Response...Interrupt!Sending Command: 0004Waiting for Response...Interrupt!Sleeping for 8sSending Connect...!Instance thread procedure. Command = 1SPI Lock done!Interrupt!Sending Command: 0001Waiting for Response...
it still waits forever but know a little bit later in the process ....
so there is still a faint light at the back of my tunnel .....
as they say here -> Die Hoffnung stirbt zu letzt !
some progress after all even with the troublesome version with the boost's firmware !!!
@Valkyrie, still no response handling feedback messages ???? (read your reply a little later after posting this, thanks for the pin out warning anyway that was a .... )
Yikes. Ok, since everyone else is using the boost with Netduino, I'll move my cc3000boost over to the NetduinoPlus2 to see what is going on. But, I won't be able to do it until this evening.
Also, when it works, the cc3000 should respond with an event for each command. In the output it should look like this:
CC3000 Example ApplicationSending Command: 4000Waiting for Response...New Event: OpCode: 4000Handling Response for OpCode: 4000Response Received -- Simple Link Start ConfirmedSending Command: 0008Waiting for Response...New Event: OpCode: 0008Handling Response for OpCode: 0008Response Received -- Event Mask confirmedSending Command: 0207Waiting for Response...New Event: OpCode: 0207Handling Response for OpCode: 0207
Yep, that's what is worrying me the most .... the Read() gets not executed, now the reason why is the big question ... thx for trying out the boost and joining in this quest ... tbc ...
"On my working CC3000 Boost, it start up with this
"Example App:driver version 5.14.7.13"
"That version string represents PALTFORM_VERSION, APPLICATION_VERSION, SPI_VERSION_NUMBER, DRIVER_VERSION_NUMBER"
Piwi and baxter Boost:
======================
Example App:driver version 2.13.7.12
The driver version is different, SPI is the same. We are talking apples and oranges here. Valkyrie-MT has a working CC3000 boost and we do not because of the flawed update. I used the patch programmer and the companion binary driver/firmware update for the MSP430G2553. I think this loaded the CC3000 with firmware appropriate to the Basic WiFi application for the MSP430G2553 which rendered the CC3000 useless for general applications. The CC3000 has been proven to run on the Micro Framework (Valkyrie-MT), Arduino and Propeller Spin platforms. I tried the Arduino code with a Sparkfun Arduino Pro Micro (3.3V) and it would't run. All of the running implementations used a "FACTORY CC3000", not an updated C3000. I have not been able to find any way on the TI site to restore the CC3000 to factory settings so I am just going to buy another one and not touch it with updating.
Well, that is indeed good news ...
We now know that using the TI Patch Programmer and the associated driver/firmware binaries will render the CC3000 Boost unusable for general applications.
Well, I hooked up the CC3000 boost and it just worked. I followed Baxter's pinout table. Here is the image:
Very good news, I already ordered a new boost at the TI shop.
After I get it working, I'll try and implement nvmem_read_sp_version(unsigned char* patchVer) to get the EEPROM service pack version and match it to the release package, may be I can apply the proper release package to get the first boost in a working state again ....
Couldn't get the version since the function is not avail on G2 because of the Tiny Driver usage.
Trying to figure out the Socket Send command, but I can't figure out what the end is... the following is my breakdown of a valid working command sent from the Stellaris Launchpad using the sample application.
Socket Command:
Socket Send To 192.168.1.84, port 0xC738, message "12345"
01 00 33 00 00 - SPI Header, HCI Length of 0x33 or 51 decimal
02 - Write Type
83 18 - opcode 0x1883 (wierd, expected 0x1083)
2D 00 - Payload Length? 45 decimal
00 00 00 00 - Socket ID of 0
14 00 00 00 - Arg size = SOCKET_SENDTO_PARAMS_LEN(24) - Length of Socket ID (4) = 20 = 0x14; Note: SEND (as opposed to SENDTO) uses HCI_CMND_SEND_ARG_LENGTH(16) - Length of SocketID (4)
05 00 00 00 - Message length
00 00 00 00 - flags (all 0s)
0D 00 00 00 - SENDTO Only - Address offset? Calculated from Message Length(5) + (Size of Message Length(4) x 2) = 5 + (4 x 2) = 13 = 0x0D
08 00 00 00 - SENDTO Only - Address Length (always 8? what about ipv6? eek!)
31 32 33 34 35 - THE DATA/MESSAGE (ASCII for "12345")
02 00 C7 38 - 0x0002 is family AF_INET (always and type is short), and 0xC738 is the port (SENDTO Only?)
C0 A8 01 54 - Destination IP 192.168.1.84 (SENDTO Only?)
[color=#ff0000;]F9 FF FF FF - ??[/color]
[color=#ff0000;]CB 12 00 20 - ??[/color]
00 - Padding byte
Any ideas?
Update: I decided to repost this in the TI forum...
I followed Baxter's pinout table. Here is the image: 
