My xCORE-200 eXplorerKIT notes (WiFi)

Started 6Aug2017, updated 19Sept2017

This page is in group Technology where I will try to add matters about my XMOS xCORE-200 eXplorerKITs that I haven’t found elsewhere. I purchased two of these boards in the summer of 2017. It turned out to become an XMOS embedded WiFi blog note. Also see My XMOS notes and XC is C plus X about the rest of what I have ddfrom this universe.

Please study the whole table of context first, that may save you a lot of time if you are looking for something special.


Standard disclaimer, this is just for fun. No money, gifts, ads etc. Also, my non-association with XMOS, see here.

Fold handling

This blog note uses the Collapse-O-Matic WordPress plugin to handle text folding, as you may see in the “Limited selfrefs” chapter below. It’s used mostly for code examples. In addition to expanding and closing them idividually you may here:

Expand All
Collapse All


This fold is expanded.
Use “Expand All” (above) to make all folds expanded: visible, searchable and printable!

You may want to use Expand All while printing from the browser or while doing text searches.


The board is described in [1].

Fig.1 – XMOS xCORE-200 eXplorerKIT idle current measurement. Older 1A Apple iPhone USB power adaptors seen

Notes 1: Some detail

  1. Idle current consumption as it comes out of the box @ USB 5V is about 75 mA (→375 mW). Measured with no code and when not connected to xTIMEcomposer
  2. The xTAG3 1V2 [7] (that comes in the box) doesn’t seem to add anything to the idle current consumption
  3. Most of the components are on the top. There are some capacitors and low-power resistors  underneath. They would be low-temp and little to be afraid of. Besides, the four plastic mounting pieces do add some air. So I guess it’s ok to mount them in something I think is polystyrene foam, even it was flammable when I tested it. I could glue it with my standard contact adhesive (or double sided tape that it came glued with) – and nicely cut it with my FET table saw. eXplorerKIT sadly isn’t shipped in a nice foam like the startKIT. So I found some from my pile of different kinds that I have not ditched over the years
  4. The MAC address is on a label at the bottom. I made a new label for the top so that it’s available when the board is quite fastened in my fixture

Notes 2: Power-good LEDs

The hardware manual [2] doesn’t tell where the 5V power-good LED is. It’s seen below (press on it to get a PDF to print out, cut and glue in place; but screen layout is here). 3.3V was already shown as P, but I made it look the same. (Press picture for a PDF):

Fig.2 – xCORE-200 eXplorerKIT Hardware Manual with 5V LED (press to get PDF)

Notes 3: WiFi sliceCARD via PCIe/GPIO?

I didn’t order the xCORE-200 sliceKIT (here) simply because I wanted a smaller board with Ethernet on the board. (I wasn’t in time-scope to consider its obsoleted forerunner up to Jan 2017, the xCORE-200 general purpose sliceKIT (here))

I did know that I would have to connect my WiFi sliceCARD myself. I want to test out the WiFi sliceCARD SW with the XMOS xCORE-200 eXplorerKIT but later see if I could move that SW to the startKIT. I would learn a new board, and I would not in the first round be bound by pins already having been used by my aquarium controller that uses a startKIT (picture here). The long goal is to try to get the aquarium controller visible over WiFi. (WiFi sliceCARD is also written: Wi-Fi sliceCARD)

I have made a summary of how the PCIe connector is used (press picture for a PDF):

Fig.3 – XMOS slice I/O with examples from xCORE-200 sliceKIT, startKIT and WiFi sliceCARD (press for PDF)

Looking in [2] we see that we might have trouble picking up 25M_STAR, 25M_TRI and SLI_RST_N that on the xCORE-200 sliceKIT are connected to a tile 0 sub circuit, and not to any pin that would available on the xCORE-200 explorerKIT. However, by looking at the WiFi sliceCARD we see that these pins are not used. (More about STAR, SQUARE, TRIANGLE and CIRCLE at XCore: Wi-Fi sliceCARD and ports on startKIT.)

I conclude from this that I cannot on the xCORE-200 explorerKIT connect a general one-to-one PCIe sliceCARD connector break-out board that I might solder myself.

However, I would be able to find pins to connect the WiFi sliceCARD to the xCORE-200 explorerKIT since 25M_STAR, 25M_TRI and SLI_RST_N are not used. (I have a Sullins Connector Solutions NWE18DHHN-T931 CONN PCI EXP FEMALE 36POS 0.039 that I found here).

XCore: Connecting a WiFi sliceCARD to xCORE-200 eXplorerKIT?

I queried about this at XCore Exchange, see Connecting a WiFi sliceCARD to xCORE-200 eXplorerKIT?

My WiFi sliceCARD breakout board

I made the board! Also, the code runs! (Not without problems, 11Sept2017: stay tuned)

  • The SPI slave in the library runs at 12.5 MHz
  • The LSR Research TiWi-SL chip [8] is an SPI Slave and handles clock rates of 0-16 MHz, and I have shown it to work also on the eXplorerKIT
  • It uses Texas Instrument SimpleLink™ Wi-Fi® CC3000 Software [9].
  • As we see later the Wi-Fi TiWi-SL Module Driver supports TCP connections.

I connect it on J1 on eXplorerKIT to the same port pins as the SLICE CONNECTOR on the startKIT. So I won’t have to redefine the port pins for two. Not that it would have mattered, but it was OK to make the breakout board that way since it became wide enough to be solid enough. I’ve wiped out the MAC address label on this picture (press for more pixels):

Fig.4 – WiFi sliceCARD starKIT-like breakout board for J1 on eXplorerKIT (press for more pixels)

I used a standard breadboard (1/10″ spacing = 2.54 mm) and a non-holed glass fibre board that I bored 1.5 mm holes in (1 mm spacing but zic-zac layout made it not that tight for the holes). I soldered with wires underneath. No shaking hands! I removed unused breadboard matter above J1, so that it’s easier to use the free I/O ports at the same time.

+3.3V isn’t available on J1 so I pick it from the centre pin (P2) of J14. Since +5.0V is P1 I have made it impossible to connect it wrongly with an interlock part filling up J14 entirely.

And here’s the diagram. Observe that the XMOS diagram correctly shows B8 as GND but also wrongly shows the unconnected B3 and B16. See this with Fig.3 above. (Press picture for a PDF):

Fig.5 – Diagram of WiFi sliceCARD starKIT-like breakout board for J1 on eXplorerKIT (press for PDF)


Added after the correct files and libraries search below had been done: The two XC typedefs in main.xc contain all the port pin definitions. I only needed to change the port placement of BIT0 of wifi_tiwisl_ctrl_ports_t from 0x4E to 0x4C. Both of these are parameterised to wifi_tiwisl_server in file wifi_tiwisl_server.xc in module module_wifi_tiwisl. Then they are used by functions like wifi_tiwisl_spi_init -> spi_master_init (in module_spi_master [sc_spi]) -> configure_clock_rate (intrinsics)

on tile[0]: spi_master_interface tiwisl_spi =
    XS1_CLKBLK_1, // Clock block 1
    XS1_CLKBLK_2, // Clock block 2
    XS1_PORT_1K,  // MOSI SPI_MO  Data Out (when Master). Input  SPI_DI at WiFi module
    XS1_PORT_1J,  // CLK  SPI_CLK
    XS1_PORT_1I,  // MISO SPI_MI  Data In (when Master).  Output SPI_DO at WiFi module

on tile[0]: wifi_tiwisl_ctrl_ports_t tiwisl_ctrl =
    XS1_PORT_4C, // Was XS1_PORT_4E in downloaded code
                 // nCS     #SPI_CS   Chip Select  is port BIT0 low
                 // nPWR_EN #SPI_EN   Power Enable is port BIT1 low
    XS1_PORT_1L, // nIRQ    #SPI_IRQ  Interrupt    is port BIT  low

Then, the spi_master_interface file spi_master.h in module_spi_master [sc_spi] is defined as follows.

typedef struct spi_master_interface
    clock blk1;               // at XS1_CLKBLK_1
    clock blk2;               // at XS1_CLKBLK_2
    out buffered port:8 mosi; // at SPI_MO  8-bit buffered output (MOSI: Master Output Slave Input)
    out buffered port:8 sclk; // at SPI_CLK 8-bit buffered output
    in buffered port:8 miso;  // at SPI_MI  8-bit input input     (MISO: Master Input Slave Output)
} spi_master_interface;

Installing the drivers, which and from where?

I am not certain if this is structured correctly. Maybe it’s not structured at all. Bear with me, once I find a structure of what I’m trying to structure I’ll try to structure it. (Disclaimer: this doesn’t necessarily mean that XMOS hasn’t given it any structure).

From when I started (but didn’t finish) trying this for the startKIT I had the first three modules installed in xTIMEcomposer:

  1. [sc_wifi] – 1v0. These  have the same tag
    1. Status: installedmodule_wifi_tiwisl 
    2. Status: installedapp_tiwisl_simple_webserver
    3. Status: installed – test_webclient_pkt_gen but it doesn’t show [sc–wifi] in xTIMEcomposer
    4. Status: ? – I assume this is a newer version of module_wifi_tiwisl? However, the [Wi-Fi TiWi-SL Module Driver –  1.1.1rc0.a November 11, 2013] (Wi-Fi TiWi-SL Module Driver) is probably what I’m after. It says “This component drives the TiWi-SL Wi-Fi module fitted on the XA-SK-WIFI sliceCARD. The TiWi-SL module is a SPI slave and is clocked at 12.5 MHz. Supports TCP connections.” I think the code are the three first points here
      In xtcp_client.h we see XTCP_PROTOCOL_TCP (Transmission Control Protocol) and XTCP_PROTOCOL_UDP (User Datagram Protocol. Not supported in this version)
    5. Status: ? – Demo code: [TiWi-SL Simple Webserver Demo Quickstart Guide – 1.1.1rc0.a November 11, 2013], at here. It says “This application uses the XA-SK-WIFI sliceCARD together with the xSOFTip module_wifi_tiwisl and demonstrate: Connecting to a wireless access point, Run a simple HTTP webserver to display a “Hello World!” webpage.”
    6. Status: installed  Embedded Webserver Library [lib_webserver – 2.0.1 January 07, 2016]. See
    7. 1.1-3h have I once downloaded from GiHub; the WiFi Repository [sc_wifi – 1.1.2rc0] at GitHub ( The bundle sc_wifi-master comes with the modules and apps above, but also with the extra files Makefile, LICENSE.txt,  README.rst  (lLatest release: 1.1.2rc0), xpd.xml and CHANGELOG.rst. (Changes to dependencies: sc_spi1.4.0rc0 – so it’s not been tested with 1.4.0rc1)
  2. [sc_spi] – 1v0. These  have the same tag
    1. Status: installed – module_spi_master
    2. Status: installed – module_spi_slave
    3. Status: installed – app_spi_loopback_demo
    4. Status: installed – app_spi_master_demo
    5. 2.1-4 I once downloaded from GitHub; the SPI SOFTWARE COMPONENT [1.4.0rc1]. See The bundle sc_spi_master comes with the modules and apps above, but also with the extra files Makefile, LICENSE.txt,  README.rst (latest release 1.4.0rc1), xpd.xml and CHANGELOG.rst (Changes to dependencies: sc_slicekit_support1.0.4rc0)
  3. I deleted 1.1 and 2.1-2 to try to start afresh. But as the list below grew longer and longer I undid that. (I undid by using “Import”, “Import Existing Projects into Workspace” from my backup.) The scheme right now is to install every piece of code I can find and then see. After all I am a sw engineer, it’s not magic!
  4. But I did start with rereading a thread I started on XCore a while ago: Chicken and egg: xTIMEcomposer and GitHub.
  5. Status: installed – SPI Library [lib_spi –  3.0.2 January 07, 2016]. Found in the Libraries tab that searches content from in xTIMEcomposer. See
  6. There is no xCORE-200 eXplorer support module or library. But there may be something in these two:
  7. Status: installed  module_slicekit_support [sc_slicekit_support]. Unknown version, probably 1.0.4rc0 since it’s mentioned above
  8. Status: installed  Slicekit Core Board Support Library [lib_slicekit_support – 2.0.1 January 07, 2016] from Libraries tab in xTIMEcomposer. See
  9. Now maybe it’s time to start at the present presentation WiFi sliceCARD [3] (or here). It presents these papers:
    1. sliceKIT Modular Development System Product Brief [1.3 – April 16, 2014]
    2. sliceKIT Selector Sheet [4.0 – May 30, 2014]
      • WI-FI sliceCARD
        The Wi-Fi sliceCARD uses a high performance 2.4GHz WLAN module to bring 802.11b/g wireless connectivity to sliceKIT, with throughput of up to 7Mbps. Using the ready-built xSOFTip SPI component, it allows you to easily integrate the wireless module into your application. Our xSOFTip Explorer tool includes demo apps and full documentation to get you started quickly
    3. sliceKIT daughtercard port mappings [1.0 – April 27, 2014]
    4. GPIO Wi-Fi Demo Quick Start Guide [1.0.4rc0.a – March 12, 2013]
      • It is here. It says “This example demonstrates the use of two Slice Cards, XA-SK-GPIO and XA-SK-WIFI slice together with the xSOFTip components for Wi-Fi, SPI, I2C and WebServer to provide access to the GPIO slice features via a simple embedded webserver.”
  10. Dead end:
    Instead I went to GitHub at where I found [lib_wifi – 0.0.2]: lib_wifi. But I think this is a newer, more generalised library and not what I’m looking for. It’s dependent on lib_xtcp(>=5.1.0) lib_ethernet(>=3.0.3) lib_gpio(>=1.0.0) lib_filesystem(>=0.0.1) lib_xassert(>=2.0.0) lib_logging(>=2.0.0) lib_locks(>=2.0.2) but it doesn’t say anything about tiwisl. (Update: Gothmag on XCore Exchange replied that “lib_wifi does seem to be a newer lib if they properly supported it but I’m not sure they do, as in it seems almost entirely abandoned by them and I don’t think a slice with that wifi module was ever released. They also don’t seem to have any lib/module/examples accessible from within xTimeComposer itself as you mentioned.”)
  11. I’ll keep you posted about how I pick the SW as it develops. I want to end up with something that should run on the startKIT as well as the xCORE-200 eXplorerKIT


[app_tiwisl_simple_webserver]: TiWi-SL Simple Webserver Demo Quickstart Guide: “This application uses the XA-SK-WIFI sliceCARD together with the xSOFTip module_wifi_tiwisl and demonstrate: * Connecting to a wireless access point, * Run a simple HTTP webserver to display a “Hello World!” webpage.”

  1. In Makefile I changed the target to XCORE-200-EXPLORER
  2. And of course I now use XTAG3 ([7])
  3. In xhttpd.xc I inserted my values for WIFI_SSID and WIFI_PASSWORD
  4. In main.xc I modified wifi_tiwisl_ctrl_ports_t bit0 from XS1_PORT_4E to XS1_PORT_4C
  5. Bingo! It worked the absolute first time I ran it! The XMOS WiFi and SPI (++) code worked, my WiFi sliceCARD SPI breakout board worked, as well as the WiFi sliceCARD. Here’s the proof: The xTIMEcomposer window. The Apple AirPort Utility (I removed most of the values) plus a Safari browser tab. “Hello world!”

Fig.6 – XMOS **WELCOME TO THE SIMPLE WEBSERVER DEMO** (press for fullpixel)

Here’s the build log, built with xTIMEcomposer 14.3.0. I have added colours: module_wifi_tiwisl module_spi_master and _app_tiwisl_simple_webserver to see what belongs to where:

Build log

xmake all 
Checking build modules
Using build modules: module_wifi_tiwisl module_spi_master
Analyzing httpd.c
Analyzing hci_helper.c
Analyzing hci_pkg.c
Analyzing tiwisl_event_handler.c
Analyzing main.xc
Analyzing xhttpd.xc
Analyzing xtcp_client.xc
Analyzing wifi_tiwisl_server.xc
Analyzing wifi_tiwisl_spi.xc
Analyzing spi_master.xc
Creating dependencies for spi_master.xc
Creating dependencies for wifi_tiwisl_spi.xc
Creating dependencies for wifi_tiwisl_server.xc
Creating dependencies for xtcp_client.xc
Creating dependencies for xhttpd.xc
Creating dependencies for main.xc
Creating dependencies for tiwisl_event_handler.c
Creating dependencies for hci_pkg.c
Creating dependencies for hci_helper.c
Creating dependencies for httpd.c
Compiling httpd.c
Compiling hci_helper.c
Compiling hci_pkg.c
Compiling tiwisl_event_handler.c
Compiling main.xc
Compiling xhttpd.xc
Compiling xtcp_client.xc
Compiling wifi_tiwisl_server.xc
Compiling wifi_tiwisl_spi.xc
Compiling spi_master.xc
Creating app_tiwisl_simple_webserver.xe
Constraint check for tile[0]:
  Cores available:            8,   used:          2 .  OKAY
  Timers available:          10,   used:          2 .  OKAY
  Chanends available:        32,   used:          2 .  OKAY
  Memory available:       262144,   used:      15292 .  OKAY
    (Stack: 2108, Code: 9184, Data: 4000)
Constraints checks PASSED.
Constraint check for tile[1]:
  Cores available:            8,   used:          1 .  OKAY
  Timers available:          10,   used:          1 .  OKAY
  Chanends available:        32,   used:          0 .  OKAY
  Memory available:       262144,   used:       1064 .  OKAY
    (Stack: 348, Code: 596, Data: 120)
Constraints checks PASSED.
Build Complete

Wireless device roles

I think that the roles [4] here go as follows: The WiFi sliceCARD logs onto the master wireless router and gets its ip address from it. After this the WiFi sliceCARD communicates with client itself, directly. This is a according to a range of protocol, starting (I think) with 802.11up to TCP, and these are all handled by the LSR Research TTiWi-SL board’s ARM processor (again: [8]). I can actually observe this direct communication by seeing that getting the Hello World! text on the phone and then walking around the house, I lose it quite fast, while the network itself is well within range. My routers (master and bridge) don’t seem to be involved.

However, should my application need to get something from the internet the communication would of course be routed over the WiFi router into the Wide Area Network (WAN) wire to my Internet Service Provider (ISP).

Of course, the ip address needs to be on your wireless network. I have an internal Wi-Fi network with access to my network disks, and one for guest. So, to impress my kids who come home every now and then and fire up a connection on the guest network, I’d have to do my homework first.

Analysis and xSCOPE

  1. I made a project _app_tiwisl_simple_webserver derived from app_tiwisl_simple_webserver to get my own changes in there
  2. I added a counter seen as  “Hello World! 123” that was incremented for every http GET
  3. I saw that even if parse_http_request was run within some hundred ms when I pressed update in the browser it took 1-2 seconds before the Hello World! 124 was seen in the browser. Where is the delay? I want to analyse with the tools that are integrated with xTIMEcomposer. So this certainly is about time:
  4. I hadn’t used xSCOPE before so I downloaded AN00196 Getting started with real time xSCOPE in xTIMEcomposer Studio. The scope sw reminds me of the rather strange gui of my bitscope USB scope (described here). What is a button’s name and what is a state, rather confusing. The PDF that came with AN00196 didn’t describe it all; I should have started with xTIMEcomposer User GuidePart G: Application Instrumentation and Tuning [5].
    – The code just sending 64 values values to xSCOPE took about 0.1 ms. But when I added a printf (or even two) it took 3000 ms, an decrease of time of 30.000 times. I also added a round count and made that a second probe. This was an interesting exercise, because that linear curve didn’t fill up as much of the window as the sine. It only went from first trigger to last trigger of the sine (press for full screen):

    Fig.7 – xSCOPE short “round”

    – But this is logical, it shows the calls to xscope_int in that range. When I instead put the call to both values’ xscope_int inside the loop both were visible full width (press for full screen):

    Fig.8 – xSCOPE wide “round”

    – It also took me some time to learn to increase or decrease values in the gui; like Samples/Div. Increase by left mouse button, decrease by right button. And that the granularity of Offset is defined by the Samples/Div value.
    – The above screen clips are Real-Time Mode, with no axis names. However, ticking Offline Mode in the Run configurations file will generate a log file (.xmt) that when opened is seen in a client that sets up axis names and gives me better tools to analyse

  5. Aside: When I analyse the code I see XC transaction being used. This is the first time I see it. In the main webserver thread in xhttpd.xc in _app_tiwisl_simple_webserver the transaction xtcp_event is the only event that hangs on the main select. But xtcp_event resides in i completely different library, in module_wifi_tiwisl file xtcp_client.xc. This is rather nice and certainly couldn’t be done in occam
  6. I have added printouts in function httpd_handle_event in file httpd.c, called from the main webserver thread, like this – so that I can remove the printouts easily. Courtesy C #define macro for debug printing at stackoverflow (for a timed version of this, see debug_tc_printf later on):
    #define DEBUG_PRINT_HTTPD 1 // 0 no printouts and no code
    #define debug_printf(fmt, ...) \
        do { \
            if(DEBUG_PRINT_HTTPD) \
                printf(fmt, __VA_ARGS__); \
        } while (0) // gcc-type ##__VA_ARGS__ doesn't work
    debug_printf ("not httpd_handle_event %u %s\n", conn->event, "XTCP_IFUP new ip address");

Loading SPI_CLK is no good

If I connect the SPI_CLK output pin (search to see its definition) to my BitScope USB scope I get a crash when I run in xTIMEcomposer. That goes even if I use a USB isolator. The scope has internal impedance of 1M||50pF. The crash I get looks like this:

[  606 ms] Switching on Wi-Fi module.... 
[  657 ms] init
[ 1761 ms] WriteN 1 10   // In wifi_tiwisl_spi_first_write
[ 2416 ms] read2 1 ff.ff // After last spi_master_in_buffer in wifi_tiwisl_spi_read 
                         // in file wifi_tiwisl_spi.xc in module module_wifi_tiwisl
xrun: Program received signal ET_ILLEGAL_PC, Illegal program counter.
      [Switching to tile[0] core[1]]
      0xffffffff in ?? ()

This is 100% repeatable. If I connect the scope when it’s started OK then all is fine. Red text is mine.

  • If connect a 1M||47pF between SPI_CLK and GND then it hangs after the “init” text. Repeatable
  • If connect a 1M||47pF between SPI_CLK and 3V3 then it hangs after the “WriteN 1 10” text. Repeatable
  • If I connect any of these when it’s started OK, it stops. I even see it stop during startup with just the 20 cm wire hanging on SPI_CLK

I can understand the complete stop behaviour since the code does blocking calls waiting for things to go high or low with no timeout. But then, the SPI_CLK is just an output, isn’t it?

But the elegant message from xrun is more than I understand. How can the program counter become illegal? What’s going on?

I made an XCore Exchange entry for this point. See

Hello World! works, but it takes long time to finish (1)

  1. Here are two Hello World! sequences (in blue, colours and bold added for blog note only). Without using xSCOPE now I can easily see that the wasted time is between XTCP_SENT_DATA and XTCP_CLOSED. The conn->event enum values are nice to have for later, when analysing an xSCOPE curve offline. Later I have also added the timing as observed in xSCOPE Offline mode. They would fluctuate some:

    Hello World internal log (1)

    TCP in operation:

    Switching on Wi-Fi module.... ok!
    Connecting to OM11-4
    IP Address:
    not httpd_handle_event 9 XTCP_IFUP new ip address
    httpd_handle_event 0 XTCP_NEW_CONNECTION // Time: 0.00 sec
    httpd_handle_event 1 XTCP_RECV_DATA      // Time: 0.05 sec
    GET "Hello World!" 1 
    httpd_handle_event 2 XTCP_REQUEST_DATA   // Time: 0.27 sec
    httpd_handle_event 3 XTCP_SENT_DATA      // Time: 0.32 sec
                                             //       What is it doing now?
    httpd_handle_event 7 XTCP_CLOSED         // Time: 1.39 sec
    httpd_handle_event 0 XTCP_NEW_CONNECTION
    httpd_handle_event 1 XTCP_RECV_DATA
    GET "Hello World!" 2
    httpd_handle_event 2 XTCP_REQUEST_DATA
    httpd_handle_event 3 XTCP_SENT_DATA
    httpd_handle_event 7 XTCP_CLOSED

    Next is #hello_world_internal_log_2 (below)

  2. The xTIMEcomposer xSCOPE screen clip in Offline mode for the above is seen below. Press for fullpixel. (Well, there are 5 sequences). There seems to be some x-axis offset error, 2 is not at 2 and 7 is just above 6.

    Fig.9 – xSCOPE of the above

  3. When I, in the web browser pressed update quite fast (in order to see if the web client then didn’t close the connection) I got this error message. I will investigate later on.
    xrun: Program received signal ET_ILLEGAL_RESOURCE, Resource exception.
          send_cmd (conn_id=0, cmd=XTCP_CMD_CLOSE, c_xtcp=2147614978) at /module_wifi_tiwisl/src/xtcp_client.xc:14
          14            c_xtcp <: cmd;
    <terminated>_app_tiwisl_simple_webserver.xe [xCORE Application]
            <terminated, exit value: 125>xrun (13:58 23.08.17)
    <terminated>_app_tiwisl_simple_webserver.xe [xCORE Application]
            <terminated, exit value: 125>xrun (13:59 23.08.17)
  4. Observe that wifi_tiwisl_server.xc causes these warnings if -Wall is set in Makefile -Wshadow, -Wsign-compare, -Wswitch-default. XMOS should have issued an update to avoid them as they are totally unnecessary. I didn’t do that, so I can’t have -Wall


Now is the time for profiling the code. xTIMEcomposer may generate files for Gprof. It’s described in [6]. It looks to me like tile[1]:core[1] is used for xSCOPE and that user code is placed in tile[0].core[1]. Here’s the gprof window:

Fig.10 – Gprof window

The code spends 68% of its time in function wifi_tiwisl_spi_read in file wifi_tiwisl_spi.xc in module_wifi_tiwisl. Below is the xmos code. I think it must be the line that waits for the irq line that would be the one that burns most of the cycles. The location is 0x41a9e, but how do I ensure that this is the place? I couldn’t find it in the mapfile (see how to make it here). I’ll research some more. (Trying to debug with asm window)

// spi_master_read
void wifi_tiwisl_spi_read(spi_master_interface &spi_if,
                          wifi_tiwisl_ctrl_ports_t &spi_tiwisl_ctrl,
                          unsigned char buffer[],
                          unsigned short num_bytes,
                          int bypass_cmd)
  // Wait for IRQ to be low
  spi_tiwisl_ctrl.p_spi_irq when pinseq(0) :> void;
  // Assert CS
  spi_tiwisl_ctrl.p_cs_pwr <: ASSERT_NCS;
  if (!bypass_cmd)
    // Issue the read command
    spi_master_out_buffer(spi_if, spi_read_header, SPI_READ_SIZE);
  // Read the SPI data from device
  spi_master_in_buffer(spi_if, buffer, num_bytes);

It’s probably no problem to burn cycles here. I assume that the rest of the code can’t do anything before the TiWi-SL chip has data for it. Any such spin-loop (passive in the code, that nice one-liner) that would block for any other task would have gotten a separate core. Since the xmos coder hasn’t done that then I assume it’s ok. So I don’t think this explains the long time after XTCP_SENT_DATA before XTCP_CLOSED. Of course, if this spinning reflects some application level protocolling back and forth that takes a lot of time then that would probably falsify my conclusion above.

Adding a get_time_now function to use with c files

In order to print out present time in us in front of every debug_printf (see above) I made this new macro.

Observe that “On XMOS XS-1 devices the clock will run at 100MHz” (XMOS Programming Guide). Therefore it counts to 100 in a μs (XS1_TIMER_MHZ in timer.h), which we have to divide by. This also means that it wraps around after 2exp32=4294967296 100 MHz pulses = 42949 ms. So in our case we use ms by dividing with XS1_TIMER_KHZ (100*1000):

#define debug_t_printf(fmt, ...) \ /* not thread safe, see below */
do { \
        timer p_time; \
        unsigned p_time_now; \
        p_time :> p_time_now; \
        printf ("[%5u ms] ", p_time_now/XS1_TIMER_KHZ); \
        printf(fmt, __VA_ARGS__); \
    } \
} while (0) // gcc-type ##__VA_ARGS__ doesn't work for XC

You’ll find timed printf also discussed at XCore Exchange here.

However, it could only be used in an .xc file, since the global timer isn’t available from c. I needed this from httpd.c. I then added this function in xtcp_client.xc since it was used by httpd.c:

unsigned get_time_now (void) {
    timer p_time;
    unsigned p_time_now;
    p_time :> p_time_now;
    return p_time_now; // Wraps at 2expp32 = 4294967296 100 MHz counts (42949 ms)

I then could get the time and print it out in httpd.c like this:

#define debug_tc_printf(fmt, ...) \ /* not thread safe, see below */
do { \
        unsigned p_time_now = get_time_now(); \
        printf ("[%5u ms] ", p_time_now/XS1_TIMER_KHZ); \
        printf(fmt, __VA_ARGS__); \
    } \
} while (0) // gcc-type ##__VA_ARGS__ doesn't work (correction in debug_tc_printf2)

Observe that the above debug_tc_printf macros are not atomic (ie. not thread safe). In this example I see this when it prints from module_wifi_tiwisl and httpd_handle_event which are par placed on different logical cores. I solved this by adding [..] around every debug_t_printf on one core and (..) around the other. It would look like this on one crash core crash (I added colour coding for this note):

-- Not thread safe --
[ 2160 ms] [readN 2390 N=21]
[ 2211 ms] [deassert]
( 2262 ms) (httpd_handle_event 2 XTCP_REQUEST_DATA)
( 2313 ms) [ 2313 ms] (httpd_handle_event 3 XTCP_SENT_DATA)
[writeN 1193 N=202]
[ 3425 ms] [read2 2391 00.0b]

It’s not elegant. I’ll look at the suggestion in XCore Exchange shown above, but if this one isn’t safe I guess it isn’t either. I guess they have to be collapsed into one single printf, which seems to be thread safe. Update: the XCore Exchange shown above solution is not atomic either. I tried it for those above.

Atomic, thread safe version timed printf

I have posted a question on stackoverflow about this. See How do I use variadic arguments with printf in a macro?. Kerrek SB did come up with an atomic thread safe solution. Observe the sequence of params to printf and no comma (token pasting) before fmt:

// Wraps at 2exp32 = 4294967296 100 MHz counts (42949 ms)
#define debug_t_printf2(fmt, ...) \ /* is thread safe */
do { \
        timer p_time; \
        unsigned p_time_now; \
        p_time :> p_time_now; \
        printf("[%5u ms] " fmt, p_time_now/XS1_TIMER_KHZ, __VA_ARGS__); \
    } \
} while (0) // gcc-type ##__VA_ARGS__ doesn't work

// Shortest usage since ## not allowed for XC: 
debug_t_printf2 ("%s", "Hello World!\n");

and for C. Observe that ##__VA_ARG__ is allowed:

// Wraps at 2exp32 = 4294967296 100 MHz counts (42949 ms)
#define debug_tc_printf2(fmt, ...) \ /* is thread safe */
do { \
        unsigned p_time_now = get_time_now(); \
        printf("[%5u ms] " fmt, p_time_now/XS1_TIMER_KHZ, ##__VA_ARGS__); \
    } \
} while (0) // gcc-type ##__VA_ARGS__ allowed

// Shortest usage since ## is allowed for C: 
debug_tc_printf2 ("Hello World!\n");

The thread safe log now goes like this. After this I will remove the [..] and (..) decorations:

-- Thread safe --
[28241 ms] [readN 9132 N=21]
[28293 ms] [deassert]
(28344 ms) (httpd_handle_event 2 XTCP_REQUEST_DATA)
(28394 ms) (httpd_handle_event 3 XTCP_SENT_DATA)
[28394 ms] [writeN 4562 N=202]
[29504 ms] [read2 9133 00.0b] 

Hello World! works, but it takes long time to finish (2)

The reason for the long timing seems to be the rather large amount of bytes being sent across the SPI bus. The only thing I need to understand now is why the connection is closed every time, when that seems to take most of the time.

Previous was #hello_world_internal_log_1 (above).

Hello World internal log (2)

TCP in operation:
Some legend:

  • All printf lines start with ms timing like [1647 ms] or (2317 ms). All the others are my comments (except for long hex data that wrap the lines)
  • poll-b is at “Periodically check for new connections, data to send and incoming data” in wifi_tiwisl_server in wifi_tiwisl_server.xc
  • poll-e is at the end of the sequence printed as poll-b. It prints out time since poll-b
  • I have added hex to ascii conversions as well
  • I didn’t care to decode all the cmd with the TiWi-SL chip
  • Observe that the log below takes way much longer time because I print out each byte. But relative times between each line is still interesting
[ 1647 ms] poll-b
[ 1697 ms] writeN 79 N=14:
[ 1803 ms] read2 161 00.15
[ 1854 ms] readN 162 N=21:
[ 1955 ms] deassert
[ 2006 ms] writeN 80 N=34: 01.00.1d.
[ 2163 ms] read2 163 00.09
[ 2214 ms] readN 164 N=9:
[ 2266 ms] deassert
( 2317 ms) httpd_handle_event 0 XTCP_NEW_CONNECTION
[ 2367 ms] writeN 81 N=22:
[ 2469 ms] read2 165 00.11
[ 2520 ms] readN 166 N=17:
[ 2624 ms] deassert
( 2675 ms) httpd_handle_event 1 XTCP_RECV_DATA
[ 2675 ms] read2 167 01.7d
[ 2779 ms] readN 168 N=381:
Non-ascii in [..]:
…[2][133][24]w[1][2][0][0][0][12][0][0][0]_[1][0][0][0][0][0][0][0][0][0][0][0][0][0][0]GET / HTTP/1.1[13][10]Host:[13][10]Upgrade-Insecure-Requests: 1[13][10]Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8[13][10]User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8[13][10]Accept-Language: nb-no[13][10]Accept-Encoding: gzip, deflate[13][10]Connection: keep-alive[13][10][13][10][0]
[ 3761 ms] deassert
[ 3815 ms] poll-e used 2168 ms
( 3815 ms) GET "Hello World! 2"
[ 3916 ms] poll-b
[ 3970 ms] writeN 82 N=14:
[ 4072 ms] read2 169 00.15
[ 4122 ms] readN 170 N=21:
[ 4224 ms] deassert
[ 4275 ms] writeN 83 N=22:
[ 4614 ms] read2 171 00.11
[ 4649 ms] readN 172 N=17:
[ 4750 ms] deassert
[ 4803 ms] poll-e used 887 ms
[ 4854 ms] cmd 5
[ 4905 ms] poll-b
[ 4956 ms] writeN 84 N=14:
[ 5059 ms] read2 173 00.15
[ 5114 ms] readN 174 N=21:
[ 5219 ms] deassert
( 5269 ms) httpd_handle_event 2 XTCP_REQUEST_DATA
( 5320 ms) httpd_handle_event 3 XTCP_SENT_DATA
[ 5320 ms] writeN 85 N=202: 01.00.c5.
Non-ascii in [..]:
[1][0][197][0][0][2][129][16][192][0][2][0][0][0][12][0][0][0][176][0][0][0][0][0][0][0]HTTP/1.0 200 OK[10]Server: xc2/pre-1.0 ([10]Content-type: text/html[10][10]<!DOCTYPE html>[10]<html><head><title>Hello world</title></head>[10]<body>Hello World! 2 </body></html>

[ 6888 ms] read2 175 00.0b
[ 6945 ms] readN 176 N=11:
[ 6996 ms] deassert
[ 7047 ms] writeN 86 N=22:
[ 7314 ms] read2 177 00.11
[ 7353 ms] readN 178 N=17:
[ 7456 ms] deassert
[ 7510 ms] poll-e used 2604 ms
[ 7562 ms] cmd 7
[ 7613 ms] close_socket
[ 7668 ms] writeN 87 N=14:
[ 7775 ms] read2 179 00.09
[ 7823 ms] readN 180 N=9: 04.0b.
[ 7877 ms] deassert
[ 7927 ms] poll-b
( 7927 ms) httpd_handle_event 7 XTCP_CLOSED

[ 7981 ms] writeN 88 N=14:
[ 8188 ms] read2 181 00.15
[ 8239 ms] readN 182 N=21:
[ 8345 ms] deassert
[ 8396 ms] poll-e used 468 ms

Screen recording to see how Hello World! feels

Observe that pressing the Fig.11 causes a 9.2 MB MPEG-4 (.mp4) movie download!

It was produced on a Mac with QuickTime Player’s screen recording having Safari and xTIMEcomposer running. One sequence with little debug and one with much debug, into two QuickTime (.mov) movies with 1-1 pixel resolution from my 4096 pixel width screen. I made a single longer movie in iMove from both and exported as .mp4 1080 height. So it’s not as nice looking as the real thing. Another thing; I have cheated above, I actually added printf with always taking 5 char width after this recording!

You’ll have to scroll through the movie to try to correlate the logs with the behaviour of the browser. I also tried Chrome, it behaves like Safari but doesn’t visualise it as well. So no movie of Chrome.

What I don’t understand is the long interval after Hello World! 2 has arrived in the browser. It’s probably because I haven’t been this close to http before. The embedded fire detector software I have worked with didn’t use http. I’m climbing the http learning curve. That being said, this board behaves somewhat differently than other sites. It’s so much slower. Why, and does it have to be? Now I’ll scope the signals.


An “unsolicited event”

There is a TODO in tiwisl_event_handler.c in function event_checker:

int event_checker(int opcode, unsigned char *rx_buf)
  if (opcode == 0)
    //TODO: process_unsolicited_event(c_xtcp, rx_buf);
    debug_tc_printf ("#### #### Unsolicited event %u\n\n", *rx_buf); // Teig
    return 1;

Hello World internal log (3)

TCP in operation:
I added the printf there. It seems to come every time like this. I don’t yet know if rx_buf[0] is relevant (it’s always 4) at this stage. If it “delays” the server then it’s only after sending of all N=202 bytes, some 300 ms until XTCP_CLOSED. But I want to understand it:

(23884 ms) httpd_handle_event 3 XTCP_SENT_DATA
[23884 ms] writeN 5014 N=202: 
[24947 ms] read2 10035 00.0b
[25004 ms] readN 10036 N=11: 
[25005 ms] deassert
(25055 ms) #### #### Unsolicited event 4

[25162 ms] writeN 5015 N=22: 
[25167 ms] read2 10037 00.11
[25216 ms] readN 10038 N=17: 
[25216 ms] deassert
[25267 ms] writeN 5016 N=14: 
[25278 ms] read2 10039 00.09
[25320 ms] readN 10040 N=9: 
[25320 ms] deassert
(25374 ms) httpd_handle_event 7 XTCP_CLOSED

I also see this unsolicited event at other places! Stay tuned, I think I know what that is.

Digging deeper: SPI, HCI, TCP

Digging deeper, not finished yet:

HCI events compared

The Texas Instruments hci.h [9] and the Adafruit (more later) hci.h [10] would have the same event list:

#define HCI_EVNT_WLAN_UNSOL_BASE (0x8000)
#define HCI_EVNT_WLAN_UNSOL_INIT               (0x0004 + HCI_EVNT_WLAN_UNSOL_BASE)
#define HCI_EVNT_WLAN_TX_COMPLETE              (0x0008 + HCI_EVNT_WLAN_UNSOL_BASE)
#define HCI_EVNT_WLAN_UNSOL_DHCP               (0x0010 + HCI_EVNT_WLAN_UNSOL_BASE)
#define HCI_EVNT_WLAN_KEEPALIVE                (0x0200 + HCI_EVNT_WLAN_UNSOL_BASE)
// Only in Adafruit code:
#define HCI_EVNT_ASYNC_ARP_DONE                (0x0400 + HCI_EVNT_WLAN_UNSOL_BASE)

The red entries map against XMOS hci_defines.h in module module_wifi_tiwisl in directory wifi_tiwisl go like this. I need to find out:

#define HCI_EVNT_WLAN_UNSOL_BASE               (0x8000)
#define HCI_EVNT_WLAN_UNSOL_DHCP               (0x0010 + HCI_EVNT_WLAN_UNSOL_BASE)
#define HCI_EVNT_WLAN_KEEPALIVE                (0x0200 + HCI_EVNT_WLAN_UNSOL_BASE)
I can’t really find HCI defined in Wkipedia or found well defiend by a net search. However, closer to this note I find HCI I see mentioned in [8](2) as:

The main interface to the TiWi-SL Module is a Serial Peripheral Interface (SPI).
This section describes the SPI Host Controller Interface (HCI).

It then goes on to describe the pins SPI_CLK, SPI_DI, SPI_CS, SPI_IRQ, SPI_DO. By seeing the HCI_EVNT_WLAN_UNSOL_BASE (in fold, above) I then infer that HCI is a memory mapped protocol in the layer above the hardware SPI pins. And XMOS has the spi_master_interface in file spi_master.h that takes care of the same pins (clocks and ports).


XMOS: Here you can see how a TCP in file xtcp_cmd.h (typedef below) is using HCI commands:

// XMOS hci_pkg.c
#define HCI_CMND_SOCKET                            0x1001
#define HCI_CMND_BIND                              0x1002
#define HCI_CMND_RECV                              0x1004
#define HCI_CMND_ACCEPT                            0x1005
#define HCI_CMND_LISTEN                            0x1006
#define HCI_CMND_CLOSE_SOCKET                      0x100B
#define HCI_CMND_SETSOCKOPT                        0x1009
#define HCI_CMND_SEND                             (0x81)
#define HCI_CMND_READ_BUFFER_SIZE                 (0x400B)
#define HCI_CMND_SIMPLE_LINK_START                (0x4000)
#define HCI_CMND_WLAN_IOCTL_SET_SCANPARAM          0x0003
#define HCI_CMND_WLAN_CONNECT                     (0x0001)
#define HCI_CMND_EVENT_MASK                       (0x0008)

// adafruit and TI hci.h (only one shown)

// XMOS xtcp_cmd.h
// Teig annotated with numbers:
typedef enum xtcp_cmd_t {
  XTCP_CMD_LISTEN,             //  (0) 0x00
  XTCP_CMD_UNLISTEN,           //  (1) 0x01
  XTCP_CMD_CONNECT,            //  (2) 0x02
  XTCP_CMD_BIND_LOCAL,         //  (3) 0x03
  XTCP_CMD_BIND_REMOTE,        //  (4) 0x04
  XTCP_CMD_INIT_SEND,          //  (5) 0x05
  XTCP_CMD_SET_APPSTATE,       //  (6) 0x06
  XTCP_CMD_CLOSE,              //  (7) 0x07
  XTCP_CMD_ABORT,              //  (8) 0x08
  XTCP_CMD_TIMED_OUT,          //  (9) 0x09
  XTCP_CMD_JOIN_GROUP,         // (11) 0x0b
  XTCP_CMD_LEAVE_GROUP,        // (12) 0x0c
  XTCP_CMD_GET_MAC_ADDRESS,    // (13) 0x0d
  XTCP_CMD_GET_IPCONFIG,       // (14) 0x0e
  XTCP_CMD_ACK_RECV,           // (15) 0x0f
  XTCP_CMD_ACK_RECV_MODE,      // (16) 0x10
  XTCP_CMD_PAUSE,              // (17) 0x11
  XTCP_CMD_UNPAUSE,            // (18) 0x12
  XTCP_CMD_UPDATE_BUFINFO,     // (19) 0x13
  XTCP_CMD_WIFI_ON,            // (21) 0x15 sends 
                               //           HCI_CMND_SIMPLE_LINK_START
                               //           HCI_CMND_READ_BUFFER_SIZE
                               //           HCI_CMND_EVENT_MASK
                               //           HCI_CMND_WLAN_IOCTL_SET_CONNECTION_POLICY
  XTCP_CMD_WIFI_OFF,           // (22) 0x16
  XTCP_CMD_DISCONNECT          // (23) 0x17
} xtcp_cmd_t;

For each HCI_CMND… (fold, above) there is a blocking wait for the response in function read_and_wait_for_event in file  wifi_tiwisl_server.xc, the nice XCORE XC select with wait for the IRQ is not used. Function wifi_tiwisl_spi_read hangs on a pin change like this: spi_tiwisl_ctrl.p_spi_irq when pinseq(0) :> void; but if WiFi module doesn’t work it will hang forever, but the channel c_xtcp/c_wifi reply from wifi_tiwisl_server might be timed out by its controlling task xhttpd. But it doesn’t.

TI: HCI command by function like SimpleLink_Init_Start

Texas Instruments: For TI (can’t find it in Adafruit code) the HCI_CMND_SIMPLE_LINK_START is wrapped in a function call SimpleLink_Init_Start in file wlan.c with the text “send HCI_CMND_SIMPLE_LINK_START to CC3000”. It then does a blocking wait for the response in SimpleLinkWaitEvent. Also, since hci_event_handler must have some response to terminate, a faulty CC3000MOD will cause the entire application to hang.

Adafruit did it with the TI CC3000MOD module

The Adafruit company in New York is very good on documentation. Even if their HUZZAH CC3000 WiFi Shield [10] has been discontinued (before Sept2017), there is lots of documentation and code there.

As we saw above the Adafruit protocol talking with that module over SPI is the same as talking with the LSR Research TiWi-SL module on the XMOS WiFi sliceCARD since the latter runs the same protocol (Texas Instrument SimpleLink™ Wi-Fi® CC3000) on board their built-in ARM. Files hci.h (TI, Adafruit) and hci_defines.h (XMOS) have the same code base.

Below is the highlight from [10]. Of course, the CC3000 on the Adafruit board may be newer and thus implement more:

The CC3000 hits that sweet spot of usability, price and capability. It uses SPI for communication (not UART!) so you can push data as fast as you want or as slow as you want. It has a proper interrupt system with IRQ pin so you can have asynchronous connections. It supports 802.11b/g, open/WEP/WPA/WPA2 security, TKIP & AES. A built in TCP/IP stack with a “BSD socket” interface. TCP and UDP in both client and server mode, up to 4 concurrent sockets. It does not support “AP” mode, it can connect to an access point but it cannot be an access point.

By the way. Adafruit now has two products (Arduino WiFi Shield 101 and ATWINC1500 WiFi Breakout) that contains the Atmel/Microchip module ATWINC1500. (ATWINC1500-MR210PB has PCB antenna and ATWINC1500-MR210UB has U.FL connector for external antenna, Adafruit sell both). Adafruit says that it has “SSL support, soft-AP capability, and is more reliable.”. This may mean that the CC3000 isn’t that reliable? The Shield 101 also contains an Atmel/Microchip CryptoAuthentication chip type ATECC508. However, I see Adafruit points to Arduino’s page for the  Arduino WiFi Shield 101 product (code: ASX00001) where it says RETIRED.

I queried about this at the Adafruit forum at ARDUINO WIFI 101 SHIELD RETIRED? AND WHAT NOW? Here is the main response from an Adafruit person:

the atwinc modules do not have any EOL info, so we dont know anything. however, they seem to be readily available so we have no plans to discontinue our boards!
the cc3000 modules were essentially discontinued by TI many years ago, with slow but steady ‘refusal to fix bugs or respond to support requests’ so we discontinued them. the atwinc work much better and cost less, anyhow 🙂

Standard disclaimer, like for all of my blog notes). I’ll buy a couple of the latter.

Another nice thing Adafruit shows is a Cloud thermometer that from the embedded board only uses very little code (even if the signing process requires multiple SHA-256 hash computations) to refer to Javascript that’s handled by Amazon DynamoDB, entered by the AWS browser javascript SDK [11]. Could this be somewhat related to how Netatmo can take over data for me?

I have taken this into a new blog noteMy single-board boards and why notes

Notes 4: XTAG3 LEDs

[7] tries to explain where the LEDs are positioned on the XTAG3 (XTAG-3) but since I didn’t understand it I made my own from it. (Press picture for a PDF, also to print tabs to tape beside it):

Fig.12 – XTAG-3 LED layout (Disclaimer: only checked by me) (Press for PDF, also to print out tabs)

The text about each LED is of course XMOS’, so you have to read [7]. It says that the LEDs function is “clockwise, starting from the power button on the bottom right” that I didn’t grasp. That power button probably is SW1. It’s not mounted and it’s not at the bottom right.

I started clockwise from the one and only LED that lit when I powered the XTAG3. It is D7 in the print. So the “first” is D7 (Power). Clockwise from it we have in the print D2 (Run), D3 (Status), D1 (Target), D4 (xSCOPE) and D8 (JTAG).  When I ran the debugger the behaviour did make sense. But I need a disclaimer: don’t send it to Mars based on this.


Wikipedia: falsifiabilityGprof,  ISP (Internet Service Provider), SHA-1 (Secure Hash Algorithm 1, also including SHA-256),  SPI (Serial Peripheral Interface Bus), TCP (Transmission Control Protocol), U.FL RF connectorWAN (Wide Area Network), Wi-Fi (WiFi)

  1. xCORE-200 eXplorerKIT, see Part: XK-EVK-XE216. Silicon on Board: XE216-512-TQ128, xCORE-200 XE/XEF: GIGABIT ETHERNET, see
  2. xCORE-200 explorerKIT Hardware Manual, (XM007647C) 2015/10/20, see
  3. WiFi sliceCARD by XMOS, see
  4. Types of Wireless Networks, see
  5. xTIMEcomposer User Guide, see
  6. XMOS Application Note: AN10124: How to profile an executable on hardware, see
  7. xTAG v3.0 Hardware Manual, XMOS 2015. It’s called XTAG3 or XTAG-3. It contains an XS1-U8see
  8. TiWi-SL Self-contained 802.11 b/g WLAN module, see that contains lots of documentation. Like:
    (1) Product Brief:
    TiWi-SLTM 802.11 b/g Wi-Fi® Module with Application Processor, see It states that:
    “TiWi-SL is the industry’s first industrial temp-rated 802.11 b/g Wi-Fi module. It has been designed for simple connectivity to the industry’s most popular microcontroller platforms. It utilizes Texas Instruments’ CC3000 SimpleLinkTM technology to move nearly all the functions required for Wi-Fi off the host processor and onto the module.”
    (2) Datasheet:
    TiWi-SL MODULE DATASHEET Integrated 802.11 b/g WLAN Module, see It points to [9] and it mentions HCI (Host Controller Interface)
    (3) EM BOARD User Guide
    TIWI-SL EM BOARD User Guide where they show that “Texas Instruments has developed Wireless LAN software examples that run on the MSP-EXP430FR5739 Experimenter Board. Further specifics on the examples can be found on the Connectivity wiki at …” first link below.
    (4) Getting Started with TiWi-SL
    It points to [9]
  9. Texas Instrument’s data base of CC3000 Software
    The problem is that in Sept2017 the Texas Instruments (TI) documents that LS Research (LSR) refers to in their page and documents (above) have been removed and replaced with newer versions: 
    (1) Documents removed by TI
    Getting Started with TiWi-SL. The TI CC3000 Wiki contains a wealth of information to quickly start developing applications with TiWi-SL. Information on supported hardware platforms and example software can be found there. Even if it’s removed, see
    (2) Active documents by TI
    Texas Instrument SimpleLink™ Wi-Fi® CC3000 Software, see
    (3) C code library
    CC3000-PLATFORMDRIVER: CC3000 Platform Independent Wi-Fi Driver, ACTIVE 1.11.1 29-OCT-2013, see
  10. Adafruit HUZZAH CC3000 WiFi Shield with Onboard Antenna, see
  11. Adafruit Cloud thermometer, see
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 *

11,756 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>