TI's SimpleLink CC3200-LaunchXL with Linux First Steps


Texas Instuments offers an evaluation kit for it's Single-Chip Wireless MCU CC3200: CC3200-LaunchXL

Citing from TI's Description:

The SimpleLink™ Wi-Fi® CC3200 LaunchPad evaluation kit is a development platform for the CC3200 wireless microcontroller (MCU), the industry’s first single-chip programmable MCU with built-in Wi-Fi connectivity. The board features on-board emulation using FTDI device.

This LaunchPad comes with driver support and a software development kit (SDK) with 40+ applications for Wi-Fi protocols, internet applications, and MCU peripheral examples.

The CC3200 MCU features a 802.11 b/g/n Station and Access Point, roles with fully integrated radio, baseband, and MAC Standards-based Wi-Fi solution Single-chip Wi-Fi MCU: Wi-Fi network processor + ARM® Cortex®-M4 MCU integrated into one chip including RF reference design.

This page will document my experiences with the CC3200-LaunchXL using Linux as development platform.


Getting the SDK from Texas Instruments

For downloading the SimpleLink Wi-Fi CC3200 Software Development Kit (SDK) you need a "myTI" account which you may create for free.

The SDK is a Windows executable which simply installs all the files needed for development on a Windows platform. To be able to use the files on Linux you may either run the SDK installer on a Windows box and copy the directory tree to your Linux system, or you may run the installer with wine directly under Linux.

Running the installer on Windows creates a directory tree under C:\ti\CC3200SDK_1.0.0.

As stated above, you may run the SDK installer under Linux with wine:

wine CC3200SDK-1.0.0-windows-installer.exe

Running the installer with wine creates a directory tree under ~/.wine/drive_c/ti/CC3200SDK_1.0.0.
I symlinked ~/.wine/drive_c/ti/CC3200SDK_1.0.0/cc3200-sdk to ~/cc3200-sdk and used this in the examples below.

The CC3200 Software Development Kit consists of a collection of hardware and software documenting pdfs, a collection of example program sources, the sources of the hardware driver library/application development framework and some tools to support development with serveral IDEs and tool chains.
Of course the GNU toolchain (gcc) is the one interesting me.


Configuring the LaunchXL JTAG Debug Interface

The debug interface is provided by an FTDI FT2232 chip with custom vendor and product IDs. To make it accessible for the Linux system, there is an udev rule (from here) needed:

# 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”

(in kernel versions newer than 3.12 this doesn't work anymore, see here)

With the ftdi-sio module loaded (by the above udev rule or otherwise), I get two /dev/ttyUSBx devices when the Launchpad is plugged in.

In my setup, OpenOCD seems to write access /dev/bus/usb/<bus_num>/<node_num> which is owned by root:root. This ownership is not changed by a GROUP:="dialout" statement in the above udev rule.

So I had to add an additional rule to change group ownership of this device file.
My /etc/udev/rules.d/99-tiftdi.rules looks like this:

ACTION!="add", GOTO="cc3200_lp_end"
SUBSYSTEM=="usb", ATTR{idVendor}=="0451", ATTR{idProduct}=="c32a" \
  , ENV{bus_id}="$attr{busnum}", ENV{node_id}="$attr{devnum}" \
  , RUN+="/sbin/modprobe ftdi-sio product=0xc32a vendor=0x0451" \
  , RUN+="/usr/local/ftdi_chown.sh"


/usr/local/ftdi_chown.sh is a tiny script getting bus id and node id from udev via environment and changes the group ownership of the respective device file.


# bus id and node id in the device path are not simple integers but zero padded to a width of three.
bus_id=`printf "%03d\n" $bus_id`
node_id=`printf "%03d\n" $node_id`
chown :dialout /dev/bus/usb/$bus_id/$node_id

Running gdb/openocd as described below will remove the first of the two /dev/ttyUSB* for use as the debug interface.
The second /dev/ttyUSB* may be used as a serial console by the target program.


Build and install openOCD (Open On-Chip Debugger)

Building and installing openOCD is the standard "./configure; make; sudo make install"
cd <openOCD source tree>
sudo make install

Make shure the ./configure run reports

OpenOCD configuration summary
MPSSE mode of FTDI based devices        yes (auto)

Using OpenOCD in version 0.8.0, the configuration file for the debug interface needs to be changed.
(same has been successfully tried with OpenOCD version 0.9.0)

In ~/cc3200-sdk/tools/gcc_scripts/cc3200.cfg replace the following few lines

interface ft2232
ft2232_layout luminary_icdi
ft2232_device_desc "USB <-> JTAG/SWD"
ft2232_vid_pid 0x0451 0xc32a


interface ftdi
ftdi_device_desc "USB <-> JTAG/SWD"
ftdi_vid_pid 0x0451 0xc32a
ftdi_layout_init 0x00a8 0x00eb
ftdi_layout_signal nSRST -noe 0x0020

Starting OpenOCD with the following command:

openocd -f ~/cc3200-sdk/tools/gcc_scripts/cc3200.cfg

shows the following message:

Open On-Chip Debugger 0.8.0 (2014-09-19-14:45)
Licensed under GNU GPL v2
For bug reports, read
Info : only one transport option; autoselect 'jtag'
adapter speed: 1000 kHz
Info : clock speed 1000 kHz
Info : JTAG tap: cc3200.jrc tap/device found: 0x0b97c02f (mfg: 0x017, part: 0xb97c, ver: 0x0)
Info : JTAG tap: cc3200.dap enabled
Info : cc3200.cpu: hardware has 6 breakpoints, 4 watchpoints

Stop OpenOCD by pressing Ctrl-C. In the future it will get started from the gdb debugger.


arm-none-eabi Cross Tool Chain

The arm-none-eabi cross tool chain will enable you to compile, link and debug source code destined to run on the CC3200 arm microcontroller.

Download the prebuilt binaries of the arm-none-eabi cross tool chain for Linux from launchpad.net. Unpack it to an appropriate directory and add the bin/ directory to the execution path.

cd ~/downloads/gpl/binary/launchpad.net/
tar xvjf gcc-arm-none-eabi-4_8-2014q2-20140609-linux.tar.bz2
export PATH=$PATH:~/downloads/gpl/binary/launchpad.net/gcc-arm-none-eabi-4_8-2014q2/bin

You may want to add the last line from above to ~/.bashrc to have the path to the arm tool chain binaries available in every future shell.

Compile one of the examples from the CC3200 SDK:

cd ~/cc3200-sdk/example/blinky/gcc

This should produce blinky.axf in ~/cc3200-sdk/example/blinky/gcc/exe/.

To be able to upload, run and debug the compiled binary for the CC3200, you may need to move the jumper from P58-VCC to SOP2.
The jumpers should be set like in the picture below.

Debugging Jumper Settings

Edit the OpenOCD start command in ~/cc3200-sdk/tools/gcc_scripts/gdbinit to make shure OpenOCD finds it's appropriate configuration file.
Mine looks like this:

target remote | openocd -c "gdb_port pipe; log_output openocd.log" -f ~/cc3200-sdk/tools/gcc_scripts/cc3200.cfg

Run a gdb session

arm-none-eabi-gdb -x ~/cc3200-sdk/tools/gcc_scripts/gdbinit exe/blinky.axf

The gdb should upload the blinky binary to the CC3200 and print something like below:

GNU gdb (GNU Tools for ARM Embedded Processors)
Reading symbols from /home/lukas/.wine/drive_c/ti/CC3200SDK_1.0.0/cc3200-sdk/example/blinky/gcc/exe/blinky.axf...done.
Loading section .text, size 0xf38 lma 0x20004000
Loading section .data, size 0x18 lma 0x20004f38
Start address 0x20004790, load size 3920
Transfer rate: 66 KB/sec, 1960 bytes/write.
Breakpoint 1 at 0x20004470: file ../main.c, line 199.

Breakpoint 1, main () at ../main.c:199
199         BoardInit();

Pressing "c" (for continue), then "enter" should run the uploaded program and you should see blinking the three LEDs D5 - D7 one after another in a one second interval.




TI Manuals as PDFs

Hardware Examples

This site maintained by:
My public PGP key
last updated: 2014-05-08 Valid CSS! Valid XHTML 1.0 Strict