Bootstrapping the OpenMote platform

This quick post explains how to compile the OpenMote firmware, available in our GitHub repository, and also how to flash it to an OpenMote-CC2538 board through an UART port using the bootloader backdoor mechanism present in the Texas Instruments CC2538 SoC. In this post we assume that you have an OpenMote-CC2538 board and an OpenBase board connected to a computer through the emulated USB port (using an FTDI chip), as depicted in the next image. By the way, you only need the cable between the ON/SLEEP and GND pins in the OpenBase if the OpenMote-CC2538 board does not enter the bootloader backdoor automatically (if it does not work either, try to short RTS/AD6/DIO6 to GND). We also assume that you are using the Ubuntu 14.04 LTS operating system on your compter, either natively or in a virtual machine. We know the process can be also run under Windows with a little bit of patience, but we have not tried it so far. If you do it, please let us know! :-)

Bootstrapping OpenMote

To start with, you will need to install the toolchain to compile C/C++ code for the ARM Cortex platform and also the Python environment that is used to upload code through the serial port with the cc2538-bsl script. To do it, open a terminal and issue the following commands one after the other:

sudo add-apt-repository -y ppa:terry.guo/gcc-arm-embedded

sudo apt-get update

sudo apt-get dist-upgrade

sudo apt-get install build-essential gcc-arm-none-eabi libnewlib-arm-none-eabi python python-serial

You will also need the C/C++ standard library for the ARM Cortex platform. Unfortunately, the package is not currently available in the standard Ubuntu repositories and, thus, you will need to install it manually. To install it manually, issue the following commands in the same terminal:

wget http://mirrors.kernel.org/ubuntu/pool/universe/libs/libstdc++-arm-none-eabi/libstdc++-arm-none-eabi-newlib_4.8.3-11ubuntu1+4_all.deb
sudo dpkg -i libstdc++-arm-none-eabi-newlib_4.8.3-11ubuntu1+4_all.deb

Once you have installed the required tools, you will need to obtain the OpenMote formware by cloning our GitHub repository. Use the following command to ensure that the cc2538-bsl script under the tools directory is also cloned in the process.

git clone –recursive https://github.com/OpenMote/firmware.git OpenMote/firmware

If you already have the OpenMote firmware repository in your computer then you need to execute the following command to check out the cc2538-bsl script explicitely.

git submodule update –init –recursive

Once you have installed the toolchain and cloned the OpenMote firmware repository in your computer, you are good to go. The next step is compiling and uploading an example project into the target OpenMote-CC2538 board. For that, go to the OpenMote/firmware/projects directory.

cd OpenMote/firmware/projects

There you will see that there are many example projects, e.g., how to use the LEDs, buttons, etc. We will start with the test-leds project, which demonstrates how to blink the LEDs on the OpenMote-CC2538 platform. To compile the project go inside the test-leds/src subdirectory and issue the following command:

cd test-leds/src

make TARGET=cc2538 all

Right after executing this last command you should see the ouput of the Makefile system compiling the different files of the test-leds project. The process is pretty fast but you may notice some warnings caused by the Texas Instruments CC2538 Foundation Firmware. Once completed, you should see a message stating that the building of the test-leds has completed. Once finished, it is time to upload the binary (test-leds.hex) to the OpenMote-CC2538 board. To do it, issue the following command:

make TARGET=cc2538 bsl

This command invokes the cc2538-bsl script, which uploads the firmware to the OpenMote-CC2538 via the UART port. Once the script completes erasing and flashing the board you should see the LEDs of the OpenMote-CC2538 blinking periodically. You are done! Now that you know how to program the OpenMote-CC2538 feel free to explore the other test projects that we have build so far.

IoT Tutorial by Matthias Kovatsch

Yesterday there was an online event about the technology enabling the Internet of Things. The event, which as organized by the Eclipse Foundation, was in the form of a video tutorial presented by Matthias Kovastsch, researcher at ETH Zurich and author of Copper, Erbium, Californium, Scandium and Actinium. The tutorial, named “Connecting Sensor Networks“, presented a holistic overview of the Internet of Things technologies, from the physical layer (IEEE 802.15.4e) to the application (IETF CoAP) layers, and also presenting the open source hardware and software tools that are currently available to implement it. Of course, the OpenMote platform was there together with the Contiki operating system. Notice, however, that there are other open source software implementations of IoT standards, for example OpenWSN. If you missed the event, you can watch the video and the slide deck again here. We hope you enjoy it!

OpenMote at the IoT & Smart Cities PhD School in Lerici, Italy

The OpenMote team has taken part in organizing and sponsorizing the 2nd edition of the IoT & Smart Cities PhD School. The event is organized by Prof. Gianluigi Ferrari and its team from the WASNLab at the University of Parma and takes place every year during a week in the beatiful town of Lerici. This year several people related to the Internet of Things have been present at the school and presented their research activities, including Prof. Karsten Borman, Prof. Andrea Basso, Dr. Simon Duquennoy, Dr. Màrius Monton, Matthias Kovatsch and many others. We, the team at OpenMote, have participated in two activities.

First, the industrial consortium, where we presented our vision for an open source Internet of Things, both hardware and software,  that will foster its development and growth by enabling research, development and learning at various levels; universities and research centers to develop new technologies and to educate new generations of engineers, companies to prototype their solutions and, finally, individuals to develop their personal projects. All of them can count on the OpenMote platform and the open source stacks that are currently available (Contiki, OpenWSN and RiOT) for such purpose.

Second, the hackaton, where the attendees were divided in small groups (8 people) and had to complete an IoT related project in a short ammount of time (4 h). In the hackaton we provided the hardware (OpenMote kits) to develop the projects as well as the assistance to complete them in the required time. Out of three groups that were formed, two used the OpenMote platform for their projects. Using Contiki they were able to create a full 6LoWPAN network where resources (e.g. a temperature sensor) could be read on demand using CoAP. In the next picture you can see the various groups working in their projects while the mentors were providing support.

OpenMote at IoT School 2014

Overall, we have to say that we are very happy of our participation in the IoT & Smart Cities PhD School. It has been an amazing event from all perspectives and we want to thank the organizers and participants for making it so. Let’s hope that we can see each other again next year for the third edition.

The OpenMote team.

OpenMote at IETF90 in Toronto, Canada

From July 20 to July 28, 2014, the Internet Engineering Task Force (IETF) is celebrating its 90th meeting in Toronto, Canada. As last time in London, United Kingdom, the OpenMote team is participating in the Low-Power and Lossy and Networks (LLN) Plugfest, which encompases different IETF working groups like 6TiSCH, 6lo and ROLL. This time more than 20 people participated in the Plugfest with various prestentations and demos for draft standards and hardware/software tools, which are briefly summarized next.

For example, Qin Wang and Tengfei Chang from the University of Science and Technology Beijing, demonstrated the 6TiSCH Operation Sublayer (6top) [draft-wang-6tisch-6top-sublayer-01]. In summary, 6top is a management layer build on top of IEEE802.15.4e TSCH that aims to standardize the way the schedules are build and maintained. On its behalf, Nicola Accettura from UC Berkeley demonstrated On-The-Fly (OTF) scheduling [draft-dujovne-6tisch-on-the-fly-03], as depicted in the next picture. OTF provides mechanisms to dynamically adapt the allocated softcells between two TSCH neighbor nodes in order to satisfy a given set of bandwidth or delay constraints. Pascal Thubert from Cisco and Thomas Watteyne from Dust Networks/Linear Technology demonstrated the use of Proxy ND as a mechanism to reduce the amount of traffic flooded to the LLN by backbone IPv6 infrastructure (draft-thubert-6lowpan-backbone-router-03). The demo presented two Smart Mesh IP networks from Dust Networks connected through two Cisco switches froming a single IPv6 network domain.

IETF90_OnTheFly

Finally, Xavier Vilajosana Universitat Oberta de Catalunya demonstrated an IPv6 Flow Label within a RPL Domain [draft-thubert-6man-flow-label-for-rpl], as you can see in the next picture. IPv6 Flow Label replaces the RPL option inside an IPv6 flow label allowing to save 44 bits in each frame, and provides rules for the root to set/reset the flow label when forwarding packets to the Internet.

IETF90_Flowlabel

Besides the importance of the work presented and demonstrated in the plugfest regarding the standardization of LLN networks, we want to remark that most of these demonstrations made extensively use of the OpenMote platfrom running the OpenWSN stack. However, there are also other operating systems for the IoT being developed today. In that sense, OpenMote has donated an OpenMote bronze kit to RiOT developers in order to accelerate the porting of RiOT to the OpenMote platform.

The OpenMote team.

Flashing OpenMote via UART

Over the last weeks we have received several e-mails asking wether the OpenMote-CC2538 could be flashed via UART using the USB-to-UART (FTDI) port on the OpenBase. The answer was in all cases “Yes, indeed!“, but the devil is hidden in the details (as usual). Let’s start by getting back to the basics.

The Texas Instruments CC2538 supports flashing through UART or SPI under two conditions as described in the CC2538 User’s Guide. First, if no valid image is found in the Flash memory. Second, forcing it by pulling a configurable GPIO pin of port A to a certain level, e.g. high or low, within 10 us from startup. In both cases the CC2538 will enter a bootloader mode where it can be programmed through either port using the commands described in the CC2538 ROM User’s Guide.

Said that, it is technically possible to flash the OpenMote-CC2538 via UART. In fact, it was specifically designed to enable that and there are already certain tools that allow you to do it already: the cc2538-bsl and the cc2538-prog. Both are available at GitHub under an open source license; the first is written in Python and the second is written in C. We have only tried the first one since it is more portable, but we have to say that it works really good!

However, with the two first batches of OpenMote-CC2538 boards that we have shipped so far it impossible to do BSL programming out of the box since the Flash image that we loaded to test them after production has a locked bootloader. We know it’s a setback, but at that time we thought everyone would be using a JTAG probe to program the boards, since it is more convenient for debugging purposes. Of course, we were wrong and we have changed that. Now all the OpenMote-CC2538 boards that we ship come with a Flash image that has an unlocked bootloader.

Thus, for all those that have an OpenMote-CC2538 shipped prior to July 1st you will need a JTAG, for example the Segger J-Link, to upload a Flash image that has the bootloader unlocked. You can find information on how to upload the Flash image using the Segger J-Link here. In the upcoming weeks we will publish a tutorial that describes in detail how to unlock the bootloader and program the OpenMote-CC2538 using the cc2538-bsl, so stay tuned.

The OpenMote team.

OpenMote-CC2538 running FreeRTOS on tickless mode

That’s right, last week we got the OpenMote-CC2538 platform to run FreeRTOS on tickless mode and it only consumes 1.6 uA while it is is LPM2! Here’s a picture to testify it. We know, it has been published on Twitter already, but we believe it is so cool that we needed to post it again. If you also think it’s cool and want to learn more about the FreeRTOS tickless mode running on the OpenMote platfrom, keep reading.

OpenMote Tickless

So what does the tickless demo do? There is a single task that runs every 5 seconds and cycles the red led; the led is on for 250 ms and off for 4750 ms. While there is no other task ready to be run (e.g., because we only have one task and it is sleeping), the operating system enters tickless mode. In tickless mode the operating system disables the periodic tick interrupt that runs at 100 Hz, programs an asynchronous wake-up interrupt when the following task needs to be ready to run and, finally, it  puts the microcontroller to a sleep mode. When the interrupt fires the microcontroller wakes-up and resumes execution. This enables to greatly reduce energy consumption since the microcontroller does not need to necessarily wake up every 10 ms to just increment the tick count. Here’s a video to demonstrate it. We know, it is a very boring video in the world to demonstrate it, but it’s worth it.

 

However, if you plan to use the FreeRTOS tickless mode there is something that you need to know. Different sleep modes consume different energy and require different ammounts of time to wake-up depending on your microcontroller. Thus, the optimal sleep mode is not always the one that consumes the lowest energy; it will depend on the expected sleep time and the time required to wake-up from the selected sleep mode. For example, under LPM0 the CC2538 draws around 2 mA but is able to enter sleep mode and resume code execution immediately (0 us). Contrarily, under LPM1 the CC2538 draws less current (600 uA) but requires 4 us in order to start executing code. Finally, under LPM2 the CC2538 draws 1.6 uA but it requires up to 136 us in order to start executing code. Thus, for sleep times under under ~300 us it is not worth to go to LPM1 and for sleep times under ~3 ms it is not worth to go to LPM2, as you will be spending more energy overall due to the time spent in the transition states. We have already taken that into account and th FreeRTOS tickless port for the OpenMote-CC2538 decides which sleep mode is better according to the expected sleep time. This allows to minimize energy consumption regardless of the taks execution pattern of your application.

In the following days we will publish the (unofficial) FreeRTOS port to the OpenMote-CC2538 platform so that you can play with it. Stay tuned!

The OpenMote team.

PS: By the way, the first most boring video on the Internet to demonstrate asynchronous task scheduling is probably this one (source).

OpenBattery, now with sensors!

After receiving many requests from our customers, we have finally decided to ship the OpenBattery board with the sensors populated. This means that now the OpenBattery board is capable of sensing temperature and relative humidity (Sensirion SHT21), acceleration (Analog Devices ADXL346) and light (Maxim MAX44009) out of the box, no need to get your hands dirty with the soldering iron! By the way, all the sensors are digital and connected to the OpenMote-CC2538 via the I2C bus, which is passed through the XBee pins. Be quick and place your order in our shop before they are gone.

OpenBattery sensors

Celebrating 3 months

Today OpenMote is celebrating its third month of activity. The truth is that our work started a little bit earlier, when we started designing the hardware and talking about creating a small company to sell it, but production and shipping could not start until we were officially incorporated (and as you all know, in Spain these things take a while!). In order to celebrate we want to share two figures with you that are amazing.

First, in these three months of activity we have already shippied more than 100 OpenMote-CC2538 to our customers. It may not seem much to you, but to us it is kind of a magic number. It’s 10² and it sets our next milestone: 1000. Let’s see if we can make that happen before the year ends, but we will need your help to achieve it.

Second, the kits we have sold so far have gone to 15 different counties! These are the countries that have at least one OpenMote kit right now (in alphabetical order): Canada, China, France, Germany, Greece, Ireland, Italy, Portugal, Spain, Russia, Sweeden, Switzerland, United Kingdom, United States of America and Uruguay. How cool is that? The truth is that we could never imagine that such a small idea could spread that fast and that far.

Thanks for trusting us and keep spreading the word.

The OpenMote team.

Building OpenWSN with Scons in Eclipse

This short tutorial aims to provide a quick guide to setup Scons as an external tool to build OpenWSN in Eclipse on a Linux machine. Note that Scons is the building environment provided by OpenWSN which really simplifies setting up the project.

We assume that:

  • An openwsn-fw repository is cloned somewhere in your PC (e.g ~/cool_stuff/openwsn/openwsn_fw)
  • A system variable pointing to openwsn-fw home  exists in the environment (e.g $OPENWSN_HOME)
  • Eclipse is installed
  • Scons is installed
  • You are able to compile OpenWSN from a terminal using Scons.

First, import your project into Eclipse. This can be done by right-clicking on the Project Explorer (left side of eclipse) and selecting Import. Browse to the project directory,

e.g $OPENWSN_HOME/firmware/openos/projects/cc2538/03oos_openwsn

Then we will need to create one or more external builder according to the Scons targets we want to execute. To do so, select the Run-> External Tools -> External Tools Configurations

And on the left side “Program” right click and select new. The following image shows an example configuration to build cc2538 with GNU ARM toolchain.

More external tool configurations can be added, for example:

Apply changes or Run them.

And that’s it, now you can build OpenWSN in Eclipse using Scons.

Getting started with Contiki and OpenMote

Today we are going to explain how to start developing with Contiki using OpenMote hardware. To follow this tutorial you will need the following materials:

  • Computer running GNU/Linux
  • OpenMote bronze kit (available at our shop for 200€)
  • Segger ARM J-Link (available at Mouser for 48€)
  • ARM-JTAG-20-10 adapter (available at Olimex for 4.95€)
  • GitHub account

First of all, we assume that you are using a Debian-based operating system. In particular we provide instructions for the latest long-term support release of Ubuntu (14.04 LTS), which was released in May 2014. However, installation in other Debian-based distributions, e.g. Debian itself, should be similar if not equal. We are also aware that the whole process is available in Windows and MacOS X, since all the tools that we use are available for such operating systems, but at the moment we do not provide instructions for them. Alternatively you can download Instant Contiki, a virtual machine for VMWare Player that contains the operating system (Ubuntu) and all the software required to follow this tutorial. The password is user.

Assuming that you have a working GN/Linux based on Ubuntu, start by installing the tools to cross-compile C/C++ code for ARM microcontrollers. The tools are not available in the default Ubuntu repositories but are available through PPA repositories. Open a terminal and type the following commands.

sudo add-apt-repository ppa:terry.guo/gcc-arm-embedded
sudo apt-get update
sudo apt-get install gcc-arm-none-eabi gdb-arm-none-eabi

In addition take into account that, at the moment of writting this article, the gdb-arm-none-eabi packet is broken in Ubuntu 14.04 LTS since it conflicts with the standard GCC tools. In order to be able to install the package it you will need to issue the following command. Hopefully the issue will be resolved soon and this will no longer be needed.

sudo dpkg --install --force-overwrite /var/cache/apt/archives/gdb-arm-none-eabi_7.6.50.20131218-0ubuntu1+1_amd64.deb

To load code and debug you will also need to download and install the latest version of the Segger J-Link drivers for GNU/Linux. At the time of writing the latest version of Segger J-Link is 4.84.6. For Debian-based distributions you can download the DEB package for 32 bits or 64 bits systems from the Segger website. There are versions for Fedora-based distributions (RPM package), as well as for Windows (EXE) and MacOS X (DMG). To download the software you will need to provide the serial number of your Segger J-Link probe or confirm that you do not have a pirate probe version.

Once the download is complete move to the appropriate folder. To install de DEB package just type the following command and follow the onscreen instructions. Notice that we are using the 64 bit version and that by default the software installs to the /opt/SEGGER/JLink directory.

sudo dpkg --install jlink_4.84.6_x86_64.deb

Finally, you will need two additional packages: git and putty. First, git in order to be able to clone the Contiki repository from GitHub to your computer. Second, putty to be able to communicate with the OpenMote-CC2538 through a serial port. You can install both packages issuing the following commands in a terminal.

sudo apt-get install git putty

Now that you have all the tools required to compile, load and debug code for ARM microcontrollers, we need to obtain the Contiki source code. To do that, go to GitHub and create an account if you do not have one already. After that, go to the Contiki repository in gitHub and create a repository that forks it, as displayed below (top right corner).

Fork Contiki

Once you have forked the Contiki repository into your GitHub account you need to clone it into your computer by issuing:

git clone https://github.com/username/contiki.git ~/Contiki

If you plan on contributing to Contiki you can also add the original Contiki repository as an upstream tracking branch in git. That way you will be able to integrate changes in the Contiki main branch into your own Contiki branch, as well as contribute your changes back to the Contiki main branch by creating a pull request. To do so issue the following commands in a terminal:

git remote add upstream https://github.com/contiki-os/contiki.git
git fetch origin -v
git fetch upstream -v
git merge upstream/master

Now that you have the Contiki source code in your computer is time to compile it. Let’s start with a simple “Hello World” project. Issue the following commands on a terminal:

cd ~/Contiki/examples/hello-world
make TARGET=cc2538dk hello-world

The first command changes the current directory to the Contiki directory where the “Hello World” project resides. The second command triggers the compile of the whole Contiki operating system using its Makefile-based build system.

Compile Contiki

After a certain ammount of time you will see that various files have been compiled and the binaries for the CC2538 generated, as depicted next.

Compiled Contiki

Now that the code is compiled you need to upload it to the OpenMote. Prior to that make sure that the OpenMote is connected to the OpenBase and that the OpenBase is connected to the computer via the USB_FTDI USB port. Also make sure that the OpenBase on/off switch is in the USB_FTDI position. If so, you should see a green led on the OpenBase lighting. Next, make sure that the Segger J-Link is connected to the computer and connected to the OpenBase using the ARM-JTAG-20-10 adapter, as depicted next.

Contiki Setup

Once everything is properly connected you need to open a new terminal and start the Segger GDB Server by issuing the following command:

/opt/Segger/JLink/JLinkGDBServer -device CC2538SF53

This command executes the JLinkGDBserver to debug a CC2538SF53 device, which is the one we use for the OpenMote-CC2538 board. It is mandatory to include the “-device CC2538SF53” parameter since the Segger JLink needs to configure the CC2538 chip for standard JTAG operation (4 wire) instead of the new cJTAG (2 wire). You should see a dialog similar to the one depicted next where the JLinkGDBServer waits for a connection from the GDB client.

JLinkGDBServer

Once the Segger JLinkGDBServer is connected to the target device you need to go back to the other terminal and issue the following command:

arm-none-eabi-gdb

After issuing this command you should see a window like the following. Here GDB is waiting for you to input the commands to load the target code and start debugging.

arm-none-eabi-gdb

Once GDB is executing, issue the following commands one by one in the GDB window:

target remote localhost:2331
monitor interface jtag
monitor speed 5000
monitor endian little
monitor flash download = 1
monitor flash breakpoints = 1
monitor reset
load hello-world.elf

This commands are responsible for configuring the GDB client to talk to the GDB server (the one executing in the other terminal) and loading the “Hello World” machine code compiled for the CC2538 (located in the hello-world.elf file) to the OpenMote. At this point you should see the code loading to the OpenMote, as depicted next.

Loaded GDB

Each command that you execute in the GDB client reflects in the GDB server, as depicted next.

Loaded JLink

Once the code has been successfully loaded into the OpenMote-CC2538 board, launch PuTTY and open the appropriate serial port, probably under the name of /dev/ttyUSBX. In our case the serial port is under /dev/ttyUSB0, as depicted next. The default serial parameters are 115200 bps, 8 bits, no parity, 1 stop bits and no flow control. In addition, remember that to be able to open the serial port PuTTY will need super user privileges (hint: use sudo!).

PuTTY

Once the code has been successfully loaded and PuTTY is connected to the appropriate serial port press the reset button on the OpenMote. You will see three leds fade shortly and a “Hello world” message will be sent through the serial port, as shown next.

PuTTY Contiki

And that’s it, congratulations! You have successfully compiled Contiki and loaded into the OpenMote. In following tutorials we will show how to compile and run more advanced examples.

Powered by WordPress. Designed by Woo Themes