Netduino home hardware projects downloads community

Jump to content


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.
Photo

Spark Core (TI CC3000) Porting for Super WiFI Mini?

CW2 Ziggurat29

  • Please log in to reply
256 replies to this topic

#21 piwi

piwi

    Advanced Member

  • Members
  • PipPipPip
  • 114 posts
  • LocationGermany

Posted 29 June 2013 - 04:57 PM

Hi Guys,

 

got some simply question, I hope ...

 

recently received my launchpad+cc3000 build it all to specs as far as I know, at least all compiled, build, etc...

 

even the leds are lighting to indicate wlan is up ... the apps should be connectable through terminal where certain commands can be entered to configure the darn thing but this seems not to be possible ... although my system (W7-64) does report the presence of the beaty on COM4 no connection can be made ..... i'm pulling my hair out and that already during half the day so there is not much left ...

 

b4 I go bold, i'd rather ask you guys if you have any tips, trick, whatsoever, anything to the matter is most welcome ....

 

TIA

 

Posted Image



#22 piwi

piwi

    Advanced Member

  • Members
  • PipPipPip
  • 114 posts
  • LocationGermany

Posted 29 June 2013 - 09:32 PM

Yippie ....

 

at least there is some feedback, it seems the run ...

 

now for the next step ... getting it in my AP ... secured by WPA2/TKIP+AES/MAC-Filter

 

Reply in puty -> [font="'courier new', courier, monospace;"]Example App:driver version 2.13.7.12[/font]
 



#23 baxter

baxter

    Advanced Member

  • Members
  • PipPipPip
  • 415 posts

Posted 29 June 2013 - 10:37 PM

Well that is good news. Tell how you did it. I have been trying to get this combination running for over a week. I posted on the E2E forum, but no answers.

http://e2e.ti.com/su...1/t/274708.aspx

Did you use the latest SDK and update the driver and firmware with the patch programmer?  I followed this document,

http://processors.wi...n_for_Launchpad

 

I suspect that the new SDK has somehow broken the software for the Launchpad MSP430G2553. Also, are the red and green LEDs on, I can't tell from your photo.



#24 piwi

piwi

    Advanced Member

  • Members
  • PipPipPip
  • 114 posts
  • LocationGermany

Posted 29 June 2013 - 11:34 PM

Ha, got the mac as well.

 

Tweeked the code to display the decimal numbers but I know how to type calc. Used the nvmem_get_mac_address function ... checked the MAC (at least the first three numbers and that came back as TI as a company so I guess I'm not that far from right (as in not wrong))

 

@baxter: Just followed the SDK 1.11 update with the two step flasher for the MSP430G2553.

http://processors.wi...Wi-Fi_Downloads

 

and followed these instructions

http://processors.wi...n_for_Launchpad

 

and yes both green and reds are on, strangely enough the board reacts now on reset as well, got some time it did not do that ... ???

 

oh, by the way, did you change the jumpers to use hw uart ?

 

I'm using the CCS 5.4 as an editor ... that's getting used to though ... after many years using vs ...

 

and at some point my whole AP went bananas, couldn't get it to secure anymore, had to update the firmware ... finally succeeded ... had to reboot my pc as well and thought to give the terminal session one more go ... and it worked all of a sudden ... with and without the CCS ... man I do mis that online debugging in VS, stepping forward and backwards, looking at almost any time at any var, etc. ... 

 

got putty to display only can't enter any commands and if using hyperterminal I get the messages as well but at entering commands the launchpad/wifi insist on invalid command response ...

 

have to go it's 1.30 am .... need some sleep ... sd ...



#25 baxter

baxter

    Advanced Member

  • Members
  • PipPipPip
  • 415 posts

Posted 30 June 2013 - 01:47 AM

@piwi: Thanks for the information. We basically are in sync and followed the same steps (serial is hardware jumpered). The thing I didn't do is reboot my PC. I did so, brought up a terminal (9600 baud,8n1) and connected to the MSP430 Application UART COM port; and no response. I then repeatedly pressed the reset button on the MSP430 and got the following response,

 

--- > Example App:driver version 2.13.7.12

 

I then sent a "1" and got,

---> Illegal commandDONE

 

In my router DHCP Client list, I have an entry only identified by a MAC address and IP address that I don't recognize,  80:1F:02:9D:B4:EC. The organizational unique identifier for TI is 08:00:28 so with my attempts at First Configuration something may have gotten through. In any event, the path forward is now clear.

 

Many thanks for the reboot tip.

 

EDIT: It appears that reset puts the MSP430 into command mode and it sends the version info. and if nothing is sent back within a short time interval it goes back to waiting for a reset. The command that it is waiting for is a First Configuration command that is prefixed with TTT... I need to look it up again.



#26 ziggurat29

ziggurat29

    Advanced Member

  • Members
  • PipPipPip
  • 244 posts

Posted 30 June 2013 - 04:01 AM

I think I just fried mine  :mellow: Seems pwr_en is ground and it's supposed to be an input...

 

your radio or host board?  I've flicked pwr_en high and low just fine, so maybe double check the wiring, maybe it's OK!

 

OMG I am not sure if I have seen a more poorly documented device.  Does TI actually make this, or resell it?

 

Sounds like you guys with the TI eval boards are moving ahead with the 'stock' code to make it do something interesting.  I'm going to continue to plow through the hard and stony soil of non-docs in hopes of finding some rich volcanic earth beneath.  Or maybe only bedrock....



#27 baxter

baxter

    Advanced Member

  • Members
  • PipPipPip
  • 415 posts

Posted 30 June 2013 - 05:01 AM

@ziggurat29: Maybe if you took a look at the GitHub Arduino C++ code link in Post #19 it might bring some coherence. They have it running on Uno, Teensy 3.0 and a Sparkfun Pro Micro.

 

@hanzibal: My sympathies ... I killed a Wiz820Io by supplying 5V power to it by accident.



#28 piwi

piwi

    Advanced Member

  • Members
  • PipPipPip
  • 114 posts
  • LocationGermany

Posted 30 June 2013 - 10:07 AM

well, it still seems to work.

 

displays now startup message with now the MAC address too. Starting with 08:00:28.

 

when typing command 02 immediately after the msg brings me a Done but 01 (smart config) and several others do not return at all ???

 

One step further :

 

Example App:driver version 2.13.7.12 MAC 08:00:28:56:D3:81 01

Smart config DONE

DONE IP:255.255.255.255

 

Now why is this IP the way it is ?

 

And the java applet and the apple apps do run into infinity ... if they could no response, any ideas ?



#29 baxter

baxter

    Advanced Member

  • Members
  • PipPipPip
  • 415 posts

Posted 30 June 2013 - 08:37 PM

@piwi I picked the following off the TI E2E forum: ==================================== Quote Hello luca, You can select to force a static IP or allow the router's DHCP to assign one, base on your use of the 08 command.  After the smart config, the device should be connected to the AP, so you must setup how it gets its IP before the smart config.  If you chose to force a static IP, you must make sure that this IP is available and adhere's to the AP's numbering convetion.  The steps for each configuration are as follow:   Static IP:  "0a" to clear previous, "09" disconnects, "08[octets_of_ip address][octets_Of_Gateway]", reset board, "01" smart config   DHCP IP: "0a" to clear previous, "09" disconnects,"0800000000[octets_Of_Gateway]", reset board, "01" smart config

======================End Quote

 

The available commands are toward the bottom of this page, http://processors.wi...tion_for_MSP430

 

i tried,

Static IP = C0A8002D (192.168.0.45)

Gateway = C0A80001 (192.168.0.1)

Command sequence: (Static) -------------------------- 0a <-- done 09 <-- done 08c0c8002dc0a80001 <-- done Push reset button 01 <-- Hangs, Tried iPad App, Java App (both hang)

Ping 192.168.0.45 (no luck)

 

I am not going to waste any more time on this. I think the MSP430G2553 too limited in resources to reveal the full capabilities of "Smart-Link". The MSP FRAM launchPad would probably work as advertised.  I am moving on to CC3000 with Arduino while our resident porting expert, ziggurat29,  struggles with the micro Framework port.



#30 hanzibal

hanzibal

    Advanced Member

  • Members
  • PipPipPip
  • 1287 posts
  • LocationSweden

Posted 01 July 2013 - 07:55 AM

your radio or host board?  I've flicked pwr_en high and low just fine, so maybe double check the wiring, maybe it's OK!

The radio, when trying to set the pwr_en input pin high by applying 3.3V to it, it seems to result in a short circuit.



#31 ziggurat29

ziggurat29

    Advanced Member

  • Members
  • PipPipPip
  • 244 posts

Posted 01 July 2013 - 02:06 PM

The radio, when trying to set the pwr_en input pin high by applying 3.3V to it, it seems to result in a short circuit.

blick.  and how weird, because that pin is indeed a 3.3v digital input.  Maybe if you wave a dead chicken over it, and say a prayer, it will come back?  Occasionally incense helps, also.

 

Then maybe that's why mine won't speak back to me?  Now I must break out the oscope (and figure out a way to hook to my crazy modded pin header).  (now I wish I had a logic analyzer!)  (maybe this will finally make me use that bus pirate I got ages ago)

 

Unrelated, but I got a 'product obsolete' notice on this eval board (296-30564-ND), with no replacement suggestion.  Not the module itself mind you but the board.  Don't know what that means or if it is news you can use....



#32 hanzibal

hanzibal

    Advanced Member

  • Members
  • PipPipPip
  • 1287 posts
  • LocationSweden

Posted 01 July 2013 - 03:16 PM

I did try the dead chicken routine but nothing in particular happened (other than our old parrot arising from the dead which was kind of freaky btw).

 

I too have a Bus Pirate laying somewhere, still untouched since I use the scope instead, it works pretty ok for me.

 

Vdd is 3V3 but I might have accidentally applied 5V logic at some point effectively killing the pin (I'm using my own USB explorer board, not a Netduino).

 

Btw, are you also using the older TiWi-SL eval board from LS Research?

Attached File  TiWi-SL.jpg   45.04KB   4 downloads

I soldered short wires onto pins 7 - 12 on both the J4 and J5 headers (and left all other pins unused), then stuck it down a regular breadboard.

 

 

 



#33 ziggurat29

ziggurat29

    Advanced Member

  • Members
  • PipPipPip
  • 244 posts

Posted 01 July 2013 - 03:40 PM

I did try the dead chicken routine but nothing in particular happened (other than our old parrot arising from the dead which was kind of freaky btw).

 

I too have a Bus Pirate laying somewhere, still untouched since I use the scope instead, it works pretty ok for me.

 

Vdd is 3V3 but I might have accidentally applied 5V logic at some point effectively killing the pin (I'm using my own USB explorer board, not a Netduino).

 

Btw, are you also using the older TiWi-SL eval board from LS Research?

Posted ImageTiWi-SL.jpg

I soldered short wires onto pins 7 - 12 on both the J4 and J5 headers (and left all other pins unused), then stuck it down a regular breadboard.

 

well, at least you can have the chicken for dinner.  and zombie parrots are quite the thing I hear, but careful of the bite.

 

I did read that the boards are very un 5v friendly, so you may indeed be hosed.

 

Yes, that is the board I am using.  Didn't know there was a newer one, and digikey didn't have any advice, but it was kinda spendy anyway.

I probably should have taking your pin route (on the breadboard); I make a 'conventional' upward facing header that I could use the ever-popular-and-formerly-scorned-by-myself-but-now-I-am-a-convert jumper wires with female ends, so I could simply plug them into my NP2, but then I can't connect probes at the same time, so I had to solder additional free leads to probe with.  Would have been better your way on a breadboard!

 

Anyway, I'll give it just a couple more hours, then I have to go back to my regularly scheduled work for the rest of the week, alas...



#34 ziggurat29

ziggurat29

    Advanced Member

  • Members
  • PipPipPip
  • 244 posts

Posted 01 July 2013 - 04:57 PM

Well, stop your grinnin' and drop your linen, it responded back to my kookily-crafted initial packet in a cogent way.  Now I will have to Shake a Leg, haha.



#35 Valkyrie-MT

Valkyrie-MT

    Advanced Member

  • Members
  • PipPipPip
  • 315 posts
  • LocationIndiana, USA

Posted 01 July 2013 - 05:36 PM

I'm nervous about hooking the CC3000 up.  Can someone (whom has it communicating) post a fritzing diagram for connecting the SPI to any Netduino?  The fellow who fixed up the Arduino library suggested using a voltage divider is necessary, but some folks say it's not if the Arduino is 3.3v.  I figure the same would apply to a Netduino?  



#36 baxter

baxter

    Advanced Member

  • Members
  • PipPipPip
  • 415 posts

Posted 01 July 2013 - 07:27 PM

@Valkyrie-MT:

I am assuming that you can hook it directly to the Netduino. The schematic for the breakout board I am putting together is in the Eagle zip file here

http://www.centerblack.com/

3.3V VCC needs to supply at least 300mA. I am waiting on a Sparkfun Arduino Pro Micro (3.3V) to follow that development while ziggurat29 proceeds with his Netduino port.

Attached Files



#37 Valkyrie-MT

Valkyrie-MT

    Advanced Member

  • Members
  • PipPipPip
  • 315 posts
  • LocationIndiana, USA

Posted 02 July 2013 - 01:22 AM

Well, stop your grinnin' and drop your linen, it responded back to my kookily-crafted initial packet in a cogent way.  Now I will have to Shake a Leg, haha.

 

Ziggurat29, You have to let me help you.  I was just gearing up to do a .NET MF port myself.  I have an CC3000EM and I was about to setup an Arduino and capture the SPI traffic on my logic analyzer.  Then I was planning on porting/rewriting the framework in C# for .NET MF.  Can you post a zip of what you have so far?  Being able to start with (at least) the basic SPI stuff working would be very helpful.  



#38 ziggurat29

ziggurat29

    Advanced Member

  • Members
  • PipPipPip
  • 244 posts

Posted 02 July 2013 - 01:24 PM

Ziggurat29, You have to let me help you.  I was just gearing up to do a .NET MF port myself.  I have an CC3000EM and I was about to setup an Arduino and ...

 

Sure, why not?

My plans (up to this point) were:

*  prove hardware interface (done)

*  prove SPI communications (done, I believe)

*  first make a managed code 'driver'

*  then make a native code integration with the firmware

So, two 'products' come out, one managed, and one native.  I want to do the managed version first because I believe it will be easier to experiment and debug in that context, and should cement my understanding of the part (the documentation is stunningly poor), and because I think it is a useful end in it's own right.  Once I have a thorough understanding of the device, then for the firmware it's a separate exercise to plan the integration, ostensibly replacing lwip (or maybe they can coexist, but I need to get into netmf's networking code to see what that means, since you'd effectively be making a multihomed system).

 

...  Can you post a zip of what you have so far?  Being able to start with (at least) the basic SPI stuff working would be very helpful.  

 

What I have right now, such as it is, is really exploratory code with no design to speak of, so it would be an embarrassment for me to post it.  If you really need it, I can douche out my more spirited comments and send it to you PM or something, but really I can sum it up this way:

 

Electrical:

using NP2

D13 - sck

D12 - miso

D11 - mosi

D6 - /IRQ

D5 - PWREN

D4 - /CS

3.3v  - pwr *

GND - no 'earth'ly idea

 

*  this will have to change soon as I start doing radio stuff; too much load

 

I am manually managing /CS and monitoring /IRQ for now -- maybe forever.  The SPI transactions often have to be done in two parts, and /IRQ is irksome in that it has mixed duty and doesn't seem useful to use it as an interrupt source, at least not so far, and anyway it gives me the feel of being level-sensitive and that's not supported on the NP2, but I'm not sure.

 

Software:

 

things:

SPI cc3000;   //I spi something that begins with the letter 'cc'    OutputPort cs;    //active low    OutputPort pwren;  //active high    //InterruptPort irq;  //interrupt; active low    InputPort irq;    //YYY I'm going to poll this for now until I understand this device better  

config:

  //make our spi (mode 1)      cc3000 = new SPI(new SPI.Configuration(        Pins.GPIO_NONE,    // SS-pin (we will manually do it)        false,        // SS-pin active state (low)        0,          // The setup time for the SS port YYY 50 uSec        0,          // The hold time for the SS port        false,        // The idle state of the clock (low)        false,        // The sampling clock edge (trailing)        1000,        // The SPI clock rate in KHz        SPI_Devices.SPI1));  // The used SPI bus (refers to a MOSI MISO and SCLK pinset)      //make our (manually controlled) cs (active low)      cs = new OutputPort(Pins.GPIO_PIN_D4, true);      //make our power control (active high)      pwren = new OutputPort(Pins.GPIO_PIN_D5, false);      //make our interrupt input (active low)  //XXX holding off on this until I understand the device better      //irq = new InterruptPort(Pins.GPIO_PIN_D6, false, Port.ResistorMode.Disabled, Port.InterruptMode.InterruptEdgeLow);      irq = new InputPort(Pins.GPIO_PIN_D6, false, Port.ResistorMode.Disabled);  

  //power up      pwren.Write(true);  

 

the spi clock speed was chosen semi arbitrarily, to make debugging with the scope easier.  Side note:  specifying 1000 KHz actually gave me a clock of 640 KHz.  I measured.  Maybe a Gates reference joke -- 'who will ever need more than 640K'?  anyway....

 

action:

 

The SPI transactions are mostly normal.  'Mostly', because:

*  the first one only after powerup requires a 50usec pause after the 4th byte before continuing.  seems like a workaround for device bug.  I do this by two sequential WriteRead operations.  netmf is slow enough that you don't have to use any delay code, and you get about 84 us delay.  happily there doesn't appear to be a max delay.

*  the reads involve retrieving a length of the variably sized payload that follows, so you need to do those transactions in two phases also.

 

goofy first write (also this required to be a 'link start' command):

 

  //wait for the signal that its ready      //XXX III support a timeout      while (irq.Read()){}      begin();  //assert cs and (redundantly) wait for irq      //delay(50usec);      //goofy first write has a little pause after the first busy bit before moving on with the rest      cc3000.WriteRead(pktLinkStart, 0, 4, null, 0, 0, 0);      //delay(50usec);        //and then the rest of it      cc3000.WriteRead(pktLinkStart, 4, 6, null, 0, 0, 0);      end();  //negate cs  

reading is a little interesting in that you must retrieve the length, and then complete the reading:

 

  //wait for the signal that its ready      //XXX III support a timeout      while (irq.Read()) { }      begin();  //assert cs and (redundantly) wait for irq      //write header and read the length bytes      cc3000.WriteRead(pktReadHeader, 0, 5, pktReadPayloadLen, 0, 2, 3);      //make length into a number; header is big endian.  other things are little.      int nPayloadLen = ( pktReadPayloadLen[0] << 8 ) | pktReadPayloadLen[1];      if (0 != nPayloadLen)      {        byte[] pktBogoWrite = new byte[1];  //dummy        //read payload        //XXX sanity check on length        byte[] pktReadPayload = new byte[nPayloadLen];        cc3000.WriteRead(pktBogoWrite, 0, 1, pktReadPayload, 0, nPayloadLen, 0);        //XXX III 'spatchy      }      end();  //negate cs  

OK looks like I did wind up posting most of what I did so far, haha!

 

Some things:

 

*  a healthy level of distrust of the documentation is worthwhile.  For instance, they contradict themselves in what is the spi mode to use.  It is spi mode 1.

*  you can tell that different engineering teams worked on this, not necessarily in concert for whatever reason.  For instance, some values are big endian, and others are little endian, so watch for that.

*  the 5 byte header I would probably re-phrase as:

  *  unsigned char byDir;  //1 = write, 3 = read;  from the spi master perspective

  *  unsigned short sWriteLen;  //little-endian;  when op=1, master indicates payload length; otherwise zero

  *  unsigned short wReadLen;  //little-endian;  when op=3, slave indicates payload length; otherwise zero

 

I think this covers most of the SPI; I still need to get a handle on whether there is more /IRQ consideration since the doc claims it serves some double duty, and that there is collision resolution to be performed.

 

Beyond that, I planned to do some reading in the light of my newfound knowledge, before I do much more coding.  There's something called 'patches' which are not really clear to me if I care about, and they use the term 'event' which I think really means 'return value' and 'asynchronous notification'.

 

On the plus side, it looks like the part is what I would describe as:

*  SPI-based RPC mechanism to Berkeley sockets, with some added stuff as needed (e.g. setting mac, wifi keys, etc).

 

So I think it should be straightforward to implement an API even on the managed side that very closely resembles the existing network api, and possibly on the native side to mesh with what exists there as well.  Hope springs eternal!


  • Valkyrie-MT likes this

#39 Valkyrie-MT

Valkyrie-MT

    Advanced Member

  • Members
  • PipPipPip
  • 315 posts
  • LocationIndiana, USA

Posted 02 July 2013 - 05:36 PM

WOW.  I have a long weekend coming up and I know what I will be doing now!  

 

Sure, why not?

My plans (up to this point) were:

*  prove hardware interface (done)

*  prove SPI communications (done, I believe)

*  first make a managed code 'driver'

*  then make a native code integration with the firmware

...

 

So I think it should be straightforward to implement an API even on the managed side that very closely resembles the existing network api, and possibly on the native side to mesh with what exists there as well.  Hope springs eternal!

 

I completely agree with the managed approach.  It reminds me of the enc28j60 driver that Hanzibal ported from C.  When I saw the raw packets coming in, my eyes lit up and I knew it was doable to do everything managed.  And the debugging was much easier because of it.  Once we have the communication and the command message objects, we should be able to take it all the way.  One thing that could accelerate things greatly would be if I can get just get raw packets to work, I can bolt on mIP and immediately have a usable solution.  To me the next step would be to leverage the cc3000 TCP stack to offload the work to improve performance.  I think going all native should not be necessary since the TCP stack is in hardware, there would be little overhead in the managed portion.  If I can do an entire TCP stack in managed code, then wrapping the cc3000 TCP stack with managed code should perform far better.  

 

My only concern with the managed approach is future changes to the cc3000 firmware and hardware may also require changes in the wrapper (but that is likely to be minimal).  



#40 ziggurat29

ziggurat29

    Advanced Member

  • Members
  • PipPipPip
  • 244 posts

Posted 02 July 2013 - 06:08 PM

WOW.  I have a long weekend coming up and I know what I will be doing now!  ...

 

Haha, have phun hacking!

 

...

I completely agree with the managed approach.  It reminds me of the enc28j60 driver that Hanzibal ported from C.  When I saw the raw packets coming in, my eyes lit up and I knew it was doable to do everything managed.  And the debugging was much easier because of it.  Once we have the communication and the ..

 

I'm very impressed you and hanzibal got a tcp stack and ethernet device driver working in managed on netmf.  Thats a lot of work.

 

...

command message objects, we should be able to take it all the way.  One thing that could accelerate things greatly would be if I can get just get raw packets to work, I can bolt on mIP and immediately have a usable solution.  To me the next step would be to leverage the cc3000 TCP stack to offload the work to improve ...

My only concern with the managed approach is future changes to the cc3000 firmware and hardware may also require changes in the wrapper (but that is likely to be minimal).  

 

I'm somehow sceptical that you'll be able to get raw packets, but my understanding of this device is far from comprehensive, so don't take my word for it.  (I think it's whole raison detre is to present a high-level berkeley sockets-esque api, so that's why I'm doubtful about that).  But no matter, it will make the job 'easier' to not have to fiddle with windows, retries, mtu, congestion control, etc.  Oh wait, you already did that.  Nevermind!

 

The managed implementation is especially worthwhile if you make a shield based this device, because then you can add it onto some existing platform.  It is a small wonder to me that shield vendors do not supply rich, robust, support software, but perhaps that's due to the dynamic of this DIY market.  Still, it seems a fertile ground for an enterprising person to produce a cc3000-based shield, supply excellent support software, and just beat the pants off all the current alternatives.  (well lasting until at least the next person makes a cc3000 board, and tells folks to download your free support software, haha, but that's part of how this market works.  then you have to differentiate a different way.)

 

I suspect that they won't change the firmware and hardware in a way that would break your implementation.  That would be bad business.  Maybe they would come out with a new device, shipping both, then obsolescing this one.  But its a moderately new part.






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.