RoadTest: TI Wi-Fi CC3200 LaunchPad & CC3100 BoosterPack
Author: hlipka
Creation date:
Evaluation Type: Evaluation Boards
Did you receive all parts the manufacturer stated would be included in the package?: True
What other parts do you consider comparable to this product?: Modules like the new ESP8266, RN-XV, bluetooth modules or even the good old ENC28J60.
What were the biggest problems encountered?: Linux support is still weak.
Detailed Review:
First, let me thank for being able to participate in this road test. Even though I did not have enough time to work on the project I had planned for the CC3200 (due to the "Forget me Not" challenge), I had a fun time with these two boards. And I think they might be a good companion to my final "Forget me Not" project.
Since I'm a Linux user, my main focus in the beginning was to see how well it is supported by TI. To make it short: its a mixed experience. CCS is now available for Linux for a while, and in the newest versions supports also the CC3200/3100. But thats it with whats available from TI. The SDK for the CC3200 is distributed as Windows Executable (and it is an installer, not a self-executable ZIP file). Fortunately it can be run under Wine, so its simple to get at all the source code needed.
Updating the Firmware (which is recommended, especially if you want to use Energia) seems not to be supported on Linux at all, since it relies on the installation of drivers. So I used a virtual machine for that (still running XP on it). You need to install the Firmware update package (another Windows installer), the UniFlash programming tool and the SDK (because it has the drivers in it). Having done that, make sure you set the Jumpers on the board the right way (see the Energia guide for detailed explanations). If you did everything right, the firmware update is easy and simple (in contrast to the rest of the UniFlash operation - see the UniFlash manual for how complex that tool is).
Next step is to setup the development environment. One can use Energia which is available on all major platform. But to use the SDK fully, and also the sample applications, a real development toolchain is needed. The user guide explains how to setup the GCC tool-chain on Windows (using Cygwin), and the Linux setup is mostly similar (except that Cygwin is not needed). I found some additional guides that were helpful: https://hackpad.com/Using-the-CC3200-Launchpad-Under-Linux-Rrol11xo7NQ , http://www.achanceofbrainshowers.com/blog/tech/2014/8/19/cc3200-development-under-linux/ and https://gist.github.com/dariuskl/086823c781bfb61af361 .
(I did not need to set up the udev rules on my Kubuntu 14.04 system though, the FTDI adapter was detected automatically). After installing the CodeSourcery tool-chain, don't forget to set the PATH correctly so the binaries can be found.
You might ask: why not using CCS? Well, the picture is somewhat unclear there. CCS runs well under Linux, but it doesn't support all of the boards and debug probes. An answer in the E2E forums says that Linux support for CC3200 comes only at the end of the year. The CCSv6 Linux install guide says that CC3200 is supported (no word about CC3100), but states that the FTDI-based debug probes are not supported. So it seems that this would require additional work, or waiting until next year.
The CC3200 comes with a demo application preprogrammed. In the default state (with a pre-populated jumper on P58) the boards starts up in Access Point mode, so one can connect a PC, tablet or phone to it. If you do that, it opens up a web page that explains and shows some of the boards features.
Since I wanted to try my tool chain, I went after the simple getting started demo project ("Getting Started with WLAN Station"). It comes with a makefile for GCC, and compiled on the first run (after setting the proper path for my CodeSourcery tool-chain). Uploading was also no problem using OpenOCD and gdb, an the CC3200 signaled that it connected to my access point. Important here is to set the right AP name as well as the password for it in the source code (though thats a security risk, more to that later).
One also needs to be careful setting the jumper properly again - the differ form whats needed for the firmware update. Doing that wrong seems to cause no harm, but flashing the program does not work then.
When looking at the sample applications in the SDK, the limited Linux support strikes again: the GCC makefile are available only for a small set of examples (the infamous blinky, the getting started projects, TCP and UDP stream tests, get-time, xmpp and FreeRTOS). For all other projects the support is only available for CCS and IAR EWARM. Fortunately its not so complicated to create such a makefile from scratch (taking the existing ones as starting point).
The set of sample applications is really large, and cover basically anythings that can be done with a network-connected device. Especially important for me is the availability of a SSL demo application. I think that a modern IoT appliance really needs to focus on security. And most of the network-connected boards I know of cannot handle this at all or make it rather difficult. So I was pleased to see a complete SSL demo application, which not only does server certificate verification, but can also handle client side certificate for authentication. It uses the serial flash available on the boards to store the certificates (here the UniFlash tool comes into play again), by treating the flash as (FAT?) file system. It took me about half an hour to create a gcc makefile for this project, to get it compile successfully. But since the UniFlash tool runs only in a VM I could not be bothered to upload some certificates to really test it. Also, since the verification needs to have the current time set, it should be combined with the 'get-time' demo (that uses NTP to set the current time).
Other demos that are available include accessing weather data, doing HTTP, P2P and XMPP communications, demonstrating basic NTP and UDP socket handling, showing mDNS service discovery and many other basic networking capabilities. Also interesting are the examples for access point provisioning. many of the samples rely on having the AP name and password hard-coded in the program. But thats a security risk: its difficult to change when needed, and one might accidentally commit these to a version control system. So TI provides some examples how to do this differently. First version is to start up the board in AP mode (by setting a jumper), which can be used to enter the target AP data via a web interface. The second version used to so-called SmartConfig tool, which is available for iOS and Android. There the board also starts up in a special AP mode, but the configuration seems to be easier to do. I would need to look deeper at these examples to see how easy they are to integrate into own projects, but I reckon it should not be that problematic.
Whats also nice to see is the support for both FreeRTOS and TI-RTOS. There are several samples available for both, so it should rather easy to start own projects based on them. 8And for the FreeRTOS library there are even ggc makefiles 
For the CC3100, two things are noteworthy. First, the sample applications seem to assumes that one uses the CC31XXEMUBOOST baseboard, which was not provided as part of this road test. So I had no way to run these demos, nor to update the CC3100 firmware. Second, with the base board it is possible to use the SimpleLink Studio IDE that allows development of CC3100 programs on a PC (support for Windows only, again). These programs then can be moved over to other MCUs, after getting them to work.
Whats missing is a sample application for the TMP006 temperature sensor and the accelerometer. They are used by the out-of-the-box demo application, but for that no source code is provided (just a binary project for upload).
Having written so much about the software side, I should also take look on the hardware. First of all, when comparing with e.g. the "Connected Launchpad", these boards are small. The CC3200 is only a little bit larger than the MSP430 LP, and the CC3100 has normal booster-pack size. Both have a chip antenna on board, and come with connectors for external ones. I have not yet made tests about the range that these antennas work with.
The boards itself look nice, as its usual for TI. The CC3200 board does not come with standoffs, but has header on its bottom side. That leads to it tipping over any laying on the USB cable, which I think is a oversight from the engineers.
In contrast to other LP versions, the part with the programmer cannot be removed from the CC3200, so one always need to use the full board. OTOH, judging from the schematic, it seems to be possible to use the programmer part for external circuits too (as standalone programmer). I need to test that, though.
I like that its easily possible to power the CC3200 from an external power source, not every time an USB port is available. A dedicated port for that is nice. OTOH, there are way too many jumpers for my liking. You need to select between working with the flash memory (using the UniFlash tool) and two different programming / run modes. Select between who gets to use the UART - there is only one? Select whether the peripherals are accessible or not, and with which lines, and so on...
There is no documentation in the box, and also no CD with tools or documents on it. Thats something that I miss in comparison with the earlier development boards from TI. But maybe TI reckons that everybody has fast Internet connections. And providing tools and documents via download only means that they are always up-to-date.
TI provides a really nice and comprehensive home page for the CC3100/3200. There one can find all documents, the SDK, tools and explanations. It really is a go-to-place for all information. The sample programs are well-explained here, and so are the different tools and features.
The CC3200 really is the first network adapter (when I can call it that, its actually more than that) that really fulfills what I would expect (and need) from an IoT connector. Its support for SSL/TLS, together with real certificate validation and authentication, are crucial for all appliances with only the slightest need to security.
Both modules are rather easy to program with, even though the support on the Linux side is still weak. The UniFlash tool for managing the flash storage file system could be easier, right now its rather complicated to work with.
I really look forward to use the CC3200 in a real project, looks like this will be fun.
