Unboxing my XMOS “StartKIT” and discovering xTIMEComposer under the hood

I got my free XMOS StartKIT courtesy of XMOS (THANK YOU!!):

http://www.xmos.com/startkit

Reading this:

https://www.cs.bris.ac.uk/~dave/hotslides.pdf

And start discovering lots of projects available at:

http://www.xcore.com/projects

First, connect the StartKIT via USB to the computer, use “lsusb” to discover the vid and pid. Update this into the /etc/udev/rules.d/80-xmos.rules:

ATTRS{idVendor}==”20b1″, ATTRS{idProduct}==”f7d3″, MODE=”0660″, GROUP=”plugdev”

And then “sudo service udev restart” to restart the udevd services.

The purpose of above procedure is so that access to the device via USB does not need to be root, but just ensure that the current user or owner is member of the “plugdev” group.

Downloaded the xTIMEComposer (13.2.1, 64-bit and my OS is Ubuntu 14.04 LTS 64-bit), and ensure that you have 64-bit Java. Unpack the tarball downloaded from www.xmos.com, and then starting up the “xtimecomposer”.   Many snapshots of xTIMEComposer can be found on the web:

https://www.google.com.sg/search?q=xtimecomposer&num=100&client=ubuntu&hs=nU0&channel=fs&source=lnms&tbm=isch

Autodetection of USB device will be done, and subsequently go through the tutorial to create your first application. Mine is “spinning app”:

https://github.com/xcore/sw_startkit_examples/tree/master/app_spinning_bar

Now, at this point, doing a process enumeration, we can see hat the xtimecomposer (pid=3472) has started “xgdb” process (pid=5511) to access the hardware device via USB:

tthtlc 3472 3471 1 19:38 pts/3 00:02:19 /usr/bin/java -Dcom.xmos.cdt.disableMozillaBrowserCreation=True -Dorg.eclipse.swt.browser.UseWebKitGTK=True -jar /home/tthtlc/Downloads/XMOS/xTIMEcomposer/Community_13.2.1/xtimecomposer_bin//plugins/org.eclipse.equinox.launcher_1.1.1.R36x_v20101122_1400.jar -os linux -ws gtk -arch x86_64 -showsplash -launcher /home/tthtlc/Downloads/XMOS/xTIMEcomposer/Community_13.2.1/xtimecomposer_bin/xtimecomposer.exe -name Xtimecomposer.exe –launcher.library /home/tthtlc/Downloads/XMOS/xTIMEcomposer/Community_13.2.1/xtimecomposer_bin//plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.1.2.R36x_v20101019_1345/eclipse_1310.so -startup /home/tthtlc/Downloads/XMOS/xTIMEcomposer/Community_13.2.1/xtimecomposer_bin//plugins/org.eclipse.equinox.launcher_1.1.1.R36x_v20101122_1400.jar -exitdata 20800e -vm /usr/bin/java -vmargs -Dcom.xmos.cdt.disableMozillaBrowserCreation=True -Dorg.eclipse.swt.browser.UseWebKitGTK=True -jar /home/tthtlc/Downloads/XMOS/xTIMEcomposer/Community_13.2.1/xtimecomposer_bin//plugins/org.eclipse.equinox.launcher_1.1.1.R36x_v20101122_1400.jar

tthtlc 5511 3472 0 21:28 pts/3 00:00:20 xgdb -q -nw -i mi2 –cd=/home/tthtlc/.xmos/repos/sw_startkit_examples/app_spinning_bar –command=.gdbinit /home/tthtlc/.xmos/repos/sw_startkit_examples/app_spinning_bar/bin/app_spinning_bar.xe

From above we learned that xTIMECOmposer create and stored its repository inside $HOME/.xmos directory (see pid=5511 above). “xc” is the extension for a C file to be compiled by “xcc”, and output file is “xe” as the extension. Using “xobjdump -d xxx.xe” we can list the assembly as below:

Loadable 1 for tile[0] (node “0”, tile 0):

Disassembly of section .text (size: 240)

<_start>:
0x00010000: 00 68: ldc (ru6) r0, 0x0
<…>
0x00010012: 40 6a: ldc (ru6) r9, 0x0
0x00010014: 00 f0 6c d8: ldap (lu10) r11, 0x6c <.label0>
0x00010018: fb 37: set (1r) cp, r11
0x0001001a: 00 f0 7b d8: ldap (lu10) r11, 0x7b <.label1>
0x0001001e: eb 37: set (1r) dp, r11
0x00010020: cb 6a: ldc (ru6) r11, 0xb

Detailed instruction sets described here:

https://www.xmos.com/download/public/XM-000324-RF-1.pdf

And listing the xgdb’s (pid=5511) /proc/5511/fd directory:

lrwx—— 1 tthtlc tthtlc 64 Jan 29 22:31 5 -> /dev/bus/usb/001/005

The line above indicate that the /dev/bus/usb/001/005 is open for both read and write.

Next is to trigger a “Run Configuration” to run the program on the device.

From “ps -ef” output we can see it is “xrun” that get executed (pid=6438):

tthtlc    6438  3472  0 22:52 pts/3    00:00:00 xrun –adapter-id 0ecxWIbrM.3O. –io /home/tthtlc/.xmos/repos/sw_startkit_examples/app_spinning_bar/bin/app_spinning_bar.xe

tthtlc    6443  6438  0 22:52 pts/3    00:00:00 xgdb -q –return-child-result –batch –ex set $xcore_id=0 –ex set $xcore_boot=0 -x /tmp/.xrun6438-3BP1TC2N/xeload_auto.gdb /home/tthtlc/.xmos/repos/sw_startkit_examples/app_spinning_bar/bin/app_spinning_bar.xe

Now xrun will fork a new process running xgdb (pid=6443).

So how was xgdb able to copy the program into the remote USB XMOS device from the PC host?

The details are covered in here (page 180):

http://www.farnell.com/datasheets/1838730.pdf

How the xcc compiler, is used is explained, and “xflash” command is shown it can be used to copy the program into the flash.   After the image is flashed, and subsequently how it is booted? The page below can provde some answer:

http://www.xcore.com/forum/viewtopic.php?f=7&t=2419

Hardware-wise, it is possible to integrate with RaspberryPi:

At the heart is this multicore processor:

http://en.wikipedia.org/wiki/XCore_XS1-L1

Hardware datasheet is mainly this two:

https://www.xmos.com/download/public/XS1-L01A-TQ128-Datasheet%28L%29.pdf

https://www.xmos.com/download/public/XS1-L02A-QF124-Datasheet%28N%29.pdf

Many other examples lies at:

https://github.com/xcore/sw_startkit_examples

After downloading, take a look at the startKIT_port_mapping.h to see all the portmap for programming hardware peripherals.

https://github.com/xcore/sw_startkit_examples/blob/master/startKIT_port_mapping.h

Another amazing feature is the XSwitch:

http://en.wikipedia.org/wiki/XSwitch

Other references:

• http://www.element14.com/community/groups/internet-of-things/blog/2014/05/05/xmos-startkit-introduction-terminologyarchitecture-getting-started-and-example-programs
• https://www.xmos.com/download/public/XCC-Target-Dependent-Behavior-for-XS1-Devices.pdf
• http://www.xmos.com/download/public/XCC-Command-Line-Manual%28X6904F%29.pdf
• https://www.xmos.com/support/xtools/documentation
• https://www.xmos.com/download/public/XS1-L01A-TQ128-Datasheet%28L%29.pdf
• http://www.iraqigeek.com/2014/01/02/an-introduction-to-xmos-xc-language/
• http://electronics.stackexchange.com/questions/7979/what-is-the-xmos-series

JTAG debugging using OpenOCD and Olimex ARM-USB-TINY-H on M24SR-Discovery

Setup (notice the M24SR-Discovery and Olimex JTAG debugger):

First download openocd and configure it for stlink:

http://xpcc.io/install/tools/openocd.html

http://www.fun-tech.se/stm32/OpenOCD/index.php

http://vedder.se/2012/12/debugging-the-stm32f4-using-openocd-gdb-and-eclipse/

Ensure that libusb and libftdi libraries are all setup/installed (as in above URLs).

Next create the following file (call it say “olimex_arm_usb_tiny_h.cfg”):

#
# Olimex ARM-USB-TINY-H
#
# http://www.olimex.com/dev/arm-usb-tiny-h.html
#

interface ftdi
ftdi_device_desc “Olimex OpenOCD JTAG ARM-USB-TINY-H”
ftdi_vid_pid 0x15ba 0x002a

ftdi_layout_init 0x0808 0x0a1b
ftdi_layout_signal nSRST -oe 0x0200
ftdi_layout_signal nTRST -data 0x0100 -oe 0x0100
ftdi_layout_signal LED -data 0x0800

adapter_khz 100
adapter_nsrst_delay 100
jtag_ntrst_delay 100

And next run the following command:

sudo openocd -f ./olimex_arm_usb_tiny_h.cfg -f /usr/local/share/openocd/scripts/target/stm32f4x.cfg -d3

and in another terminal:

telnet localhost 4444

Here in the 2nd terminal you can issue commands that step the CPU through instructions.

Displaying memory:

> mdb 0x0 10   
0x00000000: 48 58 00 20 45 01 00 08 ed 7a

All the “reg” related command:

> usage reg    
  arm mcr cpnum op1 CRn CRm op2 value
  arm mrc cpnum op1 CRn CRm op2
  arm reg
  dap apid [ap_num]
  flash write_image [erase] [unlock] filename [offset [file_type]]
gdb_sync
reg [(register_number|register_name) [(value|’force’)]]
    stm32f4x.cpu arm mcr cpnum op1 CRn CRm op2 value
    stm32f4x.cpu arm mrc cpnum op1 CRn CRm op2
    stm32f4x.cpu arm reg
    stm32f4x.cpu dap apid [ap_num]
>

All the registers:

> reg
===== arm v7m registers
(0) r0 (/32): 0x00000001
(1) r1 (/32): 0x00000020
(2) r2 (/32): 0x40010C00
(3) r3 (/32): 0x0000FFF6
(4) r4 (/32): 0x00000000
(5) r5 (/32): 0x00000000
(6) r6 (/32): 0xFE396247
(7) r7 (/32): 0xEDC477F9
(8) r8 (/32): 0xFDB4F1FF
(9) r9 (/32): 0x8A5FF960
(10) r10 (/32): 0xEC772E9E
(11) r11 (/32): 0x7D5BD5C2
(12) r12 (/32): 0x00000008
(13) sp (/32): 0x20005830
(14) lr (/32): 0x08008327
(15) pc (/32): 0x0800833A
(16) xPSR (/32): 0x01000000
(17) msp (/32): 0x20005830
(18) psp (/32): 0x3DFD7268
(19) primask (/1): 0x00
(20) basepri (/8): 0x00
(21) faultmask (/1): 0x00
(22) control (/2): 0x00
===== Cortex-M DWT registers
(23) dwt_ctrl (/32)
(24) dwt_cyccnt (/32)
(25) dwt_0_comp (/32)
(26) dwt_0_mask (/4)
(27) dwt_0_function (/32)
(28) dwt_1_comp (/32)
(29) dwt_1_mask (/4)
(30) dwt_1_function (/32)
(31) dwt_2_comp (/32)
(32) dwt_2_mask (/4)
(33) dwt_2_function (/32)
(34) dwt_3_comp (/32)
(35) dwt_3_mask (/4)
(36) dwt_3_function (/32)
>

Next is disassembling instructions:

 arm disassemble 0x0 256

0x000001ee  0xd3f6        BCC    0x000001de
0x000001f0  0xf7ffffa2    BL    0x00000138
0x000001f4  0x7b9c        LDRB    r4, [r3, #0xe]
0x000001f6  0x080f        LSRS    r7, r1, #0x20
0x000001f8  0x7bbc        LDRB    r4, [r7, #0xe]
0x000001fa  0x080f        LSRS    r7, r1, #0x20
0x000001fc  0xb570      PUSH    {r4, r5, r6, r14}
0x000001fe  0xeb010402    ADD.W    r4, r1, r2
0x00000202  0xf8105b01    LDRB    r5, [r0], #1    ; 0x00000001
0x00000206  0xf0150307    ANDS    r3, r5, #7    ; 0x00000007
0x0000020a  0xd101        BNE    0x00000210
0x0000020c  0xf8103b01    LDRB    r3, [r0], #1    ; 0x00000001
0x00000210  0x112a        ASRS    r2, r5, #0x04
0x00000212  0xd106        BNE    0x00000222
0x00000214  0xf8102b01    LDRB    r2, [r0], #1    ; 0x00000001
0x00000218  0xe003        B    0x00000222
0x0000021a  0xf8106b01    LDRB    r6, [r0], #1    ; 0x00000001
0x0000021e  0xf8016b01    STRB    r6, [r1], #1    ; 0x01
0x00000222  0x1e5b        SUBS    r3, r3, #1
>

And if you want to single step through the processor, “halt” first, then “step” through.

> step
target state: halted
target halted due to single-step, current mode: Thread
xPSR: 0x01000000 pc: 0x0800833e msp: 0x20005830
> step
target state: halted
target halted due to single-step, current mode: Thread
xPSR: 0x01000000 pc: 0x08008340 msp: 0x20005830
>
> step
target state: halted
target halted due to single-step, current mode: Thread
xPSR: 0x01000000 pc: 0x08002f6a msp: 0x20005830
>

If you are interested to know how to create binaries (using linker script) for this board:

http://www.triplespark.net/elec/pdev/arm/stm32.html

(to be noted is that M24SR-Discovery comes with F103 STM32 core, whereas the openocd config file labelled as “F4” is used and it worked.   “F1x” configuration files does not work.   Not sure why?)

Mbed programming: web-based development

Mbed-style of development is web-based. The compiler is hosted somewhere, you just select the appropriate compiler, and program binaries generated for you.

Then download the binaries to the root directory of the target device which you have selected to be compiled, and the functionality (eg, like Blinking LED) will start working.

https://developer.mbed.org/teams/mbed/code/mbed_blinky/

Select "Freedom FRDM-KL25Z as the compiler, and then compile and output the bin file.

THen copy the bin files to the root directory of the Freedom device, which should have a USB mass storage automatically (or at least alerted to user to be mounted) mounted by the Linux host (I used Fedora 20 64-bit, and Ubuntu 14.04 LTS 64-bit).

Reset the Freedom device, and there you will get a blinking LED.

Similarly, following the same procedure, and choosing the compiler for STM32 Nucleo L152RE board, I can easily implementing the LED Blinkiing program (the light green blinking LED) for a different device:

Reference:

http://sg.element14.com/freescale-semiconductor/frdm-kl25z/arm-kinetis-kl25z-freedom-dev-board/dp/2191861

http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/LN1847/PF260002?icmp=nucleo-ipf_pron_pr-nucleo_feb2014&sc=nucleoL152RE-pr

Developing and debugging Mesa libraries

Downloading the latest source code for Mesa: http://www.mesa3d.org/download.html

Compile thus:
./configure --prefix /sda3/mesa

where the directory is /sda3/mesa will be the temporary output directory of the compiled Mesa libraries files. This will enable us to run any OpenGL applications with just the Mesa libraries being loaded from /sda3/mesa.

Then make and “make install”, the directory /sda3/mesa will be populated with libraries and header files:
interface.h
│ │ ├── osmesa.h
│ │ ├── wglext.h
│ │ └── wmesa.h
│ └── KHR
│ └── khrplatform.h
└── lib
├── dri
│ ├── gallium_drv_video.la
│ ├── gallium_drv_video.so
│ ├── i915_dri.so
│ ├── i965_dri.so
│ ├── kms_swrast_dri.so
│ ├── nouveau_vieux_dri.so
│ ├── r200_dri.so
│ ├── r300_dri.so
│ ├── r600_dri.so
│ ├── radeon_dri.so
│ ├── swrast_dri.so
│ └── vmwgfx_dri.so
├── libEGL.la
├── libEGL.so -> libEGL.so.1.0.0
├── libEGL.so.1 -> libEGL.so.1.0.0
├── libEGL.so.1.0.0
├── libglapi.la
├── libglapi.so -> libglapi.so.0.0.0
├── libglapi.so.0 -> libglapi.so.0.0.0
├── libglapi.so.0.0.0
├── libGL.la
├── libGL.so -> libGL.so.1.2.0
├── libGL.so.1 -> libGL.so.1.2.0
├── libGL.so.1.2.0
└── pkgconfig
├── dri.pc
├── egl.pc
└── gl.pc

Then define “export LD_LIBRARY_PATH=/sda3/mesa/lib:$LD_LIBRARY_PATH” in the environment shell. After that, using the same environment shell, execute “python torusv1.py” to run some python progam (that does OpenGL graphics, for example,
https://github.com/tthtlc/sansagraphics ).

 

There after use gdb to attach to the python process:

First see all the loaded libraries:
"info sharedlibraries":

(gdb) info sharedlibrary
From To Syms Read Shared Object Library
0x00007f6c99a99610 0x00007f6c99a9ac96 Yes (*) /usr/lib/python2.7/lib-dynload/_hashlib.x86_64-linux-gnu.so
0x00007f6c99716dc0 0x00007f6c9980669f Yes (*) /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
0x00007f6c9941a3f0 0x00007f6c994840d6 Yes /sda3/mesa/lib/libGL.so.1
0x00007f6c991d3b90 0x00007f6c991ec759 Yes (*) /lib/x86_64-linux-gnu/libexpat.so.1
0x00007f6c98f91150 0x00007f6c98fa80d0 Yes /sda3/mesa/lib/libglapi.so.0
0x00007f6c98d5b580 0x00007f6c98d64ce0 Yes (*) /usr/lib/x86_64-linux-gnu/libXext.so.6
0x00007f6c98b50b90 0x00007f6c98b5149b Yes (*) /usr/lib/x86_64-linux-gnu/libXdamage.so.1
0x00007f6c989494e0 0x00007f6c9894b708 Yes (*) /usr/lib/x86_64-linux-gnu/libXfixes.so.3
0x00007f6c987405e0 0x00007f6c987406eb Yes (*) /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1

From above we can see that “libGL.so.1” is loaded. Next, trying out some API which is found in libGL.so.1:

Breakpoint 381, glBindBuffer (target=34962, buffer=1) at ../../src/mapi/glapi/glapi_mapi_tmp.h:5677
5677 const struct mapi_table *_tbl = entry_current_get();
(gdb) bt
#0 glBindBuffer (target=34962, buffer=1) at ../../src/mapi/glapi/glapi_mapi_tmp.h:5677
#1 0x00007f6c99ca5adc in ffi_call_unix64 () from /usr/lib/x86_64-linux-gnu/libffi.so.6
#2 0x00007f6c99ca540c in ffi_call () from /usr/lib/x86_64-linux-gnu/libffi.so.6
#3 0x00007f6c99ebc5fe in _ctypes_callproc () from /usr/lib/python2.7/lib-dynload/_ctypes.x86_64-linux-gnu.so
#4 0x00007f6c99ebdf9e in ?? () from /usr/lib/python2.7/lib-dynload/_ctypes.x86_64-linux-gnu.so
xxx
xxx
xxx
#25 0x0000000000469663 in ?? ()
#26 0x00000000004699e3 in PyRun_FileExFlags ()
#27 0x0000000000469f1c in PyRun_SimpleFileExFlags ()
#28 0x000000000046ab81 in Py_Main ()
#29 0x00007f6c9b191ec5 in __libc_start_main (main=0x46ac3f <main>, argc=2, argv=0x7fff4528a378, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff4528a368)
at libc-start.c:287
#30 0x000000000057497e in _start ()

And listing the source code (the binary program will cross-reference the source code downloaded for compilation):

(gdb) list
5672 ((void (APIENTRY *)(GLenum target, GLuint id)) _func)(target, id);
5673 }
5674
5675 GLAPI void APIENTRY GLAPI_PREFIX(BindBuffer)(GLenum target, GLuint buffer)
5676 {
5677 const struct mapi_table *_tbl = entry_current_get();=====>
5678 mapi_func _func = ((const mapi_func *) _tbl)[461];
5679 ((void (APIENTRY *)(GLenum target, GLuint buffer)) _func)(target, buffer);
5680 }

And so there you go is the generic analysis.