wiki:cc135x

Version 22 (modified by Ryan Erbstoesser, 4 months ago) ( diff )

add eol note

  1. Ti CC135x Sub-1GHz Internet of Things Radio
    1. Hardware
    2. Frequencies
    3. Certifications
    4. RF Network / Infrastructure
    5. Network Architecture
    6. Data Rates
    7. Range Testing
    8. Glossary
    9. Software
      1. TI Code Composer Studio (CCS)
      2. TI GCC toolchain
      3. TI SimpleLink SDK
        1. Low Level RF driver API
        2. TI Real Time Operating System (TI RTOS)
        3. EasyLink
        4. TI 15.4 Stack
        5. RF Settings / SmartRF Studio
        6. TI Dynamic Multi-protocol Manager (DMM)
        7. CCFG registers
    10. Software Examples
      1. TI SimpleLink SDK examples
    11. Programming
      1. Via JTAG
      2. Via Serial bootloader
      3. Over the Air Download (OAD) / Over The Air (OTA)
    12. Identifying TTYs
    13. Serial UART Access
    14. DTR
    15. DIO / GPIO Configuration
  2. Third Party Software
    1. Wi-Sun
    2. Thingsquare
    3. Contiki-ng
      1. Installing the Contiki-ng Docker image
      2. Download and link the Contiki-ng source to the container
      3. Building the example:
      4. Using the Hello World example.

This product has been discontinued. Please consider the Gateworks 802.11ah HaLow WiFi Card GW16146

Ti CC135x Sub-1GHz Internet of Things Radio

This page describes the family of Texas Instruments CC135x Sub-1GHz radio modules that are used on several Gateworks products, including the GW16122/GW5910.

The CC135x enables ​Gateworks SBCs to act as a collector or gateway to other IoT sensors over the Sub-1GHz Radio band. This band allows for long range and low power communication without any carrier subscription required. No consortium or software subscriptions are required. TI has made all software open source and available.

Advantages of Gateworks IoT solution over SigFox, LoRa, Zigbee, etc:

  • Long Range
  • Create your own network
  • Do not rely on coverage of pre-existing networks (Verizon, AT&T, etc)
  • Open Source provided software by TI
  • No extra fees, subscription, etc
  • No joining of alliances/consortiums/etc
  • Works in remote areas where no coverage from other networks/carriers exist

Hardware

Hardware that contains the CC135x:

  • GW16122-B - CC1352P Info here
    • connected to FTDI UART
      • CBUS0: JTAG_RST/CC_RST# output (has strong pull-up)
      • CBUS1: BOOT_BCKDR output (has strong pull-down)
      • CBUS2: CC_TMSC output (cJTAG)
      • CBUS3: CC_TCKC output (cJTAG)
  • GW16122-A - CC1350
    • CC1350 connected to a TI Tiva MCU for programming * Not Recommended, use Rev B *
  • GW5910-C - CC1352P
    • connected on the JTAG chain with the CPU and GSC
    • connected to IMX UART and SPI bus for bootloader access
  • TI Launchpad
    • These have an XDS110 JTAG Debugger on-board (implemented via the Tiva MCU chip). The XDS110 debugger exposes two USB ACM serial devices where the first one is tied directly to the CC13xx UART (pinout matching the 'serial downloader' pins specified in the TRM) and the second serial device is for JTAG programming. These boards can be programmed via the TI 'Uniflash' tool (GUI or stand-alone command-line) or the CCS IDE.

IMPORTANT Always have an antenna connected, without one the high power amplifier will glitch the board and cause a reset.

References:

Recommended Gateworks SBCs:

Frequencies

The default GW16122 comes configured for the 915MHz band for use in the USA.

To use the 868MHz band in Europe, the following is required:

  • The changing of a RF circuit tuning inductor (L7 at 18nH)
  • Different firmware configured for 868
  • Typically these changes would require a 100 piece minimum order. Contact sales for possible prototyping boards.

Certifications

The Sub-1GHz portion runs on an unlicensed band, thus this transmitter portion would not require FCC certification. The overall system itself may require FCC certification however.

Bluetooth 2.4GHz Certification AP Note

RF Network / Infrastructure

The CC135x operates on its own network. It does not rely on towers/networks installed by 3rd party companies (LoRa, Sigfox, Verizon, AT&T, etc). The entire network infrastructure is under control by the user. This includes sensors/nodes, collector(s), antennas and more.

Network Architecture

The default is a star-based topology system where there is one central collector (The CC135x on a Gateworks SBC) that listens to all the sensors / nodes that are around it.

Mesh is available with other firmware documented on this page.

Data Rates

The data rates vary depending on the distance and the mode for the firmware.

Long range applications may see data rates of around 2.5Kbps, while close range applications may see data rates up to 5Mbps.

Please refer to the ​TI CC1352P Datasheet, Table 6-1 for more information.

Range Testing

* Note below testing done with GW16122 rev A with CC1350. CC1352P has a 20dBm power amplifier which will increase the range *

Gateworks did basic range testing with the GW16122 using a 2dBi Omni Antenna on the 915Mhz band. A successful link was acquired at 4500ft/1.4km over water. Note both the transmitter and receiver were only 1m off the ground so much better performance would be expected if the antennas were mounted higher to clear the Fresnel zones. Using a directional antennas, range can be increased further with links easily greater then >10Km. Additionally, there is different modes and tuning that can be done in software to increase the range, such as LRM (long range mode).

More range information may be found on the ​TI E2E Forums and on the TI documentation listed in the references on this page.

Gateworks Range testing map:

Glossary

  • BLE - Bluetooth Low Engery
  • BLE-ADV - Bluetooth Low Energy Advertising
  • OAD - Over the Air Download
  • 802.15.4 - IEEE standard defining the operation of low-rate wireless personal area networks (LR-WPANs). Definition includes the physical layer and media access control. Can be used with 6LoWPAN. The IEEE 802.15.4 standard is used as a data-link layer of many popular networking standards deployed in the market (6LoWPAN, Wi-SUN, ZigBee®, Thread and WHART). It guarantees a solid wireless foundation thanks to features like air arbitration (through CSMA-CA), acknowledgments and retransmissions and built-in AES security. 802.15.4 can operate on the following frequencies: 868/915/2450 MHz
    • Frequency: North America: 902–928 MHz, up to 30 channels
  • RTOS - Real Time Operating System
  • LoWPAN - Low Power Wireless Personal Area Network
  • 6LoWPAN - Low Power Wireless Personal Area Network, allowing for IPv6 packets. Read more ​here.
  • LRM - Long Range Mode
  • LP - Likely LaunchPad, referring to the CC1350 'Dev Kit' from Ti. Could also mean 'LowPower'
  • PA/LNA - Power amplifier (PA) for increased output power, and a low-noise amplifier (LNA) with low noise figure for improved receiver sensitivity. This can be used with the ​Ti CC1190 RF Booster / Front End
  • BLE Modes - advertising, scanning, master, slave. Read more ​here
  • TI-RTOS - TI-RTOS kernel is a tailored version of the legacy SYS/BIOS kernel and operates as a real-time, preemptive, multi-threaded operating system with drivers, tools for synchronization and scheduling.
  • TI-15.4 Stack - The TI 15.4-Stack is a software development kit (SDK) running on the SimpleLink™ Sub-1 GHz CC1310 wireless microcontroller (MCU). Based on the proven IEEE 802.15.4 standard, it implements the 'g' amendment of the specification for operations in North America and Europe in the Sub-1 GHz band (regulated respectively by FCC and ETSI).
  • LPWAN - Low‑Power Wide‑Area
  • NB-IoT - Narrow band Internet of Things
  • Contiki - read more Third Party Software
  • rfWsnDmNodeOad_US_CC1350STK_TI_CC1350F128-v1_06.hex
    • rf = Radio Frequency
    • Wsn = Wireless Sensor Network
    • Dm = Dual Mode, Bluetooth and Sub 1Ghz
    • Node = A node is an edge device that is a sensor and sends data back to a central coordinator or collector
    • Oad = Over the air download
    • STK = Sensor Tag Kit
  • Coord Addr - Coordinator Address - This is the address on the network for the coordinator/collector. Example: 0xAABB
  • PanID - Personal Area Network ID, example 0xACDC
  • FAN - Field Area Network
  • FH - Frequency hopping. Not used in default examples.
  • EasyLink - an API, a simple abstraction layer on top of the RF Driver and is intended as a starting point for customers creating a proprietary Sub1-GHz protocol or application.
    • Alternatives:
      • TI-RTOS RF driver (of what EasyLink is a abstraction of)
      • TI-15.4 Stack, Full stack-based network solution, available as part of the CC13x0 SDK
  • Thread - read more Third Party Software
  • Dash7 - DASH7 Alliance Protocol (D7A) is an open source Wireless Sensor and Actuator Network protocol, which operates in the 433 MHz, 868 MHz and 915 MHz unlicensed ISM band/SRD band. Dash7 has not been tested on the GW16122.

Software

Gateworks recommends using Xenial Ubuntu on the Gateworks SBC.Gateworks Ubuntu Wiki Page

The TI CC1352P chip also requires firmware, which the various different options are discussed below. The default CC1352P firmware shipped from Gateworks is the EasylinkNp with some slight modifications.

The TI SimpleLink products have drivers built into ROM for low-level programming capability. TI also offers several API's and stacks that sit on top of these drivers depending on your needs and programming capability.

TI also offers a real time operating system (RTOS) layer if desired and there also exist third party RTOS providers as well such as Contiki-ng and Zephyr.

Here we will focus on the TI set of tools and options as that is your best option for on-line support via the TI Community forums.

To create your own firmware for the CC1352P you use the TI SimpleLink CC13x2 SDK which contains a toolchain for compiling code as well as a set of documentation and examples.

For code development you must use TI's Code Composer Studio (CCS) (you use their compiler, but you don't have to use their IDE unless trying to import examples from the SDK).

Note that the RF core and driver core are built into the chip's ROM but they can be patched via rf_patch_cpe_*.h files which define structures that can be set to the 'cpuPatchFxn, 'mcePatchFxn', and 'rfePatchFxn' fields of the FR_Mode struct passed to RF_open.

  • the patch files can be found in $SIMPLELINK_SDK/source/ti/devices/cc13x2_cc26x2_v1/rf_patches
  • rf_patch_cpu_prop.h - RF core patch for proprietary radio support ("PROP" API command set) in CC13x2
  • rf_patch_cpu_multi_protocol.h - RF core patch for multi-protocol support (all available API command sets) in CC13x2
  • rf_patch_{mce,rfe}_genfsk.h - RF core patch for Generic FSK support

TI has excellent documentation for their SDK:

  • offline: In the SDK install directory under docs
  • ​SimpleLink CC13x2 26x2 SDK - 3.20.00.68
    • Note that this link is pinned tot he 3.20.00.68 version of the SDK which is what was used when writing this documentation. You can hover over the menu item on the right and select a different version via the '...' menu button

TI Code Composer Studio (CCS)

TI ​Code Composer Studio is an integrated development environment (IDE) maintained by TI with pre-installed tools and libraries for software development across TI MCU's including an optimized C/C++ compiler, source code editor, project build environment, debugger, and profiler using the Eclipse software framework. CCS supports Windows, Mac OS and Linux 64bit hosts.

While it is not required that you use the CCS IDE you will need the compiler toolchain that is installed with it.

Installation (CCS9 installed on Ubuntu 18.04 bionic host):

  1. Download the 'offline installer' from TI (this is a compressed tarball):
  2. Untar into desired destination directory
  3. Install the following pre-requisites of the installer 
    sudo apt install libc6:i386 libusb-0.1-4 libgconf-2-4 build-essential
  4. Run the installation GUI app (ccs_setup_*.bin) which allows you to choose your installation directory and what components you wish to install (default $HOME/ti)
    • for CC1352P development choose 'SimpleLink CC13xx and CC26xx Wireless MCUs'
  5. Once installed you can run CCS via the desktop icon.
  6. first install you will be asked to install xdctools then restart

TI GCC toolchain

The TI GCC toolchain is installed with Code Composer Studio and can be found where it installs in the tools/compiler/gcc-arm-none-eabi* directory.

The compiler produces .out files which are regular ELF files that can only be flashed to the device with JTAG programming tools. This file format can be converted to a binary image or an Intel Hex file using objcopy if using the serial downloader.

Examples:

  • convert ELF (.out) to .bin: 
    $(GCC_ARMCOMPILER)/bin/arm-none-eabi-objcopy -S --gap-fill 0xff -O binary $(FILE).out $(FILE).bin
  • convert ELF (.out) to Intel Hex (.hex): 
    $(GCC_ARMCOMPILER)/bin/arm-none-eabi-objcopy -S -O ihex $(FILE).out $(FILE).hex

TI SimpleLink SDK

The TI SimpleLink SDK contains libraries, documentation and examples for the TI CC13xx parts.

If using revision control, the following project files should be checked into source control:

  • .ccsproject - project info specific to CCS
  • .cproject - Eclipse CDT project file
  • .project - Eclipse CDT project file
  • .settings folder - Eclipse folder
  • makefile.defs (if using SYS/BIOS) - additional make rules
  • do not check in \Debug or \Release\<config name>, .xdchelp, .config folder, .launches folder

Some of the examples in the SimpleLink directory have makefiles for the TI GCC compiler while others only support being built with TI's Code Composer Studio, IAR compiler, or their newer syscfg tool. Look for 'gcc' directories if you want to use the stand-alone GCC compiler. These examples require that you define the GCC_ARMCOMPILER env variable as specified above.

The SimpleLink SDK provides examples and documentation for driver API's for the low-level drivers built into the chip ROM as well as higher-level abstraction API's such as the 'EasyLink' abstraction layer.

The TI SimpleLink SDK option allows you to jump in and code at various levels depending on your needs and comfort zone:

Other necessary TI tools and details:

  • SmartRF Studio is a Windows app that allows you to obtain configuration code for the various RF registers that control frequency, tx-power, bandwidth, and other low-level protocol details.
  • CCFG registers control details such as MAC address and how the CC135x powers up (ie if it skips past its serial bootloader and how).

Low Level RF driver API

The RF driver offers very low-level API's to run radio operation commands on the TI RF core and send and receive raw packets. For driver documentation see:

References:

TI Real Time Operating System (TI RTOS)

TI-RTOS accelerates development schedules by eliminating the need to create basic system software functions from scratch. TI-RTOS scales from a real-time multitasking kernel - TI-RTOS Kernel - to a complete RTOS solution including additional middleware components, device drivers and power management. TI-RTOS and TI's ultra low-power MCUs combine to enable developers to design applications with much longer battery life. By providing essential system software components pre-tested and pre-integrated, TI-RTOS enables developers to focus on differentiating their application.

The TI RTOS is integrated within the SimpleLink SDK and you can find details and examples for Threads, Semaphors, and Timers. For various examples you can choose to use the TI RTOS or choose the non-RTOS examples which have less complexity but less features.

Documentation:

The RF core has a dedicated driver called the TI-RTOS RF driver which is used for all interaction with the RF core. EasyLink is a simple abstraction layer on top of the RF driver intended as a start point for customers creating a proprietary Sub-1GHz protocol or application.

The EasyLink API is documented both online and offline:

In the EasyLink Network Processor project, the EasyLink API is also exposed via an AT Command Interface such that it can be exercised over serial transport by a host software (running on an PC, MPU or MCU) or manually by using a serial terminal emulator.

Examples can be found in the SimpleLink SDK under Software -> SimpleLink cc13x2 SDK -> Examples -> Development Tools -> CC1352 LaunchPad -> EasyLink.

For instructions on using the TI-RTOS examples refer to docs/proprietary-rf/proprietary-rf-users-guide.html

If you do not wish to use the EasyLink abstraction layer, there is also the option to do simple packet RX/TX using the TI-RTOS RF driver directly (see above).

On the other hand, if you wish to create a full stack-based network solution, consider using the TI 15.4-Stack (see below), available as part of the CC13x0 SDK.

TI 15.4 Stack

TI has an SDK that implements 15.4 Stack if you wish to implement the 15.4 stack on the host CPU vs the CC13xx CPU. See the ​Sensor and Collector applications for examples of this.

Documentation:

Examples:

  • ​rfEasyLinkNp: 
    export GCC_ARMCOMPILER=~/ti/ccs910/ccs/tools/compiler/gcc-arm-none-eabi-7-2017-q4-major/
cd ~/ti/simplelink_cc13x2_sdk_2_30_00_45
make -C kernel/tirtos/builds/CC1352P_4_LAUNCHXL/release/gcc # rfEasyLinkNp requires the TIRTOS kernel
make -C examples/rtos/CC1352P_4_LAUNCHXL/easylink/rfEasyLinkNp/tirtos/gcc
cd examples/rtos/CC1352P_2_LAUNCHXL/easylink/rfEasyLinkNp/tirtos/gcc
$GCC_ARMCOMPILER/arm-none-eabi-objcopy -S --gap-fill 0xff -O binary rfEasyLinkNp.out rfEasyLinkNp.bin
$GCC_ARMCOMPILER/arm-none-eabi-objcopy -S -O ihex rfEasyLinkNp.out rfEasyLinkNp.hex

RF Settings / SmartRF Studio

RF commands are used to set various RF properties via the RF Core API. These commands are passed via an RF_RadioSetup structure when calling RF_Open.

While SmartRF Studio can interactively configure SimpleLink chips over JTAG this requires one of TI's Launchpad development boards.

The RF commands and properties can be obtained using the Windows based TI RFStudio application which allows selecting RF details (frequency, tx-power, channel bandwidth, etc) and exporting these to code snippets which define the structures that are passed to RF_Open.

References:

TI Dynamic Multi-protocol Manager (DMM)

The Dynamic Multi-protocol Manager (DMM) allows multiple wireless stacks (ie BLE5-Stack, TI 15.4, Zibgee or EasyLink) to coexist and operate concurrently acting as an arbiter between the stacks and the shared RF core resource.

TI has several examples in the dmm subdirectory of the SimpleLink SDK.

For more information see the ​Latest TI DMM Users's Guide

CCFG registers

The TI SimpleLink chips have a CCFG register section defined in the Technical Reference Manual. These registers configure things such as MAC address, bootloader config, JTAG TAP/DAP configuration and some RF gain details. Many of the TI examples contain a ccfg.c file which includes source/ti/devices/cc13x2_cc26x2_v1/startup_files/ccfg.c

Software Examples

The following software examples all assume:

  • ​CCS9.1.0.00010_linux-x64.tar.gz - CCS9.1.0.0010 installed in home directory (see above for install instructions)
  • ​SimpleLink cc13x2-26x2-sdk-3.20.00.68 - SimpleLink SDK 3.20.00.68 installed in home directory (see above for install instructions)
  • Environment setup for GCC: 
    export COM_TI_SIMPLELINK_CC13X2_26X2_SDK_INSTALL_DIR=~/ti/simplelink_cc13x2_26x2_sdk_3_20_00_68
export GCC_ARMCOMPILER=~/ti/ccs910/ccs/tools/compiler/gcc-arm-none-eabi-7-2017-q4-major
export XDC_INSTALL_DIR=~/ti/xdctools_3_51_03_28_core

Pre-built firmware for these examples is available at:

Once you have a *.out binary file you can program the CC1352P via JTAG programming.

TI SimpleLink SDK examples

The TI SimpleLink examples fall into the following categories:

  • nortos - TI Drivers without an underlying operating system (OS) (there can be only one main thread which interrupts can preempt - typical 'multithreading' is not available).
  • rtos - TI-RTOS Kernel - a scalable real-time kernel designed to be used by applications that require real-time scheduling and synchronization or real-time instrumentation. It provides preemptive multi-threading, hardware abstraction, real-time analysis, and configuration tools. Note that the TI-RTOS Kennel used to be called SYS/BIOS and you can read more about it in the ​TI-RTOS Kernel User's Guide.
  • syscfg - The SysConfig tool makes it easy to configure components like TI Drivers and device-specific components (such as the networking stack, EasyLink, and WiFi).

Examples (for more examples see SimpleLink SDK):

  • Drivers (Simple Applications use the low level TI RF Driver API's):
    • ​rfPacketTx (nortos): Illustrates how to do simple packet transmission using the RF driver. This example is meant to be used with the rfPacketRx example. For every packet transmitted the GRN LED (Board_PIN_LED1) is 'toggled'. The frequency and other RF settings are in smartrf_settings.c defaulted to 868MHz 20dBm tx-power and can be modified using SmartFR Studio. 
      cd $COM_TI_SIMPLELINK_CC13X2_26X2_SDK_INSTALL_DIR
make -C examples/nortos/CC1352P1_LAUNCHXL/drivers/rfPacketTx/gcc
ls examples/nortos/CC1352P1_LAUNCHXL/drivers/rfPacketTx/gcc/*.out
    • ​rfPacketRx (nortos): Illustrates how to do simple packet transmission using the RF driver. This example is meant to be used with the rfPacketTx example. For every packet received the RED LED (Board_PIN_LED2) is 'toggled'. The frequency and other RF settings are in smartrf_settings.c defaulted to 868MHz and can be modified using SmartFR Studio. 
      cd $COM_TI_SIMPLELINK_CC13X2_26X2_SDK_INSTALL_DIR/examples/nortos/CC1352P1_LAUNCHXL/drivers/rfPacketTx/gcc
make
ls *.out
  • EasyLink (Higher Level API for RF applications):
    • ​rfEasyLinkTx (No RTOS): Illustrates how to do simple packet transmission using the EasyLink API. This example is meant to be used with the rfEasyLinkxRx example. It toggles GRN LED every 100ms indicating a packet has been transmitted. After the 10th packet is transmitted the 11th transmission will be aborted toggling the RED LED then the cycle will continue. The frequency and other RF settings are in smartrf_settings.c defaulted to 868MHz 20dBm tx-power and can be modified using SmartFR Studio. 
      cd $COM_TI_SIMPLELINK_CC13X2_26X2_SDK_INSTALL_DIR
make -C examples/nortos/CC1352P1_LAUNCHXL/easylink/rfEasyLinkTx/gcc
ls examples/nortos/CC1352P1_LAUNCHXL/easylink/rfEasyLinkTx/gcc/*.out
    • ​rfEasyLinkRx (No RTOS): Illustrates how to do simple packet reception using the EasyLink API. This example is meant to be used with the rfEasyLinkxTx example. It toggles RED LED to indicate a packet has been received. The GRN LED will toggle indicating an abort which is expected to happen if a packet is not received within 300ms of the RX being scheduled (which should occur every 11th packet as dictated by rfEasyLinkTx above). Both GRN and RED LED's together indicates an error (which is not expected to happen under normal conditions). The frequency and other RF settings are in smartrf_settings.c defaulted to 868MHz 20dBm tx-power and can be modified using SmartFR Studio. 
      cd $COM_TI_SIMPLELINK_CC13X2_26X2_SDK_INSTALL_DIR
make -C examples/nortos/CC1352P1_LAUNCHXL/easylink/rfEasyLinkRx/gcc
ls examples/nortos/CC1352P1_LAUNCHXL/easylink/rfEasyLinkRx/gcc/*.out
    • ​rfEasyLinkNP (TI Kernel RTOS): Exposes the EasyLink API over an AT command interface such that it can be excercised by Host SW. Note that this requires the TI Kernel RTOS.
      • Building: 
        cd $COM_TI_SIMPLELINK_CC13X2_26X2_SDK_INSTALL_DIR
make -C kernel/tirtos/builds/CC1352P1_LAUNCHXL/release/gcc
make -C examples/rtos/CC1352P1_LAUNCHXL/easylink/rfEasyLinkNp/tirtos/gcc
ls examples/rtos/CC1352P1_LAUNCHXL/easylink/rfEasyLinkNp/tirtos/gcc/*.out
      • Once flashed on two different boards (Board_TX and Board_RX) you can connect to the tty of the CC1352P UART at 115200bd 8N1 and use the ​EasyLink API AT commands to send and receive packets. For example:
        • BoardRX: Initialize the radio and receive data 
          AT+I
AT+RX
        • BoardTX: Initialize the radio and transmit 'hello' 
          AT+I
AT+TX Hello World
  • BLE5-Stack (These lack Makefiles so must be built via Code Composer Studio):
    • ​multi_role - demonstrates functioning in multiple simultaneous connection roles, master and slave simultaneously. A UART based API supports operations: Advertise, Discover, Connect. GATT Read, GATT Write, Connection Update, Disconnect. A UART API at 115200baud 8N1 will provide a simple menu (S2/DIO14 moves to the next menu item and S1/DIO15 selects the current menu item).
    • ​simple_broadcaster: Demonstrates non-connectable beacon applications (ie Apple iBeacon and Google Eddystone). This application uses the UART peripheral to display messages and is configured to broadcast sample advertising data out of the box via non-connectable advertisements. See ​Bluetooth low energy Beacons Application Note (SWRA475) for more information about Bluetooth low energy beacons. You can use a BLE Scanner such as the 'BLE Scanner' Android application to see the beacon which will be named 'SimpleBLEBroadcaster'.
    • ​simple_peripheral: Implements a simple Bluetooth low energy peripheral device with GATT services and demonstrates the TI Simple Profile. This example can be a framework for developing many different peripheral-role applications and is used as a baseline for explaining the stack in the ​BLE5-Stack Users's Guide. A UART API at 115200baud 8N1 will provide a simple menu (S2/DIO14 moves to the next menu item and S1/DIO15 selects the current menu item).
    • ​simple_central: Implements a simple Bluetooth low energy central device with GATT client functionality. By default the app is configured to filter and connect to peripheral devices with the TI Simple Profile UUID such as the simple_peripheral example. A UART API at 115200baud 8N1 will provide a simple menu (S2/DIO14 moves to the next menu item and S1/DIO15 selects the current menu item).
    • ​simple_peripheral_oad: Demonstrates on-chip OAD functionality combined with the simple_peripheral example application. This app is configured to be managed and launched by the Boot Image Manager (BIM) example app meaning this project does not include aCCFG section to configure the device at boot and therefore requires that the BIM project is programmed into the device first. See OAD for more info.
    • ​project_zero: Implements a simple Bluetooth low energy peripheral devices with GATT services also demonstrating how to integrate Over the Air (OAD) Download and three custom services. This app is configured to be managed and launched by the Boot Image Manager (BIM) example app meaning this project does not include a CCFG section to configure the device at boot and therefore requires that the BIM project is programmed into the device first. See OAD for more info.

Programming

Via JTAG

The CC135x by default comes up in 2-wire cJTAG mode but does support 4-wire JTAG. There is a sequence that needs to be done in order to get it to 4-wire mode.

JTAG programming is supported with OpenOCD software on the following:

  • GW16122-B via the Gateworks ​GW11033 JTAG dongle attached to the 10-pin JTAG header J6 (make sure the board is powered via the miniPCIe connector; ie in a board powered on or via a USB to miniPCIe adapter plugged into a powered USB port)
  • GW5910-C via IMX6 GPIO

Before attempting to use the Gateworks Jtag programmer sudo rmmod ftdi_sio, without this step programming may fail.

Note that the OpenOCD package from Ubuntu lacks the necessary cc26xx flash driver so we must either build OpenOCD from source manually or use the Gateworks Ubuntu PPA:

  • Installing from Gateworks Ubuntu PPA: 
    sudo add-apt-repository ppa:gateworks-software/packages
sudo apt update
sudo apt install openocd
  • Building from source: 
    apt install build-essential libusb-1.0-0-dev libftdi-dev autoconf libtool pkg-config git
git clone https://github.com/Gateworks/openocd.git
cd openocd
./bootstrap
./configure --enable-imx_gpio --enable-ftdi --enable-sysfsgpio
make install
    • The Gateworks OpenOCD git repo also has some additional patches we found necessary to make it reliably program the CC135x.

You will also need OpenOCD interface / board config files:

  • If using a GW16122-B+ and a GW16042 JTAG dongle plugged into J6: CollapsibleStart(Config file) 
    cat << EOF > gw16122.cfg
#
# Gateworks GW16122 CC1352P JTAG interface
#
# Layout: FTDI FT2232H
#   ADBUS0 TCK
#   ADBUS1 TDI
#   ADBUS2 TDO (input)
#   ADBUS3 TMS
#   ADBUS4 nTRST
#   ADBUS5 nSRST
#   ADBUS6 OE (active high) for TRST, TDI, TMS, TCK
#   ADBUS7 NC
#   ACBUS0-7 NC
#   BDBUS0 RXD
#   BDBUS1 TXD (input)
#
interface ftdi
ftdi_device_desc "USB-JTAG"
ftdi_vid_pid 0x0403 0x6010
ftdi_layout_init 0x0058 0x007b
ftdi_layout_signal nSRST -oe 0x0020

adapter_khz 10000
transport select jtag
source [find target/ti_cc13x2.cfg]
reset_config none
EOF

CollapsibleEnd

  • Program firmware.out: 
    openocd -f ./gw16122.cfg -c "program firmware.out verify reset exit"
  • If using a GW5910* C revision or greater: CollapsibleStart(Config file) 
    cat << EOF > gw5910.cfg
#
# GW5910 CC1352P JTAG Interface mapping
#
# PAD_DISP0_DAT14__GPIO5_IO08 TMS gpio-136
# PAD_DISP0_DAT15__GPIO5_IO09 TCK gpio-137
# PAD_DISP0_DAT16__GPIO5_IO10 TDO gpio-138
# PAD_DISP0_DAT17__GPIO5_IO11 TDI gpio-139
#
# PAD_DISP0_DAT23__GPIO5_IO17 RST# gpio-145
# PAD_EIM_A25__GPIO5__IO02 BOOT gpio-130

interface imx_gpio
transport select jtag
imx_gpio_peripheral_base 0x020ac000
imx_gpio_speed_coeffs 100000 5
imx_gpio_jtag_nums 9 8 11 10
imx_gpio_trst_num 17

adapter_khz 20000
source [find target/ti_cc13x2.cfg]

jtag_ntrst_delay 0
jtag_ntrst_assert_width 0
adapter_nsrst_delay 0
adapter_nsrst_assert_width 0

reset_config trst_only
EOF

CollapsibleEnd

  • Program firmware.out: 
    openocd -f ./gw5910.cfg -c "program firmware.out verify reset exit"

Via Serial bootloader

The TI SimpleLink products have a ROM bootloader that supports 2-pin UART or 4-pin SPI via a serial protocol defined in the Techical Reference Manuals (TRM):

A .bin file or .hex file is required when using the bootloader. These can be created with the gcc compiler:

  • Specify env var for TI GCC compiler (example: CCSv9) 
    export GCC_ARMCOMPILER=~/ti/ccs910/ccs/tools/compiler/gcc-arm-none-eabi-7-2017-q4-major
  • Create a bin file from out: 
    $(GCC_ARMCOMPILER)/bin/arm-none-eabi-objcopy -S --gap-fill 0xff -O binary firmware.out firmware.bin
  • Create a hex file from out: 
    $(GCC_ARMCOMPILER)/bin/arm-none-eabi-objcopy -S -O ihex firmware.out firmware.hex

This can be used to program application firmware as long as the CCFG registers define the configuration to keep the bootloader enabled:

  • GW16122-B+ connects the FTDI cbus0 to CC1352_RST# and the FTDI cbus1 to CC1352_DIO20 thus those can be used to reset and configure the serial bootloader with the following CCFG: 
    #define SET_CCFG_BL_CONFIG_BOOTLOADER_ENABLE    0xC5    // Enable ROM boot loader
#define SET_CCFG_BL_CONFIG_BL_LEVEL             0x1     // Active high to open boot loader backdoor
#define SET_CCFG_BL_CONFIG_BL_PIN_NUMBER        20      // DIO20
#define SET_CCFG_BL_CONFIG_BL_ENABLE            0xC5    // Enabled bootloader backdoor
  • In your main application you can use DIO19 for RTS if needed

There are a number of software resources available for programming in this fashion however if you program firmware that does not have the above CCFG configuration you will no longer be able to access the bootloader and will have to use JTAG. Therefore using JTAG programming is likely recommended recommended.

Once such application you can use out-of-the-box for updating firmware via serial bootloader is cc2538-bsl.py.

Examples:

  • GW16122-B: 
    apt install python python-serial python-magic python-pip
pip install intelhex # intelhex required if using .hex files
git clone https://github.com/Gateworks/cc2538-bsl.git
cd cc2538-bsl
./cc2538-bsl.py -p /dev/ttyUSB0 -b 1000000 -e -w -v firmware.hex
    • You will need to configure and toggle chip reset and bootloader-enable manually via FTDI gpio. Contact support@… for details

As the GW5910-C can be programmed via OpenOCD via imx-gpio JTAG there really isn't any reason to want to use the Serial bootloader.

Over the Air Download (OAD) / Over The Air (OTA)

For generic OTA, the idea is to transmit FW over the air to the CC13xx. After finishing FW transmitting, the OTA application will check FW integrity and if the downloaded FW Is correct, the application should notify bootloader and reboot for bootloader to move FW to CC13xx to restart.

TI provides OTA examples in the BLE Stack, TI 15.4 Stack, and EasyLink example projects. This works by having a Boot Image Manager (BIM) which resides on the OAD target and is responsible for loading new images after a download has completed. The BIM executes on a device reset and determines if a firmware update needs to be applied. If no update is being applied then the BIM will transfer program execution to the main application image. Note that TI's BLE-Stack OAD Profile does not implement or perform any security or authentication mechanisms as part of the firmware update process - if this is something you need you will need to implement this yourself or look for another OAD process. TI recommends applications use Bluetooth LE Secure Connections (LESC) with Man-in-the-Middle (MITM) protection with peer devices when performing wireless firmware updates although the use of the LESC feature does not itself guarantee image authenticity.

BIM is a fully executable application that is independent of any high level protocol stack or user application and is guaranteed to run on boot. BIM enables power loss fault tolerance during OAD... if the device power is lost during OAD the BIM will still be able to run from reset and revert to a working image if one is available. The BIM is intended to reside permanently on the chip and cannot be updated via the OAD process. BIM executes before kernel initialization takes place so the design is single threaded and bare metal. Hardware access is accomplished through driverlib. As a separate application, BIMI requires its own interrupt vector table and linker file and will produce a fully executable image that must be merged with the user application image in order to create a functional OAD enabled firmware system.

The TI BIM comes in two forms: 'on-chip' for Storing the firmware update in the internal flash and 'off-chip' for storing the firmware image in an external FLASH chip. Note that the Gateworks CC135x products do not have external flash devices connected to the CC135x however one could implement their own OAD process that uses the baseboard's mechanisms for storage and firmware update (ie JTAG).

To create an OAD image you use the TI OAD Image Tool which is distributed in both source and binary form (Linux, Windows, Mac) and is run as a post build step to an OAD application. The tool located in <SDK_DIR>/tools/common/aod/oad_image_tool.py will generate an output binary file named <app_name>_oad.bin.

For more info on this process please consult the ​BLE5-Stack Users's Guide

References:

Identifying TTYs

The FTDI USB UART chips are supported by a the 'ftdi-sio' kernel driver/module that registers /dev/ttyUSB<n> devices.

Because this is a commonly used chip including the one used in the Gateworks JTAG dongles it can be helpful to have some commands to help you identify which tty is which device:

  • List all USB devices that provide a ttyUSB: 
    for i in $(ls -1d /sys/bus/usb/devices/*); do [ -r $i/interface ] && { echo $(cat $i/interface):$(ls -d $i/ttyUSB* 2>/dev/null); }; done
  • List only GW16122 devices and their TTY: 
    for i in $(ls -1d /sys/bus/usb/devices/*); do [ -r $i/interface ] && { echo $(cat $i/interface):$(ls -d $i/ttyUSB* 2>/dev/null); }; done | grep GW16122
  • List GW16122 serial numbers: 
    usb-devices | grep -A1 GW16122

Serial UART Access

The GW5910 has the IMX6 UART3 connected as full-duplex to the CC1352P thus you can access it via /dev/ttymxc2

The GW16122 has an FTDI FT231X USB Full Speed UART connected to it via the following pinout:

  • FT231X TXD -> DIO_12 (UART_RX)
  • FT231X RXD <- DIO_13 (UART_TX)
  • FT231X RTS# -> DIO_18 (UART_RTS)
  • FT231X CTS# <- DIO_19 (UART_CTS)

Hardware flow control (RTS/CTS) is only necessary if you load code onto the CC1352P that uses it.

There are several Linux terminal programs that can aid you in communicating with the UART such as screen, picocom, minicom.

Examples: 

# Find the tty associated with the GW16122 device in your system
TTY=/dev/$(for i in $(ls -1d /sys/bus/usb/devices/*); do [ -r $i/interface ] && { [[ "$(cat $i/interface)" =~ "GW16122" ]] && basename $(ls -d $i/ttyUSB*); }; done)
echo $TTY
apt install picocom
picocom --baud 115200 $TTY
  • make sure you point to the correct /dev/ttyUSB* device managed by the ftdi_sio driver

DTR

Some board revisions will reqire DTR to be asserted before the board will come out of reset. DTR is part of a UART policy dating back to the modem days where by default 'HUP' is enabled which will send a 'hangup' signal (via DTR or data-terminal-ready) when the last process closes the tty. In essence DTR# is driven high when no processes have the UART device open and driven low when any process has the UART device open. Unfortunately this is the wrong polarity to 'just work' in an obvious manner.

You can manually control DTR in a number of ways:

  • use picocom (see below) which allows you to toggle DTR via control commands
  • use stty to disable HUP which will release DTR# and drive it high letting the CC1352P out of reset but not that terminal programs may put it back in reset if they control DTR. 
    # Find the tty associated with the GW16122 device in your system
TTY=/dev/$(for i in $(ls -1d /sys/bus/usb/devices/*); do [ -r $i/interface ] && { [[ "$(cat $i/interface)" =~ "GW16122" ]] && basename $(ls -d $i/ttyUSB*); }; done)
echo $TTY
stty -F $TTY hup
  • write your own UART code that uses the TIOCMBIS and TIOSMBIS ioctl to manually control the modem signals:
    • with a C application use an ioctl on the tty from termios.h: 
      cat << EOF > dtr.c
#include <errno.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

#include <sys/ioctl.h>
#include <sys/types.h>
#include <sys/stat.h>

int main(int argc, char **argv)
{
        int fd, line, assert;
        const char *tty;

        if (argc < 2) {
                fprintf(stderr, "usage: %s <ttydev> <0|1>\n", argv[0]);
                exit -1;
        }

        tty = argv[1];
        assert = atoi(argv[2]);

        /* open serial port */
        fd = open(tty, O_RDWR | O_NOCTTY);
        if (fd == -1) {
                perror("open");
                exit -errno;
        }

        /* perform IOCTL to set DTR */
        line = TIOCM_DTR;
        printf("%s: %s DTR#\n", tty, assert ? "assert" : "deassert");
        if (ioctl(fd, assert ? TIOCMBIS : TIOCMBIC, &line) == -1) {
                perror("ioctl");
                close(fd);
                exit (-errno);
        }
        close(fd);

        return 0;
}
EOF

      gcc -c dtr.c -o dtr
chmod +x dtr
# Find the tty associated with the GW16122 device in your system
TTY=/dev/$(for i in $(ls -1d /sys/bus/usb/devices/*); do [ -r $i/interface ] && { [[ "$(cat $i/interface)" =~ "GW16122" ]] && basename $(ls -d $i/ttyUSB*); }; done)
echo $TTY
# make sure a HUP will not be sent when a process does not have control over the TTY
stty -F $TTY -hup
# assert DTR# (drive low; hold part in reset)
./dtr $TTY 1
# deassert DTR# (drive high; release part from reset) 
./dtr $TTY 0
    • use python-serial via a python script: 
      cat << EOF > dtr
#!/usr/bin/env python

import serial
import string
import sys

if len(sys.argv) < 3:
    print("usage: %s <ttydev> <0|1>\n" % sys.argv[0])
    exit(-1)

dev=sys.argv[1]
lvl=string.atoi(sys.argv[2])

if lvl:
    print("%s: assert DTR#\n" % dev)
else:
    print("%s: deassert DTR#\n" % dev)
ser = serial.Serial(dev)
ser.isOpen()
ser.setDTR(lvl)
ser.close()
EOF

      apt install python python-serial
chmod +x dtr
# Find the tty associated with the GW16122 device in your system
TTY=/dev/$(for i in $(ls -1d /sys/bus/usb/devices/*); do [ -r $i/interface ] && { [[ "$(cat $i/interface)" =~ "GW16122" ]] && basename $(ls -d $i/ttyUSB*); }; done)
echo $TTY
# make sure a HUP will not be sent when a process does not have control over the TTY
stty -F $TTY -hup
# assert DTR# (drive low; hold part in reset)
./dtr $TTY 1
# deassert DTR# (drive high; release part from reset) 
./dtr $TTY 0

DIO / GPIO Configuration

The DIO / GPIO / ADC Configuration is done through pin muxing in software and the PORTID argument.

Please read more in the ​technical reference manual, on page 1074, section 13.8

Third Party Software

  • Contiki - Open Source OS for IoT, utilizing 6LoWPAN, can run on Sub-1GHz
  • Thingsquare - Based on Contiki, exposes through REST API Click here
  • WiSun Click Here
  • Thread - Thread is an IPv6-based, low-power mesh networking technology for IoT products, intended to be secure and future-proof. Thread will not work on the Gateworks GW16122 because it is not designed for Sub-1Ghz. Based on 6LowPan. Based on 802.15.4 2.4GHz.
  • KNX - Open protocol Aimed at building automation. Operates on many physical layers.
  • Ti Simple 6LoWPAN Mesh End-Node Improves Network Performance Reference Design ​http://www.ti.com/tool/tida-010003
  • Wirepas: Fairly close to WiSun ​https://wirepas.com/

Wi-Sun

The TI 15.4 stack leverages WiSun-based frequency hopping and can be used on CC1350 and CC1352. Some 3rd parties capable of implementing a Wi-SUN stack are Adsol-Nissin and Procubed.

Please use the E2E Ti Forums for more information ​TI E2E Forums

Thingsquare

* Note below testing done with rev A with CC1350. GW16122-B uses a CC1352P which has not been tested with Thingsquare but should operate the same *

​Thingsquare is a software company that offers customized software for the chip on the GW16122, the Ti CC135x. This software allows for the use of a smartphone app to monitor and control sensors through the Thingsquare cloud/backend. A ​REST API is available as well.

A brief description of what is happening in the demo below:

  • A Gateworks GW16122 is acting as the Thingsquare IoT gateway on the Gateworks SBC
    • The GW16122 exposes a few serial interfaces (/dev/ttyACM0 and /dev/ttyACM1) which are then used for the SLIP interface
    • dnsmasq acts as a DNS server for the slip interface
    • The sl0 uses PTP for the DNS
    • The SLIP requires some routing and forwarding between interface sl0 and eth0
    • The firmware on the GW16122 pushes data up to the Thingsquare cloud
  • The CC1350 Sensor tag is reporting back to the Gateway and pushing it's information up to the cloud

Hardware required: All items purchased seperately

  • Gateworks ​Ventana or Newport Single Board Computer
  • Gateworks ​GW16122 IoT Card
  • Gateworks GW10124 900Mhz Antenna
  • Gateworks ​GW10074 MMCX to SMA Female Adapter Cable
  • ​Ti CC1350 Sensor Tag
    • Gateworks SBC and GW16122 are the 'collector' in the system. This CC1350 !Sensor !Tag becomes the 'sensor' for development.
  • USB to Mini-PCIe Adapter
    • This allows the Gateworks GW16122 to be connected to a Laptop / PC for programming purposes.
    • ​Option #1 - Amazon - Requires rubberband to hold GW16122 in

The following instructions assume the developer is familiar with using the Gateworks SBC & GW16122 and programming it using the instructions given elsewhere on this wiki

Setup Instructions

  1. Flash the GW16122 and sensor nodes with Thingsquare Firmware located ​here
    1. GW16122 Firmnware is labeled as CC1350 Launchpad Serial USB Access Point (US / 915 MHz)
    2. Sensor Firmnware is labeled as CC1350 Sensortag
  2. Insert a programmed GW16122 into a Gateworks SBC Mini-PCIe slot that has USB support
  3. Load Gateworks SBC Ubuntu 16.04 Software
    1. Install Ubuntu Xenial 16.04 with the instructions Ventana 16.04
    2. Confirm /dev/ttyACM0 and /dev/ttyACM1 exist on the Gateworks SBC in software
    3. Confirm an ethernet cable is connected to the Gateworks SBC connected to a LAN that has internet access via a WAN
    4. Install dnsmasqapt-get install dnsmasq
    5. Add the following lines to the end of the /etc/dnsmasq.conf file: 
      interface=sl0
listen-address=127.0.0.1
listen-address=172.16.0.1
    6. Create a script or add to /etc/rc.local to be ran after the board boots each time: 
      modprobe slip
stty -F /dev/ttyACM0 115200
sleep 3
slattach -L -s 115200 -p slip /dev/ttyACM0 &

sleep 10
ifconfig sl0 172.16.0.1 dstaddr 172.16.0.2
ifconfig sl0 mtu 600

echo 1 > /proc/sys/net/ipv4/ip_forward

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i eth0 -o sl0 -j ACCEPT
iptables -A FORWARD -i sl0 -o eth0 -j ACCEPT
systemctl start dnsmasq.service
    7. After script is installed, either run the script or reboot the board if the script will run automatically
  4. Connect the Gateway / Sensor either using a mobile phone or network browser, explained below:
    1. Utilize the Thingsquare website to connect both sensor and Gateway to cloud with the following instructions using a mobile phone: ​http://www.thingsquare.com/docs/get-started-with-starter-kit/
      1. Important Note: Checking the box 'Remote Access' is important to connect the device to the Thingsquare backend and available when logging into the app/browser with user account
    2. You can use the website ​https://developer.thingsquare.com/web/ to access the devices from a PC browser on the same LAN. Create a Thingsquare account.
      1. Use the bottom menu icon, 'Nearby' to be sure you can discover the device on the LAN
      2. Important Note: Checking the box 'Remote Access' is important to connect the device to the Thingsquare backend and available when logging into the app/browser with user account

Screenshots:

Troubleshooting:

  1. Verify traffic on sl0 interface with tcpdump, example below: 
    root@xenial-ventana:~# tcpdump -i sl0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on sl0, link-type RAW (Raw IP), capture size 262144 bytes
17:04:02.516758 IP 172.16.0.2.10323 > ec2-52-211-110-245.eu-west-1.compute.amazonaws.com.https: Flags [P.], seq 12805:13034, ack 371767140, win 500, length 229
17:04:02.682914 IP ec2-52-211-110-245.eu-west-1.compute.amazonaws.com.https > 172.16.0.2.10323: Flags [.], ack 229, win 54500, length 0
17:04:02.685640 IP ec2-52-211-110-245.eu-west-1.compute.amazonaws.com.https > 172.16.0.2.10323: Flags [P.], seq 1:102, ack 229, win 54500, length 101
17:04:02.941381 IP 172.16.0.2.10323 > ec2-52-211-110-245.eu-west-1.compute.amazonaws.com.https: Flags [P.], seq 229:330, ack 102, win 500, length 101
17:04:03.148806 IP ec2-52-211-110-245.eu-west-1.compute.amazonaws.com.https > 172.16.0.2.10323: Flags [.], ack 330, win 54500, length 0
17:04:12.109625 IP 172.16.0.2.10323 > ec2-52-211-110-245.eu-west-1.compute.amazonaws.com.https: Flags [P.], seq 330:479, ack 102, win 500, length 149
17:04:12.276629 IP ec2-52-211-110-245.eu-west-1.compute.amazonaws.com.https > 172.16.0.2.10323: Flags [.], ack 479, win 55500, length 0
17:04:18.591617 IP 172.16.0.2.10323 > ec2-52-211-110-245.eu-west-1.compute.amazonaws.com.https: Flags [P.], seq 479:580, ack 102, win 500, length 101
17:04:18.756148 IP ec2-52-211-110-245.eu-west-1.compute.amazonaws.com.https > 172.16.0.2.10323: Flags [.], ack 580, win 55500, length 0
17:04:18.772626 IP 172.16.0.2.10323 > ec2-52-211-110-245.eu-west-1.compute.amazonaws.com.https: Flags [P.], seq 580:649, ack 102, win 500, length 69
17:04:18.941914 IP ec2-52-211-110-245.eu-west-1.compute.amazonaws.com.https > 172.16.0.2.10323: Flags [.], ack 649, win 55500, length 0
^C
11 packets captured
11 packets received by filter
0 packets dropped by kernel
root@xenial-ventana:~#
  2. Verify dnsmasq is running: 
    systemctl status dnsmasq.service
  3. Verify dnsmasq is listening on the right address 172.16.0.1 
    root@xenial-ventana:~# netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      824/dnsmasq     
tcp        0      0 172.16.0.1:53           0.0.0.0:*               LISTEN      824/dnsmasq     
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      645/sshd        
tcp6       0      0 ::1:53                  :::*                    LISTEN      824/dnsmasq     
tcp6       0      0 :::22                   :::*                    LISTEN      645/sshd        
udp        0      0 127.0.0.1:53            0.0.0.0:*                           824/dnsmasq     
udp        0      0 172.16.0.1:53           0.0.0.0:*                           824/dnsmasq     
udp        0      0 0.0.0.0:68              0.0.0.0:*                           584/dhclient    
udp6       0      0 ::1:53                  :::*                                824/dnsmasq     
root@xenial-ventana:~#
  4. Verify sl0 interface exists and is up: 
    root@xenial-ventana:~# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:d0:12:9b:f2:af  
          inet addr:172.24.22.173  Bcast:172.24.255.255  Mask:255.240.0.0
          inet6 addr: fe80::2d0:12ff:fe9b:f2af/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:8962 errors:0 dropped:0 overruns:0 frame:0
          TX packets:483 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:665276 (665.2 KB)  TX bytes:58003 (58.0 KB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:172 errors:0 dropped:0 overruns:0 frame:0
          TX packets:172 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:13066 (13.0 KB)  TX bytes:13066 (13.0 KB)

sl0       Link encap:Serial Line IP  
          inet addr:172.16.0.1  P-t-P:172.16.0.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:600  Metric:1
          RX packets:307 errors:0 dropped:0 overruns:0 frame:0
          TX packets:345 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:10 
          RX bytes:42795 (42.7 KB)  TX bytes:24061 (24.0 KB)
  5. Verify you can ping www.google.com from the Gateworks SBC command line

References:

Contiki-ng

Contiki-NG is an open-source, cross-platform operating system for Next-Generation IoT devices. It focuses on dependable (secure and reliable) low-power communication and standard protocols, such as IPv6/6LoWPAN, 6TiSCH, RPL, and CoAP. Contiki-NG comes with extensive documentation, tutorials, a roadmap, release cycle, and well-defined development flow for smooth integration of community contributions.

Installing the Contiki-ng Docker image

Compiling Contiki-ng examples is made easy through use of their docker container, this saves manually configuring the build environment.  Even if you're unfamiliar with docker this procedure is quite simple.  

Official Contiki-ng wiki instructions: ​https://github.com/contiki-ng/contiki-ng/wiki/Docker

  • Installing Docker can be done using apt: 
    sudo apt-get install docker-ce

Official instructions can be found here: ​https://docs.docker.com/engine/install/ubuntu/

  • Once Docker is installed add your user to the docker group: 
    sudo usermod -aG docker <your-user>

After log out and log back in.  Missing this step will result in errors moving forward.  

  • Download the Contiki-ng Docker image: 
    docker pull contiker/contiki-ng

Download and link the Contiki-ng source to the container

Clone the source code from the Contiki-ng github repository: 

git clone https://github.com/contiki-ng/contiki-ng.git
cd contiki-ng
git submodule update --init --recursive

Create an alias to start docker with required arguments and source code bound:   

export CNG_PATH=<absolute-path-to-your-contiki-ng>
alias contiker="docker run --privileged --sysctl net.ipv6.conf.all.disable_ipv6=0 --mount type=bind,source=$CNG_PATH,destination=/home/user/contiki-ng -e DISPLAY=$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix -v /dev/bus/usb:/dev/bus/usb -ti contiker/contiki-ng"

Building the example:

Launch the container by typing contiker, this will use the alias that was previously created.  You will be presented with a new shell, with the $PWD being "/home/user/contiki-ng".

Change directory to the example you would like to build, in this case "hello world": 

cd examples/hello-world/

If you would like to see a list of Simplelink targets: 

make TARGET=simplelink boards

To build for GW16122: 

make TARGET=simplelink BOARD=launchpad/cc1352p-2

The build artifacts are located in this folder: 

/home/user/contiki-ng/examples/hello-world/build/simplelink/launchpad/cc1352p-2/

If you would like to copy them out of your running container start a different shell, "cd" to your destination directory and execute the following command: 

docker cp <container $HOSTNAME>:/home/user/contiki-ng/examples/hello-world/build/simplelink/launchpad/cc1352p-2/<desired file> .

An easier way to gain access to the files is to type "exit" within the container, then navigate to the "contiki-ng/examples/hello-world/build/simplelink/launchpad/cc1352p-2/" directory on your host machine.  

Follow the instructions in the Programming section to flash this firmware to your board.

Using the Hello World example.

Connect your programmed GW16122 to a Gateworks SBC. This will create a /dev/tty interface, in most cases /dev/ttyUSB0.

To view the output from the example: 

stty -F /dev/ttyUSB0 115200
cat /dev/ttyUSB0 &

Example of the expected output: 

Hello, world
Hello, world
Hello, world
Hello, world
Hello, world
Hello, world
Hello, world
Hello, world
Hello, world
Hello, world
Hello, world
Hello, world
Hello, world
Hello, world
Hello, world
Hello, world
Hello, world
Hello, world
Hello, world
Hello, world
Hello, world
Hello, world
Hello, world
Hello, world
Hello, world
Hello, world
Hello, world
Hello, world
Hello, world
Hello, world
Hello, world
Hello, world

Attachments (3)

Download all attachments as: .zip

Note: See TracWiki for help on using the wiki.