My XMOS notes


Started 18Feb2015, updated 25Mar2017

This page is in group Technology and is a blog note about my experience with the XMOS toolset xTIMEcomposer and XMOS HW and how I’m going to use the startKIT to control a small 40 litre aquarium’s heating and light.

Fold handling

This blog note uses the Collapse-O-Matic WordPress plugin to handle text folding. It’s used mostly for code examples. In addition to expanding and closing them idividually you may here:

Expand All

(Since there’s no folding on this screen you’ll just have to trust it happens. Nice for printing)

Collapse All


I have no association with XMOS and there is no money involved neither with this nor any other blog notes of mine. (Well, that’s not completely true: I have happily bought two HW boards from one of their resellers!). This blog note will show problems and matters I especially like (in addition my default, I especially like so much of what I have read about, that’s why I decided to come to this).

Since this is meant to be of help for XMOS users I will constantly delete matters that are not relevant any more, like problems that have been solved in newer versions of the tools or boards. But I realise this is easier to say than do..

My gut feeling right now

..on 19Jan2017 is that I like more and more what I see. I have now spent quite many hours on the startKIT and XC. I think the concept is better than the transputer and better than occam, which says a lot. I am impressed by XMOS’s ability to handle XC tasks and their quite successful tightrope walk between being stringent and pragmatic. Also, the support is excellent, both when filing tickets and on XCore. I do recommend trying this! (Again, see Disclaimer above. But I can’t see anty reason why I shouldn’t be positive for free!)

First encounters

OK; this isn’t my first time (below)
First is #01.01

XMOS series of processors

I have queried at XCore Exchange: XMOS series processors and tried to paste the answers (below). The catch is that XMOS didn’t seem to have this as a public list(?). But now it seems to be here at least. I guess the newest are at the bottom. (Every disclaimer apply)

  • XS1 G-Series
    • G = “General” purpose device. XMOS’ first chip.
    • Not recommended for new designs, no compiler support from xTIMEcomposer 14.2.2 (Oct. 2016). End of life reached as of 31Mar2017 (here)
  • XS1 A-Series
    • A = Analog – Basically an XS1-U with no USB PHY. i.e. just DC-DCs + ADC
    • Used on startKIT board (XS1-A8-DEV but read data sheet of XS1-U16A-128-FB217 (here))
  • XS1 L-Series
    • Vanilla logic only XS1 device (L stands for ‘low power’ c.f. G-series)
  • XS1 U-Series
    • U = USB (+ DC-DCs + ADC)
  • XS1 XA-series
    • XA = eXtened Architecture, or Xmos/ARM. Single tile XS1-L + ARM M3 cortex. Being phased out (2017)
    • Used on xCORE-XA board (processor is XS1-XAU8A-10-FB265). End of life reached (2016)
  • xCORE-200
    • xCore-200 XL-Series
      These are general purpose devices with no USB or Ethernet
    • xCore-200 XU-Series
      Incorporates USB interface. Example Microphone Array, see here. Board with XU216-512-FB236 here (xTAG board included)
    • xCore-200 XE-Series
      Incorporates Gigabit Ethernet and USB interface. Fancy board with XE216-512-TQ128 here (xTAG board here not included)
  • xCORE-VOICE family
    • XVSM-2000 processor
      Example Smart Microphone, see here

Starting with startKIT

First is #02.01

Observe that there is a beautiful description of the XMOS world at the element14 community fabulous blog note by “shabaz” entitled XMOS startKIT: Introduction, Terminology/Architecture, Getting Started and Example Programs. See [10].

  1. February 2015: I run OS X Yosemite version 10.10.2 (14C109) on a MacBookPro10,2 (retina, 2012). I downloaded xTIMEcomposer 13.2.1 only to learn that I had to downgrade Java (it told me when I tried to start it), see OSX 10.10.2 Yosemite asks for “older version of Java SE 6 Runtime”. (With xTIMEcomposer 14 that I downloaded on 23March2015 this is ok)
  2. So, I downloaded Java from  and downgraded to the newest 32-bit version of the Java runtime, “Java for OS X 2014-001” – even if told me that “This article is about older, unsupported Java software. Download the latest version of Java for OS X directly from Oracle”. I had this:
    Java version “1.8.0_31”,
    Java(TM) SE Runtime Environment (build 1.8.0_31-b13).
    Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07, mixed mode) and downgraded to this:
    java version “1.6.0_65”
    Java(TM) SE Runtime Environment (build 1.6.0_65-b14-466.1-11M4716)
    Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-466.1, mixed mode)
  3. However, I installed it with my own paths to libraries and user files. This was no success. It crashed several times, and I couldn’t run the debugger. It was only when it complained that it couldn’t find the include files (with no good reason) that I realised that I should remove and reinstall xTIMEcomposer with default directory positions. Now it runs, and hasn’t crashed so far.
  4. But in order to run the debugger it’s not enough to press the buttons. You also have to give it the parameter -g (I knew this before the reinstall). You set -g in XMOS Edit, Project Explorer, find makefile and double-click on it and set xCORE xcc Flags, XC Compiler to -g and also ARM gcc Flags, C Compiler to -g (I think). Press the source tab below and you’ll see these:
    XCC_XC_FLAGS = -g
    ARM_GCC_C_FLAGS = -g
    I found this in a help file, even if it just told me to set the -g flag.
  5. When I press the XT icon in the Dock the window doesn’t open. I have to press Show all windows and then press the foggy small window that appears. (However, it’s not that simple, OS X is confusing on this matter, also for f.ex. Finder)  (With xTIMEcomposer 14 this is ok)
  6. Conclusion so far: some start problems. But what I see looks promising! Downloading the examples from GitHub was great!

Now my main.xc looks like this:

code main.xc of app_spinning_bar

#include <xs1.h>
#include <timer.h>

 * the patterns for each bit are:
 *   0x80000 0x40000 0x20000
 *   0x01000 0x00800 0x00400
 *   0x00200 0x00100 0x00080
 * As the leds go to 3V3, 0x00000 drives all 9 leds on, and 0xE1F80 drive all nine leds off.
 * The four patterns below drive a dash, backslash, pipe, and slash.
 * Modified by Teig to switch rotation and show when it switches.

#define MODES 4

int leds[MODES] = {
    0xE0380, // dash     (When "startKIT" reads this way)
    0x61700, // backlash -"-
    0xA1680, // pipe     -"-
    0xC1580  // slash    -"-

/* This the port where the leds reside */
port p32 = XS1_PORT_32A;

int main(void) {
    int delay_ms = 1;            // Initial delay_ms 1 ms
    int delay_ms_now = delay_ms;
    int delay_ms_inc = 1;        // Starting clockwise
    int led_counter = 0;         // A counter to count through the leds array

    while(1) {
        delay_milliseconds(delay_ms_now);  // Wait
        delay_ms += delay_ms_inc;          // Slower or faster
        p32 <: leds[led_counter];          // Drive the next led pattern

        if (delay_ms_inc == 1) {         // Clockwise slower
            led_counter++;               // Pick the next pattern
            if (led_counter == MODES) {  // If we were at the last pattern
                led_counter = 0;         // then wrap down
            else {}
        else {                           // Anti-clockwise faster
            led_counter--;               // Pick the previous pattern
            if (led_counter == (-1)) {   // If we were at the first pattern
                led_counter = (MODES-1); // then wrap up
            else {}

        if (delay_ms == 100) {            // It's slow, enough clockwise
            delay_ms_inc = -1;            // To anti-clockwise faster
            led_counter = (MODES-1);      // Start with last
            p32 <: 0x0000;                // But first all LEDs on
            delay_ms_now = 500;           // for 500 ms
        else if (delay_ms == 0) {         // It's fast, enough anti-clockwise
            delay_ms_inc = 1;             // To clockwise slower
            led_counter = 0;              // Start with first
            p32 <: 0xE1F80;               // But first all LEDs off
            delay_ms_now = 250;           // for 250 ms
        else {
            delay_ms_now = delay_ms;      // Use the faster or the slower delay
    return 0;


First is #03.01

  1. In order to stop at a line in the debugger you have to start it then press the suspend button. But you have to press a line in the Debug window to enable first.
  2. An empty “Import xTIMEcomposer Sotware” window appeared on my screen. There’s nothing to push, and it’s not in OS X running app list (Since it’s Java I assume). Stopping xTIMEcomposer (13.2.1) removed it.
  3. Pressing the green maximize button doesn’t maximize like f.ex. Safari does (ok), and doesn’t work if Dock is on the left (not ok). I think invisible right part is equal to the width of the Dock. But if I move the Dock down, then being at the bottom in some window editor is just as bad: I had to move the Dock to the left side again. It seems like Java calculates its needed window size disregarding the Dock. Ok, maybe I’l hide it automatically when I work with xTIMEcomposer.
  4. Installed xSOFTip (spelt xSoftIP Explorer in the application). Exciting!
  5. The Resource Glossary used for built-in help has a green button at the bottom that shows up even if the present version already is the newest version that the green button mentions. This is a general problem, it also suggests to download tools running.
  6. Generate xTIMEcomposer Project, Location shows a workspace that confuses me. If Create new project in workspace (no colon) is ticked then there is a path window that shows a grayed out path (which is the automatic path, we can’t change it of course). The problem is that the line below the above ticked line says Create new project in: (obs.: the colon). If this is ticked then the path window is emptied and allows a Browse button. The placement of the path window together with two choices, without and without a colon, as I said, confuses me.
  7. When I asked it to generate a project it complained that the I2C module had not had the ports mapped. I couldn’t find out how to do that, I canceled several times. I went on with the warning. When the project appeared and I looked at the source it started with this:
    r_i2c i2c_if = {on tile[0]:"<assign port here>", on tile[0]:"<assign port here>", 1000};

    I like it.

    code port mapping

    Now I must learn what to put there. I’m starting with driving a bit-mapped display. The display’s (Adafruit 128 x 32 I2C OLED, see [1]) I2C SDA is connector J7 pin 1 (1F at X0D13) and SCL is J7 pin 2 (1H at X0D23), and the notRST is J7 pin 3 (1G at X0D22). I’ll read myself up on th XS1 Ports: use and specification [2] or Introduction to XS1 ports [3]. Here’s the answer, at least it compiles:

    r_i2c i2c_if = {on tile[0]:XS1_PORT_1H, on tile[0]:XS1_PORT_1F, 1000};

    since in i2c.h I see the type r_i2c defined to be scl, sda and clockTicks.

Daily I (xTIMEcomposer 13.2.1 ff)

First is #06.01

  1. The documentation download appeared inside xTIMEcomposer when I got an annotation of an update. Great! But it suggested to download to the path that I gave it for the non-successfull install that I deleted. There was some cleanup that wasn’t done with OS X delete.
  2. The next thing is to import adafruit’s driver from GitHub. We use Git at work, but GitHub is new. Now, how do I get this C++ driver into the startKIT? (Now, after having studied it and realised that the way that ports in the xC world and wire in the Arduino world clash, and the general structure of the driver,  being not terribly impressed by its structure and conventions, I think I’ll make my own in xC proper. I might base that on the XMOS LCD-driver)
  3. When I wanted to clean up the editor window’s list of files, and removed all of them I got An internal error occurred during: “Compute launch button tooltip”. java.lang.NullPointerException. The OS X top row of xTIMEcomposer had gone, except for the leftmost xTIMEcomposer heading.  (With xTIMEcomposer 14 I don’t know yet)
  4. Editing a source file in an external editor and then back to a still open xTIMEcomposer will cause xTIMEcomposer to query whether I want to replace it. There is a different question if a file is modified since I closed xTIMEcomposer last time. So it keeps both internal and external editing in sync. (Earlier I wrote that this was not so, but it must have been “finger trouble” on my behalf). However, I get no question about merging, only overwrite.
  5. When the compiler finds the build to be free of errors it’s the linker that has the final say. The Problems window might show Errors (4 items). Undefined reference to ‘getRotation’ might be one of them. Double-click on them and nothing happens (i.e. no text window shows up. As an experienced programmer I get the situation: there is no code for getRotation. Right-clicking with “Show in properties” helps zero. Do observe that the window is wider than it looks, scroll it to leftwards to find more (but it only says Type is C/C++ problem, not linker problem). I don’t know if this is standard Eclipse behaviour or if it’s xTIMEcomposer. But the wording is not precise. More:
  6. The problem I think is with the semantics is the word reference, which gets worse when it’s undefined. There is no reference or there is a reference but doesn’t point to anything? How about: Error from linker: ‘getRotation’ used but no code defined, or code ‘getRotation’ defined but not used. But this might be gcc matter? I’ll check out the latter case, some times it’s a warning only – if it makes this point contradictory.
  7. I had a java.lang.NullPointerException when I pushed a file into the src tree from just below the src tree. It was random_conf.h that I had just created, obviously in the wrong place(?)   (With xTIMEcomposer 14 I don’t know yet)
  8. By the way, finding out how to use the the random_module as seen from the #include "random.h" was actually quite understandable, after I first found it in the GitHub window. The Help system is great. I look forward to useing more xmos modules
  9. I ran into a problem where the XE XCore Exchange community helped me: Changing file from .c to .xc causes mismatches with previous definitions. It turned out that I hadn’t used neither REFERENCE_PARAM nor extern "C" since my alerness had been lowered by XC calling C ok, but without pointers! Read the whole thread at Afterword: I tried REFERENCE_PARAM and extern "C" and unsafe decoration, but I was not able to tweak my mind around to it! What am I doing wrong? I ended up changing the header parameter from *txt to txt[]. That worked
  10. Now, here’s something I like: the compiler took me with an error for a function that had a parameter to an array but that array was in fact used hard-coded inside. This is not wanted aliasing (it might be wanted in a linked list, but this isn’t one). I haven’t seen that kind of error message for almost 20 years when occam had it. Here’s the message: call to `testdrawbitmap' in `examples_adafruit_ssd1306_128x32_i2c' makes alias of global 'logo16_glcd_bmp' examples_adafruit_ssd1306_128x32_i2c.xc /module_adafruit_SSD1306/src line 460

Bird’s eye view

First is #04.01. XMOS is very good at documenting. However, use of terms like node,  core, logical core and tile seems to be a darwinistic art, some go and some come:

  1. David May’s The XMOS XS1 Architecture [4] – needs update?
  2. XC Reference Manual [5] – needs update?
  3. However, the XMOS Programming Guide [6] is updated. We can even subscribe to updates
  4. And XC Specification, [7] is also updated

Which LED driver?

First is #05.01

  1. I posted a question to the XE XCore Exchange community: Rewrite XMOS LCD driver for a LED display or try to port existing Arduino LED driver?, see It took five days to get it approved… Then an answer appeared immediately. Thanks!

Cancelable timout: channels or interfaces?

First is #07.01

  1. On 23March2015 I posted this to XE XCore Exchange community. It’s at The answer I got suggested “If everything is in one task and you don’t mind global state you could store a pointer to the button chanend as a global (this is all memory safe when using movable pointers). This would probably be the minimal changes to your current code. You’d have something like:” Summary of suggestion with global channel end
    First, the global declaration

    chanend * movable p_c_button;

    and then a delay_if_needed function (or task for a while) polls the channel in a select:

    case *p_c_button :> int:

    and in the main task which calls delay_if_needed (so the channel end is used one place at a time), the button channel is also polled in a select:

    chanend * movable p = &c_button;
    p_c_button = move(p);
    // ...
    case *p_c_button :> int:

    This is interesting! Thanks, Dave Lacey!

xCORE startKIT

First is #08.01

  1. Also see startKIT board
  2. Why is the startKIT‘s micro-USB connector upside down? The small cable needs a twist in order to connect to my Mac Book Pro. The USB logo on the cable is correctly upside on the machine but underneath on the board. (The xCORE-XA module (with 7 XMOS cores and an ARM core) has the debug micro-USB mounted on the underside of the board, which makes sense in this context. But even there the power micro-USB is mounted like on the startKIT: on the top of the board.)

Daily II (xTIMEcomposer 14.0.0)

First is #09.01. Started 25March2015. xTIMEcomposer 14.0.0 (13.2.2 in point 10).

  1. There are spelling errors in the examples. Like in “startkit_adc.h”: “Give it it’s own core” and “Pass i_adc control inteface“. In “startkit_adc.xc” I read “Special function to allow select on inuint primative” (inuint is a variable name). Etc. Since this is official XMOS stuff, it should have been peer reviewed all over (to misspell is human). Another, worse matter in the same file: It uses this defintion in the interface: 

    code in startkit_adc.h?


    In my opinion it should have been more like this (with obvious usage reasons):

    typedef struct tag_startkit_adc_vals {
        unsigned short x[NUM_STARTKIT_ADC_VALS];
    } t_startkit_adc_vals;

    Of course, the typedef mechanism is discussable, but I think this is most portable (as also discusued in Stack Overflow)

  2. When I build by just importing libraries (and taking over from 13.2.1) I at the moment get 11 warnings of paths it can’t find. Do I need them, when they’re not errors?
  3. Aside: I am studying different matters these days. Here’s a processor that might be viewed as a competitor to XMOS? Infineon Aurix [8]. Not that I would switch for my aquarium, and my enthusiasm of XC (with my heavy CSP and occam legacy..)
  4. Aside 2: And then there’s Symtavision [9] XMOS competitor? As they say “Symtavision provides the leading timing analysis solution for planning, optimizing and verifying embedded real-time systems.” But there seems to be a huge difference in which level the problem is attacked. I wonder where analysis ends and guarantees start. After all, XMOS has what they say is “Software Defined Silicon”.
  5. XCore Exchange: I tried to post this in the xTIMEcomposer window and also my browser, but it did not accept because of illegal characters. Which of them it didn’t tell:

    Problem Occured
    ‘launching my_module.xe’ has encountered a problem
    No such debugger
    – Debug ran on 13.2.1. So I am not able to Debug and run to line and inspect variables etc. I can download the code and Run, though. I have tried to configure at places where I thought applicable, but I am blank now. It builds ok. But there are a lot of warnings of include libraries it can’t find, some of which I am not using. But all needed elements must be there, since I don’t get error.
    – This is among what I have tried several combinations of:
    Preferences : Run/Debug : Launching : Perspectives (Defaults:) : Open when launching (“Never”), Open when application suspends (“Prompt”), Modes Debug, None
    – xTIMEcomposer 14.0.0. startKIT
    Mac OSX 10.10.2. Java 8.1. JRE 1.80_31
    private project: http:/

    Update next day: after 3 hours of careful experience-building: I deleted my project, removed the files, made a new XC project and imported all my files again. Bingo! Of course it’s a challenge for any tool vendor to take heights for all beginner’s mess, but with the experience I do have after all these years it’s always a defeat to do what I did, since I’m the one to feel stupid. But then, now I am left with more than printf-debug! (By the way, it got worse than above; it even tried to run but failed on saying that it could find no source of main(). This took an extra 1.5 hours, by following that dead end. I think this happened when I had an extra round with 13.2.1)

  6. When I had an internal error and wanted to report, now doesn’t exist. It’s a url from their page!  XMOS, where art though? (But this works; where I did report it, filed as “7404: Internal error”.)

    Internal error log

    Compiling Aquarium.xc
    cd ./.build && xcc -c -D__random_conf_h_exists__=1 -I'../.' -I'.././bin' -I'.././src' -I'/Users/teig/workspace/lib_startkit_support' -I'/Users/teig/workspace/lib_startkit_support/api' -I'/Users/teig/workspace/lib_startkit_support/doc' -I'/Users/teig/workspace/lib_startkit_support/doc/pdf' -I'/Users/teig/workspace/lib_startkit_support/src' -I'/Users/teig/workspace/module_i2c_master' -I'/Users/teig/workspace/module_i2c_master/src' -I'/Users/teig/workspace/module_random' -I'/Users/teig/workspace/module_random/src' -O2 -g -DCONFIG=Default -Xcompiler-xc -analysis -Xcompiler-xc .././.build/pca.xml '../src/Aquarium.xc' '.././STARTKIT.xn' '.././config.xscope' -o '../.build/src/Aquarium.xc.o'
    xcc1: terminated due to internal unrecoverable error
    For bug reporting instructions, please see:
    xmake[1]: *** [.build/src/Aquarium.xc.o] Error 1
    xmake: *** [bin//Aquarium.xe] Error 2
    Update: I had tried

    on tile[0].core[0]: adc_task (i_analogue, c_analogue, 0);  startkit_adc (c_analogue)

    which was not smart. It should be core[4]. At least it compiles then (but it doesn’t seem to run, I can’t see that core in the debug view). Stay tuned.
    More: trying to comment away lines I get the following:

    Internal error log 2

    10:08:31 **** Incremental Build of configuration Default for project Aquarium ****
    xmake CONFIG=Default all 
    Checking build modules
    Using build modules: lib_startkit_support(2.0.0) module_i2c_master module_random
    Analyzing Aquarium.xc
    mkdir -p '.build/src/'
    cd ./.build && xcc -pre-compilation-analysis   -O2 -g   -DCONFIG=Default -D__random_conf_h_exists__=1 -I'../.' -I'.././bin' -I'.././src' -I'/Users/teig/workspace/lib_startkit_support' -I'/Users/teig/workspace/lib_startkit_support/api' -I'/Users/teig/workspace/lib_startkit_support/doc' -I'/Users/teig/workspace/lib_startkit_support/doc/pdf' -I'/Users/teig/workspace/lib_startkit_support/src' -I'/Users/teig/workspace/module_i2c_master' -I'/Users/teig/workspace/module_i2c_master/src' -I'/Users/teig/workspace/module_random' -I'/Users/teig/workspace/module_random/src' '../src/Aquarium.xc' '.././STARTKIT.xn'  '.././config.xscope' -o '../.build/src/Aquarium.xc.pca.xml' > /dev/null
    ../src/Aquarium.xc:35:10: warning: unused variable `c_analogue'
        chan c_analogue;
    ../src/Aquarium.xc:39:76: warning: `i_analogue' not used in two parallel statements
            on tile[0].core[0]: test_display (i_delay, c_button_1, c_button_2, i_analogue);
    xcc1: terminated due to internal unrecoverable error
    For bug reporting instructions, please see:
    xmake[1]: *** [.build/src/Aquarium.xc.pca.xml] Error 1
    xmake: *** [analyze] Error 2

    Here’s the code that seemed to fix this. There is something about placements here. I did send the failing code to XMOS:

    int main () {
        chan c_external_button_1;
        chan c_external_button_2;
        interface delay_interface i_delay;
        interface startkit_adc_if i_analogue;  // For triggering/reading ADC
        chan c_analogue;                       // Used by ADC driver to connect to ADC hardware
        // From AN00177_startKIT_adc_demo:
        // These interface connections link the application to the GPIO task
        interface startkit_led_if    i_startkit_led;    // For setting LEDs
        interface startkit_button_if i_startkit_button; // For reading the button
        par {
            // Setup from lib_startkit_support.pdf:
            startkit_adc (c_analogue); // Declare the ADC service (this is the ADC hardware, not a task
            on tile[0]: adc_task (i_analogue, c_analogue, 0); // Run ADC server task (on same core as GPIO!)
            // Needed so far?:
            on tile[0]: startkit_gpio_driver (i_startkit_led, i_startkit_button, null, null, gpio_ports); // Run GPIO task for leds/button
            on tile[0].core[0]: startkit_blackhole (i_startkit_led, i_startkit_button);
            // Certainly needed:
            on tile[0].core[0]: test_display (i_delay, c_external_button_1, c_external_button_2, i_analogue);
            on tile[0].core[1]: inP_Button_Task (BUTTON_1, inP_button_1, c_external_button_1);
            on tile[0].core[1]: inP_Button_Task (BUTTON_2, inP_button_2, c_external_button_2);
            on tile[0].core[3]: server_delay_iff (i_delay);
        return 0;
    Update 10April2015: XMOS informed me that they had an update that fixed this problem: xTIMEcomposer 14.0.1. After I upgraded I haven’t seen this incidence
  7. How to get the ADC on startKIT to work. This took me an awful lot of time! I had already downloaded and used code from AN00177_startKIT_adc_demo and it ran. Still I used hour after hour – the debugger just left me at the i_adc.trigger() call. It looked like a deadlock. But then I discovered that the code stopped in init_adc_network in startkit_adc.xc, and that it believed that the links were not configured. Then I discovered the How
    to use the ADC on StartKit?
     thread, and downloaded the startkit-adc demo code. It also ran; not that strange, the demos look alike. Then I saw its config.xscope file. I pasted the contents into my Aquarium project’s config.xscope. Now it seems to work! I’ll try to make a short explanation of this when I understand it. Observe that there is a problem with the A/D values converted on the startKIT, see startKIT ADC problem (below).

    ADC on startKIT needs this config.xscope!

    <?xml version="1.0" encoding="UTF-8"?>
    <xSCOPEconfig enabled="true" ioMode="basic">
    <Probe name="ADC0" type="CONTINUOUS" datatype="INT" units="n" enabled="true"/>
    <Probe name="ADC1" type="CONTINUOUS" datatype="INT" units="n" enabled="true"/>
    <Probe name="ADC2" type="CONTINUOUS" datatype="INT" units="n" enabled="true"/>
    <Probe name="ADC3" type="CONTINUOUS" datatype="INT" units="n" enabled="true"/>
  8. Undefined reference; when I had copy/pasted app from main.xc in AN00177_startKIT_adc_demo, and I had forgotten to rename it to what was in the header: startkit_blackhole. I had used the new name where it was started in the par in another file; it was this compilation that failed. I can now understand the messages, but a somewhat higher level error message might have saved me an hour!

    'Undefined reference' log

    Undefined reference to 'startkit_blackhole'	
    Undefined reference to 'startkit_blackhole.dynalloc_maxchanends'
    Undefined reference to 'startkit_blackhole.dynalloc_maxcores'
    Undefined reference to 'startkit_blackhole.dynalloc_maxtimers'
    Undefined reference to ''
    Undefined reference to 'startkit_blackhole.init.1'
    Undefined reference to 'startkit_blackhole.init.0.savedstate'
    Undefined reference to 'startkit_blackhole.init.0'
  9. I am in fine dialogue with XMOS about the problems above. They have already come back a couple of times after I filed a report.
  10. 2April2015: A subscribed-to info told me that  xTIMEcomposer 13.2.2 was available. I had already been running 13.2.1 and the newer 14.0.0. But since this looked rather new, I downloaded it. When I tried to debug it said “No such debugger” as above. So I again deleted Aquarium and made a new fresh project with the same name, and imported all the files. No such debugger disappeared. But it was hard to get it to run. I have seen before that if I righ-click on the project, and use that drop-down menu to Debug As or Run As then that takes me there. But I still don’t get the starkit_adc library to run. After the first i.trigger(); to it, it stops and that’s it.
  11. 2April2015. When running xTIMEcomposer 14.0.0 again after the exercise above I had to do exactly the same delete and install and then import files, to get rid of “No such debugger”.
  12. The big list of Invalid project paths it complained it couldn’t find (but it still compiled ok!?), like
    Include path not found (/Applications/XMOS_xTIMEcomposer_Community_14.0.1/target/include/c++/4.2.1). lib_startkit_support pathentry Path Entry Problem

    at first didn’t appear after I had again made the project from scratch and imported the three used libraries from workspace into workspace (yes!). But then, after a clean, it was there again.

  13. 27April2015: New post by me in XCore Exchange: XMOS in safety critical systems: IEC 61508 and spatial and temporal independence, see

Daily III (xTIMEcomposer 14.0.3)

First is #10.01. Started 17June2015. xTIMEcomposer 14.0.3 (for OS X Yosemite 10.10.3)

  1. (16June2015) I experienced a total hang with spinning beach ball. OS X caught it and a report was sent to Apple. Probably an effect of “wild” button pressing on my behalf

Daily IV (xTIMEcomposer 14.0.4)

First is #11.01. Started 7July2015. xTIMEcomposer 14.0.4 (for OS X Yosemite 10.10.4)

  1. xTIMEcomposer 14.0.4 NullPointerException, posted to XCore Exchange, see Here’s the text: “I started it on OS X Yosemite 10.10.4 with Java Runitime 1.8.0_45. When I fiddled around finding my password (which, since it’s Java isn’t a process helped by the OS?) it just got the NullPointerException. When I finally found it xTIMEcomposer seems to work ok.”

startKIT ADC problem

(20May2016) At the very end of this section there is a chapter called startKIT ADC problem described by XMOS that closes this case.

(23April2015) New post by me to XCore Exchange: startKIT adc values seem to float, see

(27Sept2015) This is the same problem as described above and filed at startKIT adc values seem to float, which was not resolved. After I got the problem well isolated I have now reported it again (7Oct2015), see lib_startkit_support ADC accuracy.

I now also  have a second startKIT. Instead of the TC1047A temperature unit I now made a small board (diagram is PDF export from iCircuit pasted into a Pages document, then PDF from it, all vectorised, just press to get it):

XMOS startKIT J2 analogue input header static test board

Press to get PDF

With the test board above, plugged into the startKIT J2 analoge input header running the following speed, I get the results (also below). I have a BitScope BS10 and the pulses are as expected. Below is the complete code. This is the server that uses the adc_task (click to expand):

startKIT ADC problem code

 * startKIT-adc-test.xc
 *  Created on: 29. sep. 2015
 *      Author: Øyvind Teig

#include  <platform.h>
#include  <stdio.h>
#include "startkit_adc.h"


typedef struct tag_startkitd_adc_vals {
    unsigned short            x[NUM_STARTKIT_ADC_VALS];
    unsigned short          max[NUM_STARTKIT_ADC_VALS];
    unsigned int       mean_sum[NUM_STARTKIT_ADC_VALS];
    unsigned int       mean_cnt;
    unsigned short          min[NUM_STARTKIT_ADC_VALS];
} t_startkit_adc_vals;

#define ADC_PERIOD_TIME_USEC 0 // 1000 would mean to let
// free running and query-based "compete", not very smart!
#define ADC_NUM_SAMPLES 1000  

void test_adc (
    client interface startkit_adc_if i_analogue)
    unsigned wait_for_adc = 0;
    unsigned int loop_cnt = 0;
    unsigned int adc_cnt = 0;
    unsigned int no_adc_cnt = 0;
    t_startkit_adc_vals adc_vals;

    for (int i=0; i<NUM_STARTKIT_ADC_VALS; i++) {
        adc_vals.min[i]      = 0xffff;
        adc_vals.max[i]      = 0;
        adc_vals.mean_sum[i] = 0;
        adc_vals.mean_cnt    = 0;
    while(loop_cnt < ADC_NUM_SAMPLES) { 
        wait_for_adc = 1; 
        select { 
            case wait_for_adc => i_analogue.complete(): {
                wait_for_adc = 0;
                if ( (adc_vals.x)) {
                    for (int i=0; i<NUM_STARTKIT_ADC_VALS; i++) {
                        if (adc_vals.x[i] > adc_vals.max[i]) {
                            adc_vals.max[i] = adc_vals.x[i];
                        if (adc_vals.x[i] < adc_vals.min[i]) {
                           adc_vals.min[i] = adc_vals.x[i];
                        adc_vals.mean_sum[i] += adc_vals.x[i];
                    adc_vals.mean_cnt++; // Equally many for each
                } else {
    // Internal A/D-converter
    // 0 to 65520 (0xFFF0)
    // Div 16 = 0 to 4095, ref = 3.3V
    // 3300 mV / 4096 = 0,8056640625 mV
    // 750 mV = 25 DegC then 10 mV/DegC
    // See XS1-A8A-64-FB96-Datasheet(1.3).pdf
    // See below about "Some needed offset values"
    printf ("Summary of ADC: %u trials %u readings (%u lost)\n",
            ADC_NUM_SAMPLES, adc_cnt++, no_adc_cnt++);
    for (int i=0; i<NUM_STARTKIT_ADC_VALS; i++) {
        unsigned int adc_val_mean_i = 
        int  DegC_OneTenth_Parts = 
             (((adc_val_mean_i*100) - 198545) / 1985) - 400;
        int  DegC_Unary_Part = DegC_OneTenth_Parts/10;
        int  DegC_Decimal_Part = 
             DegC_OneTenth_Parts - (DegC_Unary_Part*10);
        printf ("i:%u DegC=%u.%u ", 
        if (i < (NUM_STARTKIT_ADC_VALS-1)) {
            unsigned overlapping = 
                (adc_vals.max[i] >= adc_vals.min[i+1]);
            unsigned int adc_val_mean_ip1 = 
            printf("min=%u mean=%u max=%u diff=%d X=%u\n",
        } else {
            printf("min=%u mean=%u max=%u\n",

int main () {
    chan c_analogue;
    interface startkit_adc_if i_analogue;
    par {
        on tile[0]: test_adc (i_analogue);
        on tile[0].core[0]: 
            adc_task (i_analogue, c_analogue, ADC_PERIOD_TIME_USEC);
            startkit_adc (c_analogue); // Declare the ADC service,
            // startkit_adc is the ADC hardware, not a task
    return 0;
Here are some lines printed out, from several runs. They are typical for many runs (click to expand)

startKIT ADC problem log

== xTIMEcomposer 14.1.0
Cable out and in after error messages, as well as xTIMEcomposer restart
No display connected, short cable, no flourescent USB light on,
however non of this seems to matter
= ADC_PERIOD_TIME_USEC 1000 for all
  not very smart, see above - use zero. If zero then we get 0 lost all over
Summary of ADC: 1000 trials 1000 readings (0 lost)
i:0 DegC=25.7 min=14880 mean=15030 max=15120 diff=209 X=1
i:1 DegC=26.7 min=15104 mean=15239 max=15376 diff=195 X=1
i:2 DegC=27.7 min=15312 mean=15434 max=15536 diff=198 X=1
i:3 DegC=28.7 min=15536 mean=15632 max=15760
Summary of ADC: 1000 trials 1000 readings (0 lost)
i:0 DegC=25.6 min=14928 mean=15025 max=15120 diff=208 X=1
i:1 DegC=26.7 min=15088 mean=15233 max=15344 diff=197 X=1
i:2 DegC=27.7 min=15344 mean=15430 max=15536 diff=199 X=1
i:3 DegC=28.7 min=15472 mean=15629 max=15728
Summary of ADC: 1000 trials 992 readings (8 lost)
i:0 DegC=25.6 min=14848 mean=15019 max=15120 diff=130 X=1
i:1 DegC=26.3 min=15008 mean=15149 max=15248 diff=197 X=1
i:2 DegC=27.3 min=15216 mean=15346 max=15440 diff=200 X=1
i:3 DegC=28.3 min=15360 mean=15546 max=15648
Summary of ADC: 1000 trials 992 readings (8 lost)
i:0 DegC=25.7 min=14848 mean=15037 max=15136 diff=130 X=1
i:1 DegC=26.4 min=15040 mean=15167 max=15312 diff=196 X=1
i:2 DegC=27.3 min=15248 mean=15363 max=15456 diff=200 X=1
i:3 DegC=28.4 min=15424 mean=15563 max=15664

Some needed offset values

Update (Nov2016) when I finally came around to using the startKIT with for internal temperature in the box, two voltages and one light sensor connected to J2 A0-A3. I removed the connection and saw these offset values. Here is where I pick up mean values of 1000 or more raw values:

Some needed offset values code

#define OFFSET_ADC_INPUTS_STARTKIT 190,175,195,187 // Moe or less these values
case (client_state == ADC_AWAIT_READ_FROM_UP) => (
        unsigned short return_adc_mean_vals[NUM_STARTKIT_ADC_INPUTS]) -> 
    {unsigned int adc_cnt, unsigned int no_adc_cnt}: {
    for (int i=0; i<NUM_STARTKIT_ADC_INPUTS; i++) {
        if (adc_vals.mean_cnt == 0) { 
            return_adc_mean_vals[i] = 0;
        } else {
           return_adc_mean_vals[i] = 
               (unsigned short) (adc_vals.mean_sum[i]/adc_vals.mean_cnt);
           // Offsets measured on whole set with nothing connected on startKIT ADC J2
           // No underflow on unsigned short, i.e. it cannot go negative:
           if (return_adc_mean_vals[i] <= offsets[i]) {
               return_adc_mean_vals[i] = 0;
           } else {
               return_adc_mean_vals[i] -= offsets[i];


See what to expect from the processor in the next chapter (just below). Here’s a summary of what I do get:

65536 steps is 16 bits is  1 ADC per bit
 4096 steps is 12 bits is 16 ADC per bit
 1024 steps is 10 bits is 64 ADC per bit

  3300 mV in 12 bits in 4096 steps is 0,8.. mV per bit
  3300 mV in 10 bits in 1024 steps is 2,6.. mV per bit

With my R-R network we have
  10 mV is 3,85.. steps of 10 bits
  «overlapping» (log above) is overlap from one to the next 10 mV step
  So, when overlapping is 1 it means about 8 bits accuracy
  Only difference is relevant, since the R-R network is not calibrated

750mV is 25.0 DegC at 10mv/DegC
  1.0 DegC is 10 mV is about 3.85 steps of 10 bits
  0.1 DegC is  1 mV is about one  step  of 12 bits
  • The answer to these was finally provided by XMOS. See below chapter “startKIT ADC problem described by XMOS”
    • Each sample as compared to another in a set seems to be at worst 8 bit from the next
    • Mean of 1000 measurements is around 10-11 bits
    • I have tried different cores, no change
    • Is there some timing related issue in the adc_task sw or startkit_adc service?
  • The answer to these is that I didn’t use ADC_PERIOD_TIME_USEC as 0, which would have meant no free-running ADC to “compete” with my query-based:
    • Why are some samples lost or not when ADC_TRIG_DELAY is changed?
    • Why doesn’t XMOS default value of ADC_TRIG_DELAY 40 cause zero lost?

XMOS internal ADC – what to expect?

I need to study what to expect, again.

startKIT board

From the startKIT Hardware Manual ( I read that  the xCORE-Analog A8-DEV device (processor XS1-A8-DEV) is only available as part of startKIT, and is therefore not separately documented. (See XMOS series of processors (above).) If you are using startKIT as a target platform and need datasheet-level documentation, you may find it useful to review the XS1-U16A-128-FB217 Datasheet, here: Here’s from the 2015/04/14 doc XM002326 (text and table 18.4):

12 Analog-to-Digital Converter. The device has a 12-bit 1MSample/second Successive Approximation Register (SAR) Analogue to Digital Converter (ADC). It has 8 input pins which are multiplexed into the ADC. The sampling of the ADC is controlled using GPIO pin X0D24 that is triggered either by writing to port 1I, or by driving the pin externally. On each rising edge of the sample pin the ADC samples, holds and converts the data value from one of the analog input pins. Each of the 8 inputs can be enabled individually. Each of the enabled analog inputs is sampled in turn, on successive rising edges of the sample pin. The data is transmitted to the channel-end that the user configures during initialization of the ADC. Data is transmitted over the channel in individual packets, or in packets that contain multiple consecutive samples. The ADC uses an external reference voltage, nominally 3V3, which represents the full range of the ADC. The ADC configuration registers are documented in Appendix G.

xmos xs1-u16a-128-fb217 datasheet 18.4 adc characteristics

ADC Characteristics: Resolution, Conversion Speed, Number of Channels, Input Range, Differential Non Linearity, Intergral Non Linearity, Gain Error, Offset Error, Power time for ADC Clock Fclk, Effective number of bits

Ok, with Effective number of bits 10 bits I have 3300 mV / 1024 = 3.22 mV absolute resolution. The figures I get are not near to that resolution.

startKIT ADC problem described by XMOS

(4Nov2015) I got the below document on mail from XMOS regarding my support ticket «8216: startKIT ADC problem» started 27Sept2015. They sent me the Design Advisory: XS1-U and XS1-A series ADC noise (Dated 2014-04-09). However, I did not feel it was right of me to inform about this here, so I kept silent.

(20May2016) I got a mail stating that the above mentioned design avisory “The U/A series ADC advisory has now been published on our website” at Here’s from it:

Issue description

Significant noise can be observed on ADC readings on the U and A series devices. For a 0 to 3.3 volt signal, this issue can introduce errors of ±50mV.

The severity of the issue is application dependent. For highly sensitive applications requiring maximum sample frequency, the issue can be critical. For applications where sensitivity is not crucial, and or oversampling and averaging techniques can be used, the severity can be regarded as normal, with workarounds available.

They also stated that there is no plan for an upgraded startKIT with an upgraded processor. Fair enough. I will use both the internal ADC with calculated long mean values and the MCP9808 High Accuracy I2C Temperature Sensor Breakout Board from Adafruit [ID:1782] in my aquarium project. (Disclaimer: this is just informative and and no ad.)

Daily VI (xTIMEcomposer 14.1.0)

Started 1Oct2015. xTIMEcomposer 14.1.0 (for OS X Yosemite 10.10.5). Machine (MacBookPro10,2). When I upgraded xTIMEcomposer I got

XTAG-2 Firmware not valid for this version, 
please power cycle the XTAG-2 device

Also when I downgraded and decided to run 14.0.4 again. It seems not to have so many of the below problems (on next try I seem to get out of them), so I have decided to continue with 14.0.4 for a while.

Running on startKIT

It’s becoming hard to get the debugger up and running. I do a lot of printf’s that may be the problem (I minimised it and it helped, but I still am plagued). Don’t know what to do. Many hang reports gone to Apple (XMOS). I have asked at XCore Exchange: This is the full list less the sequence and what I did or didn’t do:

.gdbinit: No such file or directory.
connect --adapter-id 0zGcIk5WkhKBj --xscope-realtime --xscope-port localhost:10101

Cannot connect, device is in use by another process
  Target connection failed
    Target is not responding (timed out)
    Target is not responding (timed out)
    Target is not responding (timed out)

Cannot connect, device is in use by another process
xrun: Problem in connection to device

ERROR: socket bind.(0) 

I saw these after downgrading to 14.0.4, but I seem to succeed “next time”:

First stage multi-node boot failed, please check XN file and Xmos link connectivity

Terminate failed
  Target is not responding (timed out)
    Target is not responding (timed out)
    Target is not responding (timed out)

Load failed
  Target is not responding (timed out)
    Target is not responding (timed out)
    Target is not responding (timed out)

Machine (MacBookPro10,2) restart seemed to help, first run ok (but then the log window gets full..). Some times the the xTIMEcomposer window isn’t drawn, some times it’s ok when I hover over places. At the moment I think xTIMEcomposer is too complicated (it works when everything is ok?) but impossible(?) to find out of on my own. I think 14.1.0 is worse than 14.0.4.

Daily: xTIMEcomposer (14.2.1)

A crash with “xcc1: terminated due to internal unrecoverable error” was filed in March 2016 (as #8810 at the then valid xTIMEcomposer). It had not been fixed with 14.2.1, but the code was changed so I didn’t see it. Same problem with my code compiled with 14.2.3

I filed  a new error report to XMOS (as #9481) about a case when a composite structured value is declared in a header file that’s used by several:  “Error: Multiple definition of ‘i2c_server_param.globound'”. I was confused because it had no member ‘globound’. If I just declare an “int value;” I would get  “Error: Multiple definition of ‘value'”. It also didn’t resolve the line number where the first declaration was seen. The error listing needs to be brushed up in my opinion.

Daily: xTIMEcomposer (14.2.3)

Ticket: Returning values in arrays via interfaces

I filed a new error report on 25Jan2017 called “9731: xcc1: terminated due to internal unrecoverable error”. I had OS X El Capitan 10.11.6, Version: Community_14.2.3 (build 15642, Oct-17-2016). I simply declared this as a method call in an interface, I didn’t even need to implement the method.  It’s obviously(?) very wrong:

typedef interface temperature_heat_commands_if {
    {char [4], char [4], char [4]} get_all_temp_degC (void);
} temperature_heat_commands_if;

int main() {
    return 0;

They (as usual) came back with people on the case. I believe the compiler in the future will give a proper error report. Fair enough, even if I think it should be perfectly legal to return array(s) like that.

In communicating arrays, typically in a read method that clears_notification I’ll just quote myself in that internal XMOS ticket:

I ended up using an array of bytes in the standard parameter set, like in the return of values from the ADC module for the startKIT.

However, I do have to fill every byte by hand (or in a loop). Even if I make a typedef of the array and use that both in the parameter list and internally it will complain about lvalue. It probably is so because of a pointer behind it. Still I assume the return is by value, since the read clears_notification. When I am _using_ an array by value and in my head _thinks_ of the assignment by value then I don’t see why the not-lvalue assignment should stop me.

I could move this into the Xcore group or continue with a new case here. Maybe you could mention it for somebody. While they fix this crash now, they could get away with that lvalue problem as well and let me do

return_array = internal_array;

of same types!

I am eager to see where this ends. Up to now (and probably for the future, they tend to have things thought well through), their suggestion is shown at How to use memcpy with interface array arguments. They say  that in this solution “memcpy can actually optimize the transfer across tasks”. (Noting later that it’s because on a single tile all memory is shared). Well, put it in the language then, because that’s exactly what a typesafe assigmnent of an array does!

Ticket: Unrecoverable error with wrongly typed typedef of array used in interface return

I filed an error report on 9Feb2017 called “9772: Unrecoverable error with wrongly typed typedef of array used in interface return”. It turned out that it had been fixed in 14.3, probably the next version.

Ticket: xTIMEcomposer hangs when starting startKIT

I filed an error report on 20Feb2017 called “9808: xTIMEcomposer hangs when starting startKIT”.  This was internally passed on to engineering.

Daily: xTIMEcomposer (14.2.4)

Ticket: Variable length array causes unrecoverable error

Some times I am using XC so wrongly. But the compiler needs to explain rather than crash. But then, I assume this is assert programming – so much better than quietly building a wrong object file. 18Mar2017: “9916: Variable length array causes unrecoverable error”.

xTIMEcomposer more tips

This probably should all be at

printf from sw running on startKIT

  • First, perhaps this solves your questions: AN10120: How to read/write to the console during execution
  • printf lines won’t just go to your screen! And if it doesn’t there nothing that warns you that it won’t happen! Do like this:
  • xTIMEcomposer:
  • Run:
  • Debug Configurations:
    • Main: Run on: hardware. Target: XMOS starKIT connected to …. Run JTAG I/O server
    • XScope: Real-Time Mode
    • Debugger: Stop on startup at: main (not needed for printf, though)

Figure 3. Visible printf lines are red

  • But when you have started the debugger you won’t necessarily see the correct console window where your printf logs will appear. Hold the cursor over the icons in the Console (partial screen clip above) and activate:
    • Show Console When Standard Out Changes
    • Show Console When Standard Error Changes
  • Then, press the down arrow and get the pull-down menu of the blue-framed screen. For me it has:
    • 1 CDT Global Build Console
    • 2 CDT Build Console [Aquarium]
    • 3 Aquarium.xe [xCORE Application] xgdb (21:35 13.11.16)
    • 4 Aquarium.xe [xCORE Application] /Users/../../Aquarium.xe (21:35 13.11.16)
  • Also see XCore: System time tag of printf in xTIMEcomposer debug console (below)

Long compiler error logs

It is possible to do a single change of the code, in one line, and get a very, very long compiler error log that takes very long to print to the console. And the first line of the log doesn’t necessarily point to your error.

As an example I had an array of interfaces that I didn’t listen to in the select case line with the listen-to-array-of-interface syntax. It took me long to find out, because I had done some copy paste. When I used the right syntax, zero errors. With, several hundred errors.

Even if it takes perhaps 30 seconds to print to the console window, the compiler always has completed within a second. It the console printout slowed up on purpose?

This is “worse than C”. The best compiler I have used on this was the Inmos occam compiler. It showed the problem, seldom more. Not follow-up errors. C is bad on this, we know that. But we also know it’s because of the many idiosyncracies of C. But I assumed that xC would be more coherent, since much of it is occam in new clothes. This is for errors on .xc files, so the compiler should know…

(Nov 2016) I filed one of these examples as a problem report to XMOS.

xCORE-XA Core Module Board (with xCOREs and ARM)

xCORE-XA board

(Update Mar2017: Has reached end of life, see XCore: xCORE-XA end of life and ARM (below))

(Update 13July2016) I bought one of these (also called xCORE XA) in early 2015, but haven’t started using it yet. I bought it because its processor has seven xCORE logical kernels and one ARM kernel (ARM Cortex-M3, Wikipedia). The processor XS1-XAU8A-10-FB265 data sheet is here. (See XMOS series of processors (above).) It is still presented on the XMOS pages, and I think it’s the only type of processor in which they have an ARM core. However, the board is already obsoleted, but you’ll find it at the XMOS | SUPPORT| BOARDS: GENERAL PURPOSE | Older boards. This link may take you there. However, the manual is here. Hopefully these links are permanent. The board should be rather ok for analogue, I assume.

When I retire (in 2017) I plan to build a general channel-based run-time (real-time, scheduler), and test it on this ARM – and the Arduino? I did ask at the XCore Exchange whether that ARM could run xC. Of course it can’t. See Is it possible to program ARM core of xCORE-XA using xC prog. But I could do something, based on my and Vannebo’s paper “New ALT for Application Timers and Synchronisation Point Scheduling” (here) used in “ChanSched”. Those who live will see.

Ok; this isn’t my first time

I have worked with development tools and external HW (and designed some boards) over a life time (Block play for blockers). I’ve had hands on with lots of IDEs. I would only just admit that my first Algol program was delivered on punched cards to the “Orakeltjenesten” at NTH here in Trondheim when I was a student 1971-76. The “Oracle service” still exists. However, I have only as a short visit worked with an Eclipse-based IDE. It was a Mentor Graphics development system for an  embedded ARM running the Nucleus OS (now RTOS) around 2006. But at that time it was rather unstable, so we ended up using the tool from Keil, just acquired by ARM. And now, when I was happy to see Java applets finally disappear from the Norwegian “BankID”, I decided to use and learn the XMOS toolset. It’s a private project, and here Macs rule. I look forward to this journey!

I expect to see a modern development system, even better than the Texas Instrument Development System in the 70-80-90ies and the Occam 2 Toolset in the 85-90ies, both of which I have worked with for years. The XMOS processor architecture is a fantastic new family member, starting with grandfather Ti processors 9990’s and father Transputer. I look forwards to this!

More XCore Exchange (XE community) forum posts

The below are my XCore Exchange entries not mentioned elsewhere in this blog note. Just search for “XCore Exchange” to find all.

XCore: A nondeterministic note about nondeterminism

See A nondeterministic note about nondeterminism (25Apr2012)

XCore: Protecting startKIT I2C and 3.3V from 24V surge?

10Sept2016. See (10Sept2016). Here is my initial question (below). See there for any replies.

I am connecting an Adafruit MCP9808 I2C temperature sensor underneath my aquarium together with heating cable driven by 24V DC, pulsed by the startKIT. I connect SDA and SCL on MCP9808 to X0D23 (J72) and X0D22 (J73). It’s powered by the 3V3 output. I2C doesn’t need much speed.

Is there any way at all to protect the startKIT processor from a broken heating cable that hits the MCP9808? It would be ok for the MCP9808 to break, but rather not the startKIT.

I have simulated 300 Ohm in series with the SDL and SLC and 300 Ohm in series with the 3.3V, but I don’t think it much useful. NXP advices this for SDA and SCL in their UM10204 “I2C-bus specification and user manual”. MCP9808 has 10K pull-ups on SDA and SLC. I have not added any zeners. See attached PDF. I’m afraid it’s too complex. It’s not going to be in a rocket..

(PDF attachment)

I have already made the layout such that during normal usage there’s virtually no probability of any accidental 24V. The heating cable seems sturdy. I do this to monitor the max temp under there of some 50-60 DegC. The cable is 2 x 14 meters to spread out the effect, 2 x 24 W.

I haven’t found any max ratings of the Tile 0 IO in the XS1-U16A-128-FB217 Datasheet.

I am tempted to let the connections just go unprotected. But in case there is a simple way?

I got a very extensive reply from “mon2”, especially pointing me to I2C isolators. I was intrigued by the I2C Isolator click from MikroElectronika in Serbia. New company for me! I’ll buy one isolator!

XCore: An error pin?

See (22dec2016) about how to make one’s own exception handler and even pull a line to beep when it’s invoken.

Update 12Jan2017: After this version 14.2.4 of xTIMEcomposer came with “Improved error reporting for runtime exceptions within application code” (here). See follow-up at XCore: Improved error reporting for runtime exceptions within application code

XCore: Logical cores as IEC61508 “differing systematic capability”?

See (23dec2016) about this matter. I have discussed the basis of it here. This is very interesting!

XCore: Wi-Fi sliceCARD and ports on startKIT

See (29dec2016)

Here’s my summary in that note, done after great help from henk and mon2:

Now I got it! Since I came to the startKit not via the sliceKIT core board it took you two to point me to the fact that there are four kinds of mapping of pins with four PCIe connectors (called STAR, SQUARE, TRIANGLE and CIRCLE). And alas, there is no general way to #define these in the code. And even if the startKIT has PCIe the mapping is like none of the four. Pin budgeting is difficult. So, here’s a summary of the above, with pin PCIe B6 as an example (XC coding was not in my original question):

2.10.1 STAR
    B6 X0D2 P4A0 P8A0 P16A0 P32A20
2.10.2 SQUARE
    B6 X1D2 P4A0 P8A0 P16A0 P32A20
    B6 X0D26 P4E0 P8C0 P16B0 (*)
2.10.4 CIRCLE 
    B6 X1D26 P4E0 P8C0 P16B0 (*)
(*) This is the code in Main.xc in app_tiwisl_simple_webserver: XS1_PORT_4E 

From my starting question attachment #1 (2016 12 29 startKIT connections.pdf)
and in comments above:
    B6 X0D14 P4C0 P8B0 P32A28 (*)
(*) Meaning XC remapping is necessary and makes sense

It’s a strange library/module that needs a git branch to define these matters! Has XMOS done their homework?

Update 9Jan2017: I have discovered group pin precedence (port precedence). See XS1 port-to-pin mappinghere. It’s also described in XS1 Ports: use and specification, see here. Quote from it:

The XS1 architecture has 16 logical ports, and the total number of pins by far exceeds the number of pins on the package. Ports, and Xlinks are therefore multiplexed, and there is a defined precedence when overlapping ports and links are used. The (SIC)

Also, there’s a way to display how a compiled mapping ended up, see Application Note: AN10100 How to display the pin, port and link mappings for a particular target, see here.

XCore: Atomicity of handling of port pins

See (29Dec2016)

The short answer (to how sharing of ports is handled) is that the compiler does parallel usage checks and will neither accept sharing of the same port nor sharing of the same variable between tasks. It issues variable/port “violates parallel usage rules”. I like it!

XCore: timerafter parameter

See (4Jan2017) Again some great answers.

I also commented on the replies in an entirely different blog note, see Know your timer’s type chapter “XMOS Xcore XE Community discussion group”.

XCore: Mapper output file: mapfile?

See (11Jan2017) Use:

XCC_FLAGS = -O2 -g -fxscope -save-temps
XCC_MAP_FLAGS = -Xmapper --map -Xmapper _Aquarium_map.txt -Xmapper -report

Also, there are some discussion on how to get an overview of the number of timers (timer or tmr) as used in a linked and mapped system. Basically it only allocates one timer per logical core. Read in the thread. But henk sums it up:

The architecture resource ‘timer’ maps onto the XC type ‘timer’.
There is two ways that this mapping can be achieved – soft, in which case the compiler conjures up one architecture-timer per thread, or hard, in which case the compiler allocates an architecture-timer for each timer declaration in XC. The latter enables the most efficient selects with multiple time-outs.

Indeed, port counters are something different, they count clock edges from an IO pin into a clock-block.

Update 12Jan2017: After this xTIMEcomposer 14.2.4 had “Binary viewer displaying information of compiled binary including resource usage” (here). Great!

XCore: xTIMEcomposer 14.2.4 on macOS 10.12 Sierra?

See (16Jan2017)

XCore: myif not used in two parallel statements (byte range 4..8)

See (18Jan2017)

XCore: System time tag of printf in xTIMEcomposer debug console

See (25Jan2017)

XCore: Debugger exit code or action

See (31Jan2017)

XCore: Calculating number of chanends

It’s very seldom that I don’t get a response. My guess is that this is rather sensitive information, part of XMOS’ competitive advantage, perhaps?

See (Feb2017)

XCore: Number of chanends on different boards?

See (Feb2017). Here’s the answer: “In short, every xcore tile in every chip we make has 32 channel ends. The startkit has one (XS1) tile available to the user, so has 32 channel ends on the available tile.” I think, minus one per tile if you’re using printf. See above, there may come some response to it there.

In [7] chan and chanend are defined as follows:

The chan type specifies a logical communication channel over which values can be communicated between parallel statements (§8.8). The chanend type specifies one end of a communication channel.
The locations of at most two implied ends of chan (themselves chanends) are defined through the use of the channel in at most two parallel statements (§8.8).
Channel ends are used as operands of input and output statements (§ 8.3). Channels are bidirectional and synchronised: an outputter waits for a matching inputter to become ready before data is communicated. Whether a streaming channel is synchronised or unsynchronised is implementation-defined

This means that there are two chanends per channel.

A quote for now, before a proper reply, perhaps:

Regarding the channel end numbering, I wouldn’t know how exactly the compiler/linker allocates channel numbers. I would always expect exactly 2 channel ends per channel and 0 or 2 channel ends per interface. 0 is for combined or distributed tasks, where functions break down into blocks of code running in one logical core.

XCore: Safe sprintf?

I was pointed to snprintf, which is safe. However, when I replaced all sprintf with snprintf I went from 50 to 62 kB memory. So it’s very expensive. This took me back to personal code review and made myself sure that all sprintf calls were safe. Also, I now check the return, it will inform of number of filled chars, including overflowed chars and/or terminating NUL.

See (Feb2017)

XCore: xCORE-XA end of life and ARM

See (Feb2017)

Xcore: Different results: correct when debugged but wrong when flashed

It was my fault! I had forgotten to initialise a variable!

See (Feb2017)

XCore: Improved error reporting for runtime exceptions within application code

See (Mar2017)


Wiki-refs: EclipseIDE, Nucleus RTOS

  1. adafruit monochrome 128×32 I2C OLED graphic display PRODUCT ID: 931, see
  2. XS1 Ports: use and specification, see
  3. Introduction to XS1 ports, see
  4. The XMOS XS1 Architecture by David May. Copyright © 2009 by XMOS Limited. ISBN: 978-1-907361-01-2 (PBK), ISBN: 978-1-907361-04-3 Published by XMOS Limited, see
  5. XC Reference Manual, 2008/07/16, by Douglas WATT Richard OSBORNE David MAY (VERSION 8.7), see[Y-M]).pdf
  6. XMOS Programming Guide (version E, Oct 09, 2014), see
  7. XC Specification, see
  8. Infineon Aurix processor
  9. Symtavision
  10. element14 community blog note by “shabaz”,
    – XMOS startKIT: Introduction, Terminology/Architecture, Getting Started and Example Programs, see It also has two sub-pages:
    – XMOS startKIT: Building an XMOS and Raspberry Pi Robot XMP-1 (with SPI) and
    – XMOS startKIT: XMOS and Raspberry Pi Oscilloscope XAE 1000 (with the ADC)
Email this to someoneShare on FacebookTweet about this on TwitterShare on LinkedIn

Leave a Reply

Your email address will not be published. Required fields are marked *


* Copy This Password *

* Type Or Paste Password Here *

8,731 Spam Comments Blocked so far by Spam Free Wordpress

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>