One Essential Linux Kernel Setting

When building a new kernel, be sure to enable CONFIG_IKCONFIG=y.  This will cause the file /proc/config.gz to be generated on the running system.  This is a gzipped version of the original .config file used to build the kernel.  It can be easily viewed on the running system with “zcat /proc/config.gz”.

This can be very handy for trying to figure out what features were built into a kernel running on a test device, especially one you did not build yourself.

Experimenting with the Thread Protocol

This post will be the first of a short series where I will configure Thread networks using platforms from various vendors.  First up is the Thread release 0.6.0 from Freescale.  This is an older version, but I had access to all the source from the Freescale beta website, and it works, so is worth looking at.  Future posts will explore the latest Thread releases from NXP and SiLabs.



I am using two Freescale Tower boards (twrkw24d512).  It should also be possible to use the USB dongle (usbkw24d512), but I believe that needs a separate JTAG adapter to program it, so the tower boards are easier to use.

Image result for twrkw24d512


First, check out my thread_nxp repository from GitHub :

This should create a top-level thread_nxp directory, and an “FSL_Thread_Stack_0.6.0” subdirectory, which is what we’ll be using for this set of tests.

You will also need a copy of the IAR compiler for ARM.  Eval. versions are available.

Simple Network Setup

Thread network

In this test, we’ll create a Thread end device (white circle in above diagram) and a Thread router (blue circle), which will act as the leader.  We’ll test network connectivity between the two boards and explore the commands available from the serial console CLI.

End Device

Plugging in the Tower board should have created an additional virtual COM port, so connect to that now (115N81) with a serial console (e.g. putty) in preparation for seeing the output from when we run the project.

Open the end device project “C:\thread_nxp\FSL_Thread_Stack_0.6.0\Thread\app\thread\thread_end_device\iar\twrkw24d512\thread_end_device_twrkw24d512.eww” in IAR.

Thread device configuration is specified in the file thread_end_device_config.h for each of these examples.

Go ahead and build the project and download it to the Tower board.  If you have connected the serial console you will see this startup message when the application has started running:

SHELL build: Jan 6 2017
Copyright (c) 2014 Freescale
End Device Application Demo
Press a board switch or enter 'startnwk' to create or join a Thread network!
Note that a "help" command is available.

Before experimenting too much here, let’s get the router node (the leader) running:

Thread Router

First, locate the virtual COM port created by the 2nd Tower board inserted.  Connect a serial console (115N81) to this COM port.

Locate and open the project “C:\thread_nxp\FSL_Thread_Stack_0.6.0\Thread\app\thread\thread_router\iar\twrkw24d512\thread_router_twrkw24d512.eww”.  As with the end node project, Thread defines are in the file thread_end_device_config.h (no adjustments are necessary, but you may want to look).

Compile  and run the Thread Router application, and you should see this appear on the serial terminal:

SHELL build: Jan 21 2017
Copyright (c) 2014 Freescale
Router Application Demo
Press a board switch or enter 'startnwk' to create or join a Thread network!
Starting network...
Attaching to Thread network on channel 26
Cannot find an existing network

Created a new Thread network on channel 26 and PAN ID:0xface
Interface 0: 6LoWPAN
 Mesh local address (ML16): fd00:db8::ff:fe00:0
 Mesh local address (ML64): fd00:db8::204:9f03:1841:0f
Node has taken the Leader role


You will notice that the router node has gone ahead and created a new network, and recognized there are no leaders on that network, so has made itself the leader.

Adding the End Node to the Network

We now need to start the network on the end node with the “startnwk” command, you should see output in the terminal as below:

$ startnwk

Starting network...
Attaching to Thread network on channel 26
Attached to network with PAN ID: 0xface
Node started as Polling End Device
Interface 0: 6LoWPAN
 Mesh local address (ML16): fd00:db8::ff:fe00:01

OK, so at this point we have both nodes joined to the same network.  Let’s use the ifconfig command to see what IP addresses have been assigned to each node.

On the router board, run “ifconfig all”.  On my  board, this gives the output below:

$ ifconfig all
THREAD Configuration

Interface 0: 6LoWPAN
 Link local address: fe80::204:9f03:1841:0f
 Link local address: fe80::ff:fe00:0
 Mesh local address (ML16): fd00:db8::ff:fe00:0
 Mesh local address (ML64): fd00:db8::204:9f03:1841:0f

Running the same command on my end node board gives this:

$ ifconfig all
THREAD Configuration

Interface 0: 6LoWPAN
 Link local address: fe80::204:9f0e:7061:1c
 Link local address: fe80::ff:fe00:01
 Mesh local address (ML16): fd00:db8::ff:fe00:01

Why so many addresses?  Let’s try to explain.

Link Local vs. Mesh Local Addresses

Link local addresses are used if you want to connect to a node only 1 hop away.  Mesh local addresses are used if you want to reach a node more than 1 hop away, however mesh local addresses are never routed beyond the Thread network (i.e. can never make it to the outside Internet).  Link local addresses here are like the “192.168.x.x” addresses in IPV4.

Ping Testing

Since our network is super-simple, trying to ping one board from another should work with either the link local or mesh local addresses.  Let’s try it.  On the router node, run “ping6 -c 5 <end node link local addr>.  On my setup, I see these results:

$ ping6 -c 5 fe80::ff:fe00:01
Pinging fe80::ff:fe00:01 with 32 bytes of data:
Request timed out
Reply sequence number not matching
Reply from fe80::ff:fe00:01: bytes=32 time=451ms
Request timed out
Reply sequence number not matching
Reply from fe80::ff:fe00:01: bytes=32 time=496ms
Request timed out

$ Reply from fe80::ff:fe00:01: bytes=32 time=2480ms

OK, we are getting some connectivity, but not the exact results we expect.  I’ll need to spend some time investigating this and will hopefully post the answer in a future post.

Similarly, you should be able to ping the router node from the end node.  This worked on my system, but did have the sequence number problem shown above that needs to be investigated.

Socket Communication

Let’s now try sending data from one board to another using sockets and UDP.  Fortunately the router application has already set up a socket to listen on (see APP_InitSocketServer in router_app.c).  This is setup to receive UDP datagrams on port 1234.  The receive callback handler interprets the data as plain text commands (see APP_SocketClientRxCallback in router_app.c).

With both the router and end device running, and the network joined, run these commands on the end device to create a socket and send the “Temp” command.

$ socket open udp fd00:db8::ff:fe00:0 1234 6
Opening Socket... OK
Socket id is: 0
$ socket send 0 Temp
Command was sent

The leader should receive the Temp command, and display the IP address it came from:

Temp From IPv6 Address: fd00:db8::ff:fe00:01




IoT Protocols CoAP – Part 3

In this post we extend the existing temperature server to support being an observable resource.  In this scheme the resource sends out a new value whenever required, the server does not need to poll for new messages.  The message sent could be periodic (sensor reading every second), or if a sensor state has changed.  Combined with the efficiency of the CoAP protocol, this would be a very streamlined way to collect data from sensors.

Making a Resource Observable

This is quite easy using the TxThings library we’ve been using.  Just create the resource as usual, and set the observable property to True.  Then, each time you want to broadcast a new state, just call self.notify().

Here’s a basic example of an observable temperature sensor, based on the temperature sensor code we’ve been developing.  It derives from our previous TempResource class we’ve developed earlier.  Full code is at

class ObservableTempResource(TempResource):
 Example CoAP server that implements an observable resource (temperature).
 def __init__(self):
    self.visible = True
    self.observable = True

def notify(self):
    # send a response every second
    reactor.callLater(1, self.notify)

Observing the Resource

Unfortunately the TxThings library does not yet have support for being an observer, so the above code can be tested by installing the Copper Plug-in for FireFox.

copper plugin screenshot

Browse to the observable temperature resource (e.g. coap:// and press the observe button, and you should see new temperature values coming in every one second.

Have any readers been using observable resources in real projects?  If so, how’d they work out?

IoT Protocols – CoAP – Part 2

In the previous posting we designed code for a simple CoAP client and server.  In this post we’ll extend on that code.


In terms of communications protocols, discovery is the process whereby clients can “discover” the various properties provided by the server.  Discovery is absent from some of the older telemetry protocols (e.g. MODBUS), and it’s a very desirable feature.  Without automated discovery, the client will have to be informed of the server’s capabilities by some other means, e.g. manual provisioning or reading in a configuration file for the device etc.  Automatic provisioning by discovery is much quicker and reliable.

CoAP Support For Discovery

A client can discover properties about a server by issuing a CoAP GET to the URL:



If we now switch to the files under the 01_discovery directory of the GitHub Project and run the new on one machine, then from another machine, run the CoAP GET client with args to query resources, we see:

2016-06-13 06:15:39+0000 [-] Log opened.
2016-06-13 06:15:39+0000 [-] Coap starting on 5683
2016-06-13 06:15:39+0000 [-] Starting protocol <txthings.coap.Coap instance at 0x966940>
2016-06-13 06:15:57+0000 [Coap (UDP)] Received 'T\x01\x8f\xe5\x00\x00:\x94\xbb.well-known\x04core' from
2016-06-13 06:15:57+0000 [Coap (UDP)] Incoming Message ID: 36837
2016-06-13 06:15:57+0000 [Coap (UDP)] New unique CON or NON message received
2016-06-13 06:15:57+0000 [Coap (UDP)] Request doesn't pertain to earlier blockwise requests.
2016-06-13 06:15:57+0000 [-] </temperature>;title="Temperature Resource";units="degrees C"
2016-06-13 06:15:57+0000 [Coap (UDP)] Preparing response...
2016-06-13 06:15:57+0000 [Coap (UDP)] Token: 00:00:3a:94
2016-06-13 06:15:57+0000 [Coap (UDP)] Sending response, type = NON (request type = NON)
2016-06-13 06:15:57+0000 [Coap (UDP)] Sending message to
2016-06-13 06:15:57+0000 [Coap (UDP)] Message 'TE5\xf0\x00\x00:\x94\xc1(\xff</temperature>;title="Temperature Resource";units="degrees C"' sent successfully

This shows that the CoAP server supports the single resource /temperature and a human readable representation “Temperature resource”.  Additionally some metadata is returned by the discovery:

units="degrees C"

Metadata like this can be added with calls addParam() member of a resource class in the TxThings Python CoAP library.

Resource Details

The above example for the data on the resource discovered is very minimal; what else does CoAP support?

According to the CoAP spec, servers should support the CoRE link format.  The CoRE link format is described in this RFC and we may examine it in detail in a later post.

Next Post

Next time we’ll look at observable resources, which are resources that notify clients when their data changes.

Got any feedback?  Are you using CoAP in practice?  Pls. leave a comment.


Special thanks to Maciej Wasilak for answering some of my questions about his TxThings library.


IoT Protocols – CoAP – Part 1

In this article I’ll look at the CoAP protocol, with sample code for a server and a client.  CoAP is designed to run on small devices; by default it uses UDP and has efficient binary headers, so most data can be contained in a single packet without fragmentation.

It is also designed to follow the REST model, so supports verbs such as GET, POST, DELETE etc.

To further reduce traffic, messages can either be confirmable (an ACK must be sent by the recipient), or non-confirmable (fire and forget).  The combination of UDP and non-confirmable messages sounds ideal for time vartying sensor readsings in system with a cell modem, where you pay per byte transferred.  Using this combination, a sensor reading could be transmitted in as little as a single UDP message.

Additional features of CoAP include discovery, observable messages and security via DTLS (examined in future posts).

Sample CoAP Request

The “on the wire” bytes for a CoAP GET of reading the value “temperature” from a remote node is shown below:

CoAP request

The header contains:

  • Two bits for version number (01 in this case)
  • Two bits for message type (non-confirmable in this case).  Possible message types are Confirmable (0), Non-confirmable (1), Acknowledgement (2), or Reset (3)
  • Four bits for the token length (4 in this case).  The token is described below.
  • One byte for the “code”.  This is like the HTTP verb (GET in this case)
  • Two bytes for the message ID.  The message ID is used to detect duplicate messages

After the header we have:

  • A token 0x0000ef8e, used to correlate requests and responses.  In this example the token is 4 bytes long.  The token can be 0 to 8 bytes in length
  • Four bits containing an option delta – the difference between this option and the last.  In this example the option is 11 decimal = a Uri path.  Possible values for the option are listed in
  • Four bits for the length of the option (1011 = 11 bytes in this case)
  • The option itself.  In this case the option is a Uri path, and the 11 byte value is “temperature”

Sample CoAP Response

The “on the wire” bytes for the response to the above GET is:

CoAP response

The header contains:

  • Two bits for version number (01 in this case)
  • Two bits for message type (non-confirmable in this case)
  • Four bits for the token length (4 in this case)
  • One byte for the “code”.  This is like the HTTP response code, and is 0x54 in this case (see that broken up into nibbles this is 02 05 (== HTTP response code “content”).  The full range of values for this field is listed at
  • Two bytes for the message ID
  • Four bytes for the token 0x0000ef8e.  Note this value matches the token in the request
  • A single byte 0xff to indicate end of options
  • The payload itself, ASCII bytes “33.8” to indicate 33.8 degrees C

Sample Code

This code is all stored at my GitHub page under

Code below is from the 00_simple_example directory.

Here is an example server written in Python.  I am using the txThings Python CoAP library.  This server will return the ambient temperature in degrees C.

import sys

from twisted.internet import defer
from twisted.internet import reactor
from twisted.python import log

import txthings.resource as resource
import txthings.coap as coap

import platform
import os
import random

class TempResource(resource.CoAPResource):
    Example CoAP server to return the current ambient temperature.
    No 01_discovery or any other advanced features are supported in
    this example.

    def __init__(self):
        self.addParam(resource.LinkParam("title", "Temperature resource"))

        # Disable 01_discovery for now, we'll cover that next
        # self.visible = True

    # noinspection PyUnusedLocal
    def render_GET(self, request):
        temp = self._get_temperature()
        response = coap.Message(code=coap.CONTENT, payload='%.1f' % temp)

        return defer.succeed(response)

    def _get_temperature():
        Temperature is obtained via the embedded board's tshwctl utility, it outputs both
        CPU & ambient temperature in this format:

        this function returns the ambient temperature as a float.

        # If running on real hardware, read from onboard temperature sensor
        # otherwise return a simulated value.
        if platform.machine() == 'armv5tejl':
            return float(os.popen("tshwctl --cputemp|grep external|cut -f2 -d'='").read().rstrip())
            return 30 + random.uniform(0, 5)

if __name__ == '__main__':
    root = resource.CoAPResource()

    temperature_resouce = TempResource()
    root.putChild('temperature', temperature_resouce)

    endpoint = resource.Endpoint(root)

    # Listen on default CoAP port 5683
    reactor.listenUDP(coap.COAP_PORT, coap.Coap(endpoint))

    # Run Twister'd event loop

Here is the corresponding client code:

import sys

from twisted.internet import reactor
from twisted.python import log

import txthings.coap as coap
import txthings.resource as resource

from ipaddress import ip_address

class CoapClient:
    Sample general purpose CoAP client that performs a GET to the specified IP address and path.

        python coap_client temperatures
    def __init__(self, ip_addr, url):
        self._ip_addr = ip_addr
        self._url = url
        # The reactor is Twisted's main event loop
        # Request that requestReource is called 1 second from now
        reactor.callLater(1, self.requestResource)

    def requestResource(self):
        # Create a non confirmable CoAP request.  To keep as
        # simple as possible we don't specify any observer
        # callbacks either.
        request = coap.Message(code=coap.GET, mtype=coap.NON)
        url_tokens = self._url.split('/')
        request.opt.uri_path = tuple(url_tokens)

        # COAP_PORT is 5683, the default UDP port for CoAP
        request.remote = (ip_address(self._ip_addr), coap.COAP_PORT)
        d = protocol.request(request)

    def printResponse(response):
        print 'CoAP result: ' + response.payload

    def noResponse(self, failure):
        print 'Failed to fetch resource:%s' % failure

if __name__ == '__main__':
    if len(sys.argv) == 3:
        addr = sys.argv[1]
        url = sys.argv[2]
        print 'Usage : %s <IP address> <url>' % sys.argv[0]
        print 'The url argument should not start with a "/", but use'
        print '"/" characters to separate later portions'


    endpoint = resource.Endpoint(None)
    protocol = coap.Coap(endpoint)
    client = CoapClient(addr, url)

    reactor.listenUDP(61616, protocol)

    # Run the Twisted event loop
Sample Run (connecting to server running on

2016-06-12 20:24:27-0700 [-] Log opened.
2016-06-12 20:24:27-0700 [-] Coap starting on 61616
2016-06-12 20:24:27-0700 [-] Starting protocol <txthings.coap.Coap instance at 0
2016-06-12 20:24:28-0700 [-] Sending message to
2016-06-12 20:24:28-0700 [-] Message 'T\x01\xd2\x1f\x00\x00m\xfb\xbbtemperature'
 sent successfully
2016-06-12 20:24:28-0700 [-] Sending request - Token: 00006dfb, Host: 192.168.1.
100, Port: 5683
2016-06-12 20:24:28-0700 [Coap (UDP)] Received 'TEe\xa6\x00\x00m\xfb\xff37.7' fr
2016-06-12 20:24:28-0700 [Coap (UDP)] Incoming Message ID: 26022
2016-06-12 20:24:28-0700 [Coap (UDP)] New unique CON or NON message received
2016-06-12 20:24:28-0700 [Coap (UDP)] Received Response, token: 00006dfb, host:, port: 5683
2016-06-12 20:24:28-0700 [-] CoAP result: 37.7



CoAP is an efficient messaging protocol for IoT applications.  Have you used it in practice?   If so, what limitations did you encounter?  Leave some feedback here:

Testing MTD Flash Memory


My current embedded Linux project is using “raw” NAND flash memory chips, as opposed to managed Flash like an eMMC chip.  Raw Flash is managed using the MTD subsystem in Linux.  MTD comes with a number of tools for low level testing of the Flash, and some of these are covered here.

All MTD test tools are built as kernel modules, e.g. mtd_readtest.ko.  Building of these modules must be enabled in your kernel configuration.  The “make modules” step must be run after the kernel is built to generate the .ko files.  Be careful in that these are low level tests and destructive.

Each of the MTD tests should be run on unmounted Flash partitions.  Each test takes a single argument specifying the number of the MTD device to use, starting from zero, e.g. “dev=7” specifies to test /dev/mtd7

Speed Test

This can be run with “sudo insmod mtd_speedtest.ko dev=7″as an example (e.g. using /dev/mtd7).  This will give an output like this:

mtd_speedtest: MTD device: 7
mtd_speedtest: MTD device size 310378496, eraseblock size 524288, page size 4096, count of eraseblocks 592, pages per eraseblock 128, OOB size 64
mtd_speedtest: scanning for bad eraseblocks
mtd_speedtest: scanned 592 eraseblocks, 0 are bad
mtd_speedtest: testing eraseblock write speed
mtd_speedtest: eraseblock write speed is 4730 KiB/s
mtd_speedtest: testing eraseblock read speed
mtd_speedtest: eraseblock read speed is 10935 KiB/s
mtd_speedtest: testing page write speed
mtd_speedtest: page write speed is 4656 KiB/s
mtd_speedtest: testing page read speed
mtd_speedtest: page read speed is 10895 KiB/s
mtd_speedtest: testing 2 page write speed
mtd_speedtest: 2 page write speed is 4724 KiB/s
mtd_speedtest: testing 2 page read speed
mtd_speedtest: 2 page read speed is 10906 KiB/s
mtd_speedtest: Testing erase speed
mtd_speedtest: erase speed is 492051 KiB/s
mtd_speedtest: Testing 2x multi-block erase speed
mtd_speedtest: 2x multi-block erase speed is 935506 KiB/s
mtd_speedtest: Testing 4x multi-block erase speed
mtd_speedtest: 4x multi-block erase speed is 910222 KiB/s
mtd_speedtest: Testing 8x multi-block erase speed
mtd_speedtest: 8x multi-block erase speed is 944249 KiB/s
mtd_speedtest: Testing 16x multi-block erase speed
mtd_speedtest: 16x multi-block erase speed is 941316 KiB/s
mtd_speedtest: Testing 32x multi-block erase speed
mtd_speedtest: 32x multi-block erase speed is 915722 KiB/s
mtd_speedtest: Testing 64x multi-block erase speed
mtd_speedtest: 64x multi-block erase speed is 941316 KiB/s
mtd_speedtest: finished

Page Test

This test tests NAND page writing and reading in different sizes and order.  This can be run with “sudo insmod mtd_pagetest.ko dev=7″as an example (e.g. using /dev/mtd7).  This will give an output like this:

mtd_pagetest: MTD device: 7
mtd_pagetest: MTD device size 310378496, eraseblock size 524288, page size 4096, count of eraseblocks 592, pages per eraseblock 128, OOB size 64
mtd_pagetest: scanning for bad eraseblocks
mtd_pagetest: scanned 592 eraseblocks, 0 are bad
mtd_pagetest: erasing whole device
mtd_pagetest: erased 592 eraseblocks
mtd_pagetest: writing whole device
mtd_pagetest: written up to eraseblock 0
mtd_pagetest: verified up to eraseblock 256
mtd_pagetest: verified up to eraseblock 512
mtd_pagetest: verified 592 eraseblocks
mtd_pagetest: crosstest
mtd_pagetest: reading page at 0x0
mtd_pagetest: verifying pages read at 0x0 match
mtd_pagetest: crosstest ok
mtd_pagetest: erasecrosstest
mtd_pagetest: erasing block 0
mtd_pagetest: writing 1st page of block 0
mtd_pagetest: reading 1st page of block 0
mtd_pagetest: verifying 1st page of block 0
mtd_pagetest: erasing block 0
mtd_pagetest: writing 1st page of block 0
mtd_pagetest: erasing block 591
mtd_pagetest: reading 1st page of block 0
mtd_pagetest: verifying 1st page of block 0
mtd_pagetest: erasecrosstest ok
mtd_pagetest: erasetest
mtd_pagetest: erasing block 0
mtd_pagetest: writing 1st page of block 0
mtd_pagetest: erasing block 0
mtd_pagetest: reading 1st page of block 0
mtd_pagetest: verifying 1st page of block 0 is all 0xff
mtd_pagetest: erasetest ok
mtd_pagetest: finished with 0 errors

Read Test

This does a scan of the entire Flash looking for bad blocks.

mtd_readtest: MTD device: 7
mtd_readtest: MTD device size 310378496, eraseblock size 524288, page size 4096, count of eraseblocks 592, pages per eraseblock 128, OOB size 64
mtd_readtest: scanning for bad eraseblocks
mtd_readtest: scanned 592 eraseblocks, 0 are bad
mtd_readtest: testing page read
mtd_readtest: finished




More filesystem performance comparisons – BTRFS

Earlier on I had benchmarked the performance of ext3 vs ext4 on my ARM HF Linux system.  This time I will add benchmarks for the root filesystem running BTRFS with lzo compression.

Disk Seek Performance

Using the seeker program from earlier, the results are:

./seeker /dev/mmcblk0p3
Seeker v2.0, 2007-01-15,
Benchmarking /dev/mmcblk0p3 [3630MB], wait 30 seconds…………………………
Results: 134 seeks/second, 7.42 ms random access time

This is quite a bit slower than 5.5ms for ext3 and 5.61 ms for ext4.

Disk I/O Performance

sysbench –num-threads=16 –test=fileio –file-total-size=500M –file-test-mode=rndrw prepare
sysbench –num-threads=16 –test=fileio –file-total-size=500M –file-test-mode=rndrw run
sysbench –num-threads=16 –test=fileio –file-total-size=500M –file-test-mode=rndrw cleanup

Average of 5 runs.


This is quite a bit faster than ext3 at 100.4Kb/sec and ext4 at 102.4KB/sec.

I/O with DD

dd if=/dev/zero of=data.bin bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 59.1702 s, 17.7 MB/s


The BTRFS performance appears to be much higher than ext3 or ext4 except for seeking.  This is probably due to more aggressive caching and compression.

I should also point out that despite it’s reputation as a work in progress, BTRFS has been very reliable, I have not seen a single crash or any data corruption.