Using Contiki with linux CCS

Creating Contiki/CETIC based IPv6 border router solution (6LBR) with BeagleBone Black and using TI SensorTag2 with SLIP to connect 6LoWPAN mesh network is one thing. Debugging node from linux is another. Let's see how it works :)

Getting Contiki git repo and compiling web-demo for TI Sensortag in linux works quite well. Flashing it not so. Recommended way is to
transfer image to windows and flash from there, but it's possible to flash from linux commandline also. Using Code Composer Studio (CCS) makes job much easier, and you can also debug your code, at least in theory.

CCS can import project with makefile-style compiling (File -> Import -> C/C++ -> Existing Code as Makefile Project). Unfortunately it only can understand simple Makefile and Contiki uses include etc. Even when you can compile image, CCS will complain lot's of errors and warnings. It's quite bizarre situation. One way to 'fix' it, is defining things in makefiles to headers so CCS known what is actually defined when compiling. Like adding to project-conf.h:

/* for CCS as it can't detect this from Makefile.include */
#define NETSTACK_CONF_WITH_IPV6 1
/* CCS uses wrong button-sensor.h */
#ifndef BUTTON_SENSOR_VALUE_DURATION
#define BUTTON_SENSOR_VALUE_DURATION 1
#endif

Also finding source files can be a bit tricky. Adding whole contiki would be simple way so solve this but CCS don't like adding parent of project. Way around is adding links (to project) to needed subdirectories:
project -> properties -> c/c++ general -> Paths.. -> Source Location -> Link Folder
apps, cpu/cc26xx-cc13xx, core, platform/stf06-cc26xx
Also in c/c++ build -> settings you can enable gnu-versions of parsers.

You can also add Makefile.include from top, but it only makes editing easier (project -> Add Files -> Link).

Also you need to get debug-symbols to elf, so add Makefile:
CFLAGS+=-g
LDFLAGS+=-g

Nice. Now it doesn't complain and (most) code it shows is actually right one. To debug you need to create .ccxml target configuration file (project -> New).

Note that when you connected Debug DevPack to PC, it shouldn't have SensorTag2 connected to it. After board have booted (green led on) connect SensorTag2. Also when debugging first time, Debug DevPack firmware is updated to newest one.

Start debugger. Change Debug -> .ccxml -> Edit.. -> Program -> Cortex_M3_0 Project to project root and Program to .elf file. Check that run to symbol main is set. Next start of debug should then automagically load & run to main(). If it doesn't automatically load image to SensorTag2, you can choose Load & select elf.

Unfortunately good things stops there. For some reason JTAG connection to SensorTag2 seems to disconnect really often. Even dropping it's speed from 2.5MHz to 100kHz doesn't help :( This is probably due eclipse blocking and emulation package then misses something from JTAG/Debug DevPack. Hopefully future update fixes (some of) this.

Debugging active and ready to run

Jari Vanhala, Senior SW Designer, Ixonos

Quick Visual Dashboard

When developing IoT systems you’re often dealing with a huge amount of time series data. Basically key-value pairs bound to a timestamp. Or maybe you are debugging some sensor output or feedback controller only using text output on your terminal. Getting a sense of what kind of data your sensors are outputting is not easy when you’re dealing with tens, hundreds or even thousands of sensors and measurements.

Various tools already exist to visualize time series data. They are very good at visualizing large amounts of data in multiple different ways. But setting these tools up often takes time and the learning curve to effectively configure the visualizations to view your data is often an unwelcome bump in the road when all you care about is getting a sense of the data you’re dealing with without bothering with the details.

Real-time data visualized using simple graphs with minimum lag.

When developing, testing and prototyping, it is essential that you get good understanding, how your system performs in real-time and also within a longer time-frame. You don’t want to spend time configuring and setting up visualizations tools. This is why we put together Quick Visual Dashboard. A local or cloud deployed visualization tool where you can input data using standard TCP or MQTT protocols. With simple script templates done in Python, uploading data to the tool can be done in no time.

Built-in geospatial data support to see how and where your data is on the map in real-time.

The data is preprocessed and backed by InfluxDB. This means that after you’re done with your initial prototyping and you stop caring about real time data - you can go back and use industry proven tools like Grafana to further investigate all the details of your time series data at any point in time.

Using Grafana it is possible to dive deeper into historical time-series data.

Christian Talmo, Full-stack Developer, Ixonos

Stanislav Radomskiy, Senior SW Designer, Ixonos