CC3200 Network Processor Information Station

General
1

Have you guys seen that the new CC3100/CC3200 modules have been released as experimental silicon in a few new products from TI?

SimpleLink Wi-Fi CC3200 LaunchPad

SimpleLink Wi-Fi CC3100 BoosterPack

CC3100 Datasheet

CC3200 Datasheet

This is pretty damn cool stuff. The CC3100 is a standalone WiFi module and is more or less a hugely upgraded CC3000. Where the old CC3000 ran an 8051, this new module runs a speedy ARM processor.

The CC3200 is what’s really cool. It contains everything the CC3100 has, but also includes a second, completely separate ARM Cortex-M4 to run user code on. So, instead of having to implement a WiFi module and MCU on your board, you get both in 64-Pin QFN package! (No more giant metal covered package like the CC3000 has.)

I’d love to see the next Spark Core use the CC3200, I think it could fix a lot of our issues. Like what?

While the CC3200 does support SmartConfig, it also supports WiFi Direct, Access Point and Station Modes. This means in default mode, each Core could setup a unique SSID in AP mode that the user connects to in order to enter their WiFi credentials (sort of like the WeMo Outlets).

Now, most devices that setup like this require you to use a custom phone app to do the setup (you connect to the AP, open the app, enter your credentials and the device switches to that network); another interesting thing about the CC3200 is that the Network Processor contains a built in web server! So you could setup an AP, have the user connect to it and then open their browser and do WiFi setup like that. Pretty cool, right?

The other freaking awesome thing is the CC3200 supports a plethora of hardware interfaces:

  • 8-Bit Parallel Camera Interface
  • McASP Audio Serial Port (Two I2S Ports)
  • SD/MMC Interface
  • Two UARTs
  • One SPI
  • One I2C
  • Four General 16-Bit Timers (PWM Capable)
  • Single Watchdog Timer
  • Multiple Four-Channel 12-Bit ADCs
  • 27 GPIO Pins

There’s also a pin-multiplexer that lets you access any of these features on pretty much any of the I/O pins.

The Camera, SD Card and Audio interfaces are particularly interesting to me, as they are all often requested features of the Spark Core.

I’m seriously thinking about doing some work on porting the Spark Core code over to the CC3200 LaunchPad; I’ve already got a good portion ported over to the Tiva C Connected LaunchPad, much of which should be reusable here.

Moved from Post #3 to Clear Edits

So, the datasheet seems to indicate that there’s two separate ARM processors on the CC3200. The Network Processor is an ARM Cortex of unknown type (M0 I’d imagine) while the User Application Processor is an ARM Cortex-M4 running at 80MHz.

Screen Shot 2014-06-26 at 5.07.35 AM.png784×797 300 KB

<img src="//cdck-file-uploads-global.s3.dualstack.us-west-2.amazonaws.com/business7/uploads/particle/original/2X/d/db09e5633aeea80f97eb74f9ce615712205f85a7.png" width=“425” height="350”>

<img src="//cdck-file-uploads-global.s3.dualstack.us-west-2.amazonaws.com/business7/uploads/particle/original/2X/f/f3e9ae3d31ae6ed5381aa88798176b0ac314abb7.png" width=“374” height="457”>

<img src="//cdck-file-uploads-global.s3.dualstack.us-west-2.amazonaws.com/business7/uploads/particle/original/2X/4/4989c88273f61a353a8552e2910c40f35fffcc58.png" width=“480” height="500”>

Just look at all the things they stuffed into a single, 9x9mm 64-Pin Leadless Quad Flat Pack…

So what do you guys think? I’m super excited for this. :smiley:

5 Likes
4

Here’s my mockup of that chip on a Spark Core II:

<img src="/uploads/particle/2423/d3f9f38787997a2c.png" width=“642” height="500”>

Since the GPIO are highly reconfigurable, you could make the main 16 pins do just about anything depending on how you programmed them. In my render above I’ve got a mini-header for additional I/O and a built-in MicroSD slot on the bottom. (That would be used to both hold the user’s application image and be available for user data, since the CC3200 lacks internal flash and needs either SPI or SD storage.)

1 Like
6

So, I started looking over the GPIO pins and figured that small header upfront wouldn’t work. It looks like the CC3200 has 26 useable GPIO (if you use a 32KHz and 40MHz crystal, versus an external clock source or TCXO). If we change the pinout of the two default headers so that each side has 10 signal pins (versus the current 8), we could use 20 of the 26 available GPIO!

The additional 6 would be used for the RGB LED (3 pins) and the mode button (1 pin). That leaves two pins, which would go to the FTDI USB to Serial chip (on UART2). Though, that’s assuming we don’t want any flow control; which I don’t think we need since 115Kbps should be fast enough for serial debugging. Ideally you’d use one of the JTAG/UART FTDI chips, which would give you built-in USB based JTAG debugging and serial support!

1 Like
7

Currently I’m on step 3 of the getting started guide, which is to download and install what’s needed to create Project 0.

Downloading the CC3200 SDK was straight forward. Next you set some jumpers on the LaunchPad and then install CCS 6.0 (Code Composer Studio, TI’s Integrated Development Environment). To do that first you have to fill lout a form defining what you are using it for and ensuring you are using it in the USA and not going to export it. I’ve done this 3 times in the last 2 hours, once for the SDK and twice for CCS.

Why twice for CCS. Because the web install of CCS fails. I remember now when I got a Tivo (Arm Cortex m4) back a month or so again, the CCS install failed then. On the same thing. It chokes downloading a big zip file. It allows you to submit a problem report to Ti. Which I did at the time, and never heard from again. I finished up adding the Tivo and the arm development environment to the CCS 5.5 version I had previously installed when I first started working on the VO-96.

I suspect the problem is somehow related to my satellite internet connection. The only alternative to that is to take myself and my laptop to my daughter’s place 120 miles away and use their comcast internet connection. Seeing I was just there yesterday, I was reluctant to embark on another 250 mile 4 hour trip just to overcome a TI install issue (if in fact it did overcome it).

So the trick for CCS 6.0 is to download the full zip file version. A Google search of the install error turned this up as an alternative. 754 megabyte download, and a new form to fill in, but it downloaded and installed. I added the Tivo and the VO’s C280xx to the install as well so I can have everything in one suite. Of course, once it is installed, you need to do “check for updates” and get them all applied as well. So after a couple of hours doing the “download and install CCS 6.0” bit. I’m ready to move on.

CCS has a video for me to watch…and the intriguing question “Would you like to use CCS in ‘Simple Mode’ Yes or No” to answer. One wonders what ‘Simple Mode’ relates to in CCS. Seems like an oxymoron. Anyway, I’m not about to find out; I’ll stick to the Eclipse mode I know and love so well (well, know…)

Here’s the link to the TI Wiki page where you can download the zipped CCS

I have managed to successfully compile and execute Project 0, although I have no idea what it’s doing. Called Wan_Station and blinking the red led like crazy

3 Likes
8

That’s what it does - and it works!!!

3 Likes
9

Just an FYI to anyone who doesn’t know, the CC3200 is TI’s new chip that is a Cortex M4 micro and WiFI (with a full hardware IPv4 stack) in a single package. I’ve been playing with these at work for awhile now, so I’m going to do a bit of a brain dump here just in case it helps anyone else.

The launchpads seem to have 2 MB of (external) sflash which is used to application code, certs, and a basic filesystem that you can access from your application. I think they have either 128K or 256K of ram depending on which rev you get.

The green and yellow LEDs are tied to the i2c lines, so they’ll always be on if you’re using the temp sensor or accelerometer. The SOP2 header is what controls the programming mode, if it’s on you can flash the board, if it’s off the application will run.

There are only windows drivers right now, I use linux (but I don’t fully have it working yet). Luckily most of the example projects include makefiles, but you’ll need the SDK from a windows install and you’ll then need to make a few things lower case, I seem to remember a “SimpleLink” that needed to be “simplelink”, both in files and file names. There’s only a few, just compile and see what complains. To get the serial port working see: http://www.ftdichip.com/Support/Documents/TechnicalNotes/TN_101_Customising_FTDI_VID_PID_In_Linux(FT_000081).pdf (I had to remove a flag in the command that they give, try it by hand before putting it in the file.) I don’t know how to flash the application binary and I haven’t gotten OpenOCD working yet, so no help there.

If anyone knows anything about flashing these under Linux, let me know.

EDIT: This is the /sbin/udev.reules.d/99-tiftdi.rules file that you’d need:

# For CC3200 Launchpad with FTDI Chip that TI put their codes in. ID = 0x0451, Product ID = 0xc32a
SYSFS{idProduct}==”c32a”, SYSFS{idVendor}==”0451”, RUN+=”/sbin/modprobe ftdi-sio product=0xc32a vendor=0x0451”
2 Likes
10

Holy cow that’s some kinda crazy build version!

3 Likes
11

A bit more reading and researching uncovered (for me) the following:

The host driver design has moved to queuing network events and processing them at task not at interrupt level. This I felt was the major issue with the CC3000 and causes most of the problems. The CC3200 can now get an event while processing an event and all is still well. On the CC3000 the last event is gone forever. Incidentally, TI has pretty much done the same thing I did in sprkRT for handling events, not that they knew anything about that. Still, makes one feel good.

The HTTP Server in the network processor uses new host events of “Get_Token” and “Post_Token” to provide dynamic content to and from the application processor. The token is up to 64 characters and the “get_Token” designator can be imbedded in web page content and is replaced by the token value sent from the host. There are a number of predefined system tokens and also a reasonable number (2 alphanumeric digits worth) of user defined tokens as all. The network processor will wait up to two seconds to get a token response, and if none will insert “not available” in its place.

All web pages are stored in the sFlash file system which is managed by the network processor. There are a number of new api commands allowing application processor access to the file system. TI provides a provisioning web application when the network device is in AP mode. The HTTP Server can be enabled/disabled from the application processor via the host interface.

there is a reference to a porting guide and also memory manager but I can find no documentation of either. I did notice there is anew config option to specify the max TCP transfer size, but I imagine it still defaults to needing SPI buffers of 1482 bytes plus change. I’ll dig into the code tomorrow and see what I can find. The UDP issue with the CC3000 of lumping received packets together is not mentioned so I have no idea whether this problem is fixed or not.

My head hurts. That’s enough for one day, I think

1 Like
12

I’ve been working on CC3200 pre-release silicon under Linux. I use the Linaro gcc compiler fork found at http://www.linaro.org and reverse engineered the flash tool and ported it to Linux python.

I also ported the nuttx OS to run on the M4 core (http://www.nuttx.org).

If anyone is interested in this please let me know.

5 Likes
13

What I have found very interesting today is the documentation. Most of what I have read today (the pdfs at least) are dated June 24, 2014, and what’s today, the 28th. The oldest doc I looked at wa for T)-RTOS which was dated March 2014.

The host driver side has been completely rewritten from what TI provided for the CC3000 and seems much better organized. Porting should be straightforward, but I believe you have to have an OS. @Droidifi talks about nuttx above, I have put CoOS on the spark and TI provides freeRTOS and TI-RTOS for the C3200 via CCS. Memory requirements are much less now, with data being transferred to and from user buffers directly; so no large TX and RX buffers and virtually all the large arrays and static structures are gone as well. Semaphores, mutexes, message queues and dynamic memory allocation/release seem to be the method.

Although it would be easy enough to port to a STM device, even one with as little memory as the STM32F103CB, by using nuttx, freeRTOS, or CoOS as the operating environment, it would be very difficult to keep the current spark/arduino programming environment, IMHO. Probably possible to rewrite the wiring interface but multi-tasking does require the use of message queue for task to task communications and mutexes for shared object protection.

Tomorrow I plan on starting to write some code

1 Like
15

Merged posts from the newer CC3200 thread to this one, since it was older.

I’ve got my LaunchPads on the way, hopefully they’ll arrive this week. I’ve already started modularizing Wiring for TI-RTOS that basically uses DriverLib for all the hardware functions. This means we get stuff like full DMA access and very fast GPIO access for free, since it’s ROM based!

After that I’ll start on a Spark Cloud Module.

16

Continuing the discussion from Will there be a Spark Core II:

I think there is a lot of community interest in these new TI chips and what influence they may have on future Spark Cores, so I thought it best to start a new topic to document my experiences with the TI CC3200 Launchpad.

17

Well, depending on how many SPI ports you can break out of the CC3200, you could even work a bluetooth chip onto the Spark II.

And to the Spark developers - This is the time to get your desktop IDE, local cloud and Spark firmware ROCK SOLID - the Arduino is winning the game across the world in universities and personal projects because of its IDE. If you want Spark to compete and not be beaten by the Yun 2 (which will no doubt use the CC3200 and might come in a nano form factor), you need to give us:

  • A desktop IDE
  • Cross platform development tools
  • GUI control of a number of Spark devices deployed in the field, including security to prevent them from being ‘cracked open’ if stolen
  • The entire development and deployment under my control - I don’t want to rely on somebody else’s cloud servers to pass commercially sensitive data between my severs and my Spark, or to store or flash commercially sensitive code I’ve developed.

I know you’re working on all of this, I just wanted to put my thoughts down in black & white. Looking forward to seeing what comes out in the next couple of months. Just note that a service I’m developing is currently on hold until a few of the above are taken care of. PCBs are designed, server software is developed…now I’m waiting for the ‘brains’ of the front end to work as expected before I can deploy.

2 Likes
18

Here’s an explanation of this build version:

1 - 4, Network Processor version
5, fixed constant 31
6 - 9, Chip firmware version (I assume of the rom code burnt into the chip)
10 - 13, Chip physical version

So. some rationale to the craziness :smile:

2 Likes
19

Can I make outgoing https requests using cc3100 or cc3200?

One can not make outgoing https calls from spark core today, and that’s a major roadblock for me.

20

from TI documentation for the CC3100/CC3200:

Embedded hardware crypto engine for TLS/SSL internet security - Quickly enable TLS secure link (<200ms)

1 Like
21

Note, the crypto engine isn’t standard. There will be a specific part suffix for units that contain hardware accelerated cryptography.

I doubt you’ll see the crypto part on a future Spark Core, since that part will be subject to US export restrictions.

22

Why do you think you need an OS? The Network Processor handles all of the networking: Link Layer, Internet Layer, Transport Layer and even some Application Layer tasks!

The entire idea behind the CC3000 and, in turn, the CC3100 is to allow low power, cheap microcontrollers access to the internet. That's the point of offloading the TCP/IP stack onto a separate processor!

Anything that can use a CC3000 should be able to use the 3100, maybe even less powerful hardware since the 3100 has built-in servers and clients for web, chat, email and other services!

You just talk to the module via SPI or UART... So unless your specific application needs pre-emptive multitasking, semaphores or task scheduling, there's no real need for an RTOS.

23

It’s certainly available in the launchpad, although I’m sure it is not available for export

24

@Droidifi, I’d be very interested in your Linux port of the flash tool. Is it posted anywhere online?