From Technologic Systems Manuals
Jump to: navigation, search
Note: The TS-7553-V2 is currently in engineering sample phase. This means software and features are very likely to change as the TS-7553-V2 is currently under heavy development. There may also be some features that are currently not implemented or not fully tested, please see the Revisions and changes for more information.

Product Page
Mechanical Drawing
FTP Path
528MHz or 696MHz
i.MX6UL Product Page
CPU Documentation


1 Overview

Note: This product has not been released as a standard product at this time. Information contained within this manual may be incorrect and is subject to change. Additionally, the software currently available for the TS-7553-V2 has not been finalized and is subject to change at any time

The TS-7553-V2 has not been officially released as a standard product, it is currently in engineering sampling phase. This is a small embedded platform with an NXP i.MX6UL 528 MHz or 696 MHz CPU with 512 MB DDR3 RAM.

2 Getting Started

A Linux PC is recommended for development, and will be assumed for this documentation. For users in Windows or OSX we recommend virtualizing a Linux PC. Most of our platforms run Debian and if you have no other distribution preference this is what we recommend.


Suggested Linux Distributions

It may be possible to develop using a Windows or OSX system, but this is not supported. Development will include accessing drives formatted for Linux and often Linux based tools.

2.1 Booting up the board

WARNING: Be sure to take appropriate Electrostatic Discharge (ESD) precautions. Disconnect the power source before moving, cabling, or performing any set up procedures. Inappropriate handling may cause damage to the board.

The TS-7553-V2 has an input voltage range of 5 V to 28 V DC through the main power connector which offers screw terminals for secure wiring or a barrel jack. The TS-7553-V2 will require approximately 1.4 W at idle. An ideal power supply for the TS-7553-V2 will allow up to 5W to allow peripherals to be powered as well.

Once power has been applied, output will be available on the serial console. The next section of the manual provides information on getting the console port set up. The first output is from the bootrom and will look like the following:

U-Boot 2016.03-14510-gf8f09c6 (Feb 16 2017 - 16:25:11 -0800)

CPU:   Freescale i.MX6UL rev1.1 at 396 MHz
Reset cause: WDOG
Board: Technologic Systems TS-7553-V2
I2C:   ready
DRAM:  512 MiB
Net:   FEC0 [PRIME]
Booting from the SD card ...
** File not found /boot/boot.ub **
32618 bytes read in 56 ms (568.4 KiB/s)
6735792 bytes read in 438 ms (14.7 MiB/s)
Kernel image @ 0x80800000 [ 0x000000 - 0x66c7b0 ]
## Flattened Device Tree blob at 83000000
   Booting using the fdt blob at 0x83000000
   Using Device Tree in place at 83000000, end 8300af69

Starting kernel ...

Welcome to Debian GNU/Linux 8 (jessie)!

[ SKIP ] Ordering cycle found, skipping D-Bus System Message Bus Socket
         Expecting device dev-ttymxc0.device...
[  OK  ] Reached target Remote File Systems (Pre).
[  OK  ] Started Update UTMP about System Runlevel Changes.

Debian GNU/Linux 8 ts-imx6ul ttymxc0

ts-imx6ul login:

The U-Boot build date reflects when U-Boot was built and serves as a revision indicator. A change to the kernel or filesystem will not affect this date.

2.2 Get a Console

2.2.1 Serial Console

The TS-7553-V2 includes a USB device port, this uses a 8051 based microcontroller to create a serial device on a host PC. The serial console is provided through this port at 115200 baud, 8n1, with no flow control.

Console from Linux

There are many serial terminal applications for Linux, but 3 common implementations would be picocom, screen, and minicom. These examples assume that your COM device is /dev/ttyUSB0 (common for USB adapters), but replace them with the COM device on your workstation.

Linux has a few applications capable of connecting to the board over serial. You can use any of these clients that may be installed or available in your workstation's package manager:

Picocom is a very small and simple client.

picocom -b 115200 /dev/ttyUSB0

Screen is a terminal multiplexer which happens to have serial support.

screen /dev/ttyUSB0 115200

Or a very commonly used client is minicom which is quite powerful:

minicom -s
  • Navigate to 'serial port setup'
  • Type "a" and change location of serial device to '/dev/ttyUSB0' then hit "enter"
  • If needed, modify the settings to match this and hit "esc" when done:
     E - Bps/Par/Bits          : 115200 8N1
     F - Hardware Flow Control : No
     G - Software Flow Control : No
  • Navigate to 'Save setup as dfl', hit "enter", and then "esc"

Console from Windows

Putty is a small simple client available for download here. Open up Device Manager to determine your console port. See the putty configuration image for more details.

Device Manager Putty Configuration

3 U-Boot

Note: These sections are incomplete at this time.

This platform includes U-Boot as the bootloader to launch the full operating system. When the i.MX6ul processor starts it loads u-boot from the on-board SPI flash. This allows booting images from the microSD, eMMC, NFS, or USB. U-Boot is a general purpose bootloader that is capable of booting into common Linux distributions, Android, QNX, or others.

On a normal boot you should see something similar to this:

U-Boot 2016.03-14510-gf8f09c6 (Feb 16 2017 - 16:25:11 -0800)

CPU:   Freescale i.MX6UL rev1.1 at 396 MHz
Reset cause: POR
I2C:   ready
DRAM:  512 MiB
Net:   FEC0 [PRIME]
Booting from the SD card ...
** File not found /boot/boot.ub **
32618 bytes read in 56 ms (568.4 KiB/s)
6735792 bytes read in 438 ms (14.7 MiB/s)
Kernel image @ 0x80800000 [ 0x000000 - 0x66c7b0 ]
## Flattened Device Tree blob at 83000000
   Booting using the fdt blob at 0x83000000
   Using Device Tree in place at 83000000, end 8300af69

Starting kernel ...

By default the board will boot to SD or eMMC depending on the status of the "SD Boot" jumper on startup.

3.1 Entering U-Boot shell

The U-Boot shell is a powerful tool. It allows modification of the environment, as well as the ability to run commands directly. By default, there are two ways to enter the shell: Set the U-Boot jumper, or press and hold the Push Switch before applying power and hold it for 5 seconds. When entering the U-Boot shell, it will attempt to run a script on a USB mass storage device before finally dropping to the shell.

The reset switch is provided as a convenience, so U-Boot can be entered without having to open any kind of enclosure. It can also be disabled for security purposes. Even if the switch is disabled, the U-Boot shell can still be accessed by using the U-Boot jumper.

To disable the press-and-hold method of entering the U-Boot shell, use the following U-Boot commands:

env set env set rstuboot 0
env save

By setting the env var, rstuboot, to a 1, the push-and-hold method can be re-enabled.

3.2 U-Boot Environment

The SPI flash contains both the U-Boot executable binary and U-Boot environment. Our default build has 8KB of environment space which can be used for variables and boot scripts. The following commands are examples of how to manipulate the U-Boot environment:

# Print all environment variables
env print -a
# Sets the variable bootdelay to 5 seconds
env set bootdelay 5;
# Variables can also contain commands
env set hellocmd 'led red on; echo Hello world; led green on;'
# Execute commands saved in a variable
env run hellocmd;
# Commit env changes to the spi flash
# Otherwise changes are lost
env save
# Restore env to default
env default -a
# Remove a variable
env delete emmcboot

3.3 U-Boot Commands

# The most important command is 
# This can also be used to see more information on a specific command
help i2c
# This is a command added to u-boot by TS to read the baseboard id
echo ${baseboard} ${baseboardid} 
# The echos willreturn:
# TS-8390 2
# Boots into the binary at $loadaddr.  This file needs to have
# the uboot header from mkimage.  A uImage already contains this.
# Boots into the binary at $loadaddr, skips the initrd, specifies
# the fdtaddr so Linux knows where to find the board support
bootm ${loadaddr} - ${fdtaddr}
# Get a DHCP address
# This sets ${ipaddr}, ${dnsip}, ${gatewayip}, ${netmask}
# and ${ip_dyn} which can be used to check if the dhcp was successful
# These commands are used for scripting:
false # do nothing, unsuccessfully
true # do nothing, successfully
# This command lets you set fuses in the processor
# Setting fuses can brick your board, will void your warranty,
# and should not be done in most cases
# GPIO can be manipulated from u-boot.  Keep in mind that the IOMUX 
# in u-boot is only setup enough to boot the board, so not all pins will
# be set to GPIO mode out of the box.  Boot to the full operating system
# for more GPIO support.
# GPIO are specified in bank, IO in the imx6 manual.  U-boot uses a flat numberspace,
# so for CN2_83/EIM_OE this is bank 2 dio 25, or (32*2)+25=89
# Set CN1_83 low
gpio clear 83
# Set CN1_83 high
gpio set 83
# Read CN1_83
gpio input 83
# Control LEDs
led red on
led green on
led all off
led red toggle
# This command is used to copy a file from most devices
# Load kernel from SD
load mmc 0:1 ${loadaddr} /boot/uImage
# Load Kernel from eMMC
load mmc 1:1 ${loadaddr} /boot/uImage
# Load kernel from USB
usb start
load usb 0:1 ${loadaddr} /boot/uImage
# Load kernel from SATA
sata init
load sata 0:1 ${loadaddr} /boot/uImage
# You can view the fdt from u-boot with fdt
load mmc 0:1 ${fdtaddr} /boot/imx6q-ts4900.dtb
fdt addr ${fdtaddr}
fdt print
# You can blindly jump into any memory
# This is similar to bootm, but it does not use the 
# u-boot header
load mmc 0:1 ${loadaddr} /boot/custombinary
go ${loadaddr}
# Browse fat,ext2,ext3,or ext4 filesystems:
ls mmc 0:1 /
# Access memory like devmem in Linux, you can read/write arbitrary memory
# using mw and md
# write
mw 0x10000000 0xc0ffee00 1
# read
md 0x10000000 1
# Test memory.
# Check for new SD card
mmc rescan
# Read SD card size
mmc dev 0
# Read eMMC Size
mmc dev 1
# The NFS command is like 'load', but used over the network
env set serverip
nfs ${loadaddr}
# Test ICMP
# Reboot
# SPI access is through the SF command
# Be careful with sf commands since
# this is where u-boot and the FPGA bitstream exist
# Improper use can render the board unbootable
sf probe
# Delay in seconds
sleep 10
# You can load HUSH scripts that have been created with mkimage
load mmc 0:1 ${loadaddr} /boot/ubootscript
source ${loadaddr}
# Most commands have return values that can be used to test
# success, and HUSH scripting supports comparisons like
# test in Bash, but much more minimal
if load mmc 1:1 ${fdtaddr} /boot/uImage;
	then echo Loaded Kernel
	echo Could not find kernel
# Commands can be timed with "time"
time sf probe
# Print U-boot version/build information

3.4 Modify Linux Kernel cmdline

The Linux kernel cmdline can be customized by modifying the cmdline_append variable. If new arguments are added, the existing value should also be included with the new arguments.

env set cmdline_append rw rootwait console=ttymxc0,115200 quiet
env save

The kernel command line can also be modified from from the onboard Linux. From the linux shell prompt run the following commands to install the necessary tools and create the script:

apt-get update && apt-get install u-boot-tools -y
echo "env set cmdline_append rw rootwait console=ttymxc0,115200 quiet" > /boot/boot.scr
mkimage -A arm -T script -C none -n 'tsimx6ul boot script' -d /boot/boot.scr /boot/boot.ub

The boot.scr includes the plain text commands to be run in U-Boot on startup. The mkimage tool adds a checksum and header to this file which can be loaded by U-Boot. The .ub file should not be edited directly.

3.5 Linux NFS Boot

U-Boot's NFS support can be used to load a kernel, device tree binary, and root filesystem. The default scripts include an example NFS boot script. Because of the way U-Boot tries to infer server data, the script we use will bypass this, making it more straightforward to use an NFS root that will not be heavily dependent on a particular network configuration.

# Set this to your NFS server IP and NFS directory path
env set nfsroot
env save

To boot your NFS root:

# Boot to NFS once
run nfsboot;
# To make the NFS boot the persistent default
env set bootcmd run nfsboot;
env save

3.6 Linux USB Boot

By default, U-Boot will attempt to read a U-Boot script from a USB drive when the U-Boot jumper is set. It copies /tsinit.ub into memory and jumps in to the script. To make a bootable drive, create a single ext4 partition on a USB drive and unpack the rootfs tarball located here

The one addition is to create the tsinit.ub file in the root of the USB drive. In order to do this, a U-Boot script must be created and then converted to the .ub format. This process requires a set of U-Boot specific tools. These are available on most every linux distribution, the instructions below are for Debian, either run on a host PC or on the device itself. See the package installation documentation for other respective distributions.

Install U-Boot tools in Debian

apt-get update && apt-get install u-boot-tools -y

Create the file tsinit.scr in the root of the USB drive with the linux filesystem:

# Prepare with:
# mkimage -A arm -T script -C none -n 'imx6ul usb' -d tsinit.scr tsinit.ub
if load usb 0:1 ${loadaddr} /boot/ts${model}-fpga.vme;
        then fpga load 0 ${loadaddr} ${filesize};
load usb 0:1 ${fdtaddr} /boot/imx6ul-ts${model}.dtb;
load usb 0:1 ${loadaddr} /boot/zImage;
setenv bootargs root=/dev/sda1 rootwait rw ${cmdline_append};
bootm ${loadaddr} - ${fdtaddr};

Then in the same directory generate the tsinit.ub file:

mkimage -A arm -T script -C none -n 'imx6ul usb' -d tsinit.scr tsinit.ub

3.7 Update U-Boot

WARNING: Installing a custom U-Boot is not recommended and may cause the device to fail to boot.

The latest U-Boot binary can be downloaded from the TS-7553-V2 FTP site. Copy this file to /boot/u-boot.imx on the 1st partition of the SD card. The U-Boot binary can be updated by inserting that SD card in to the TS-7553-V2, setting the U-Boot and SD card jumpers, and powering up the unit. At the U-Boot prompt, the following command can be used:

run update-uboot

The above script will use the /boot/u-boot.imx file from the SD card or eMMC, depending on the state of the SD Boot jumper.

3.8 U-Boot Recovery

If the device is booted with the TS-9471 production device seated on the edge connector with a USB cable connected to a host linux PC, the device CPU will attempt to boot to the "USB Serial Downloader". If it is in this mode the host PC will show something similar to the following:

 hid-generic 0003:15A2:0054.0006: hiddev0,hidraw3: USB HID v1.10 Device [Freescale SemiConductor Inc  SE Blank ARIK] on usb-0000:00:14.0-6.4.2/input0

Once it is in this mode the imx USB loader can be used to boot the device.

After building imx_usb on the host PC, run "imx_usb u-boot.imx" to download the U-Boot binary to the device and let the CPU execute it. Then, the Update U-Boot instructions can be used to get the system permanently booting again.

Alternatively, if the U-Boot is erased you can submit an RMA for us to recover the board.

3.9 U-Boot Development

We do provide our U-Boot sources, but we do not recommend rebuilding a custom U-Boot binary as it can leave the system in an unbootable state.

If you still want to proceed with building a custom u-boot, use the master branch from the github here:

The cross compiler below can be installed via the instructions in the Cross Compiling section of the manual.

export ARCH=arm
export CROSS_COMPILE=arm-linux-gnueabihf-
make ts7553v2_defconfig
make u-boot.imx

This will output a u-boot.imx that can be written to the device using the steps in Update U-Boot.

3.10 POST

The TS-7553-V2 includes a simple POST test. This is normally used in production to verify basic functionality rapidly before doing more thorough testing. By default, this is not enabled on every boot, but it can be added via U-Boot scripting if there is a need for additional confidence in the application. The POST test quickly verifies basic functionality of: USB, RTC (if present), Ethernet PHY, WiFi/BT module (if present), eMMC (see warning below), RAM, and the supervisory microcontroller.

The post test can be run with the following command in U-Boot:


WARNING: The 'post' command has an optional "-d" argument; when this argument is passed it does a write and readback test of the eMMC which is DESTRUCTIVE to the data on the disk! Without this argument the eMMC chip is still tested for basic functionality, but no data is read or written from the disk itself.

4 Debian Configuration

For development it is recommended to go to Debian on the SD card where there is plenty of space for development work. Debian provides many more packages and a much more familiar environment for users already versed in Debian. Once here you can use apt-get to install/remove packages, configure the network, and perform other common tasks. Out of the box the Debian distribution does not have a custom username/password set. You can use "root" as the username with no password to get access to the system. Keep in mind services such as ssh require a password set before they allow connection.

4.1 Configuring the Network

From almost any Linux system you can use 'ip' command or the 'ifconfig' and 'route' commands to initially set up the network.

# Bring up the CPU network interface
ifconfig eth0 up
# Or if you're on a baseboard with a second ethernet port, you can use that as:
ifconfig eth1 up
# Set an ip address (assumes subnet mask)
ifconfig eth0
# Set a specific subnet
ifconfig eth0 netmask
# Configure your route.  This is the server that provides your internet connection.
route add default gw
# Edit /etc/resolv.conf for your DNS server
echo "nameserver" > /etc/resolv.conf

Most networks will offer a DHCP server, an IP address can be obtained from a server with a single command in linux:

Configure DHCP in Debian:

# To setup the default CPU ethernet port
dhclient eth0
# Or if you're on a baseboard with a second ethernet port, you can use that as:
dhclient eth1
# You can configure all ethernet ports for a dhcp response with

Systemd provides a networking configuration option to allow for automatic configuration on startup. Systemd-networkd has a number of different configuration files, some of the default examples and setup steps are outlined below.



To use DHCP to configure DNS via systemd, start and enable the network name resolver service, systemd-resolved:

systemctl start systemd-resolved.service 
systemctl enable systemd-resolved.service
ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf

For a static config create a network configuration for that specific interface.



For more information on networking, see Debian and systemd's documentation:

4.1.1 WIFI Client

If connecting to a WPA/WPA2 network, a wpa_supplicant config file must first be created:

wpa_passphrase yournetwork yournetworkpassphrase > /etc/wpa_supplicant/wpa_supplicant-wlan0.conf

Create the file /lib/systemd/system/wpa_supplicant@.service with these contents

Description=WPA supplicant daemon (interface-specific version)
ExecStart=/sbin/wpa_supplicant -c/etc/wpa_supplicant/wpa_supplicant-%I.conf -i%I

Next, enable the service to start up on boot:

systemctl enable wpa_supplicant@wlan0

Create the file /etc/systemd/network/ with:


See the systemctl-networkd example for setting a static IP for a network interface. The can be configured the same way as an To enable all of the changes that have been made, run the following commands:

systemctl enable wpa_supplicant@wlan0
systemctl start wpa_supplicant@wlan0
systemctl restart systemd-networkd

4.1.2 Host a Wi-Fi Access Point

First, hostapd needs to be installed in order to manage the access point on the device. Additionally, it is strongly recommended to install haveged, a tool for increasing system entropy. The extra entropy will allow for WPA2 connections to happen much more quickly:

apt-get update && apt-get install hostapd haveged -y

Note: The install process may start an unconfigured hostapd process. This process must be killed before moving foward.

Edit /etc/hostapd/hostapd.conf to have the following lines:

wpa_pairwise=TKIP CCMP
Note: Refer to the kernel's hostapd documentation for more wireless configuration options.

The access point can be started and tested by hand:

hostapd /etc/hostapd/hostapd.conf

Systemd auto-start with bridge to eth0

It is possible to configure the auto-start of hostapd through systemd. The configuration outlined below will set up a bridge with eth0, meaning the WiFi connection is directly connected to the ethernet network. The ethernet network is required to have a DHCP server present and active on it to assign WiFi clients a DHCP address. This setup will allow WiFi clients access to the same network as the ethernet port, and the bridge interface will allow the Device itself to access the network.

Set up hostapd

First, create the file /etc/systemd/system/hostapd_user.service with the following contents:

Description=Hostapd IEEE 802.11 AP
ExecStart=/usr/sbin/hostapd /etc/hostapd/hostapd.conf -P /run/ -B

Then enable this in systemd:

systemctl enable hostapd_user.service

Set up bridging

Create the following files with the listed contents.







4.1.3 Cellular Data Network

The TS-7553-V2 includes support for the Multitech MTSMC-G2 or MTSMC-H5 connected via the TS-DC767-MT daughter card, which can connect to the internet using pppd. The modem is attached to the HD1 Header, also called the Daughter Card interface. The modem itself can be configuring with the following command:

ln -s /dev/ttymxc6 /dev/ttymultidc

There are two GPIO pins that can control reset and RTS of the cell modem. These two pins default to an I2C mode, so before they can be used, they must have the pinmux set to GPIO. This can be done with the following two commands:

peekpoke 32 0x20e0118 0x5  #Set RTS pin to GPIO, GPIO 69
peekpoke 32 0x20e011c 0x5  #Set reset pin to GPIO, GPIO 70

The DIO pins can be controlled now from the linux GPIO subsystem. In order to function properly, the RTS pin must be low, and the reset must be high. This can be done with the following commands:

echo "69" > /sys/class/gpio/export
echo "70" > /sys/class/gpio/export
echo "low" > /sys/class/gpio/gpio69/direction
echo "high" > /sys/class/gpio/gpio70/direction

The pppd application must be installed and any required modules loaded:

apt-get update && apt-get install -y ppp

This example is configured for T-Mobile in the US:



connect "/usr/sbin/chat -v -f /etc/ppp/chatscripts/tmobile"
disconnect "/usr/sbin/chat -v -f /etc/ppp/chatscripts/tmobile-disconnect"



"" "\p\p\p\p\p\p\p\p\p\p\p\p+++\p\p\p\p\p\p\p\p\p\p\p\p"
"" "ATH0"

"OK" 'AT+CGDCONT=1,"IP",""'

OK 'ATD*99***1#'


"" "\K"
"" "+++ATH0"

Using a different carrier you will likely only need to replace with the access point for your carrier.

To start pppd:

pppd call tmobile
# Or for more logging information:
# pppd nodetach call tmobile

This will create a ppp0 interface that can now be used as a standard network interface, and should set up a default route to the internet. For other carriers, typically you will only need a different access point listed in the AT+CGDCONT call, but further adjustments may be necessary.

Faster Data Rates

While the MTSMC-G2 (GPRS) is limited to 115200 baud, the MTSMC-H5 (HDSPA) can communicate over serial up to 921600 allowing actual transfer rates around 80-90KB/s.

To set a custom baudrate in Linux, the method depends on the CPU and kernel support. More recent UART peripherals have a higher clock and a smarter driver, and can therefore use custom baud rates inherently. However, some systems require the use of 'setserial' using the spd_cust flag and some manual settings. When the spd_cust baud rate is set, Linux will re-purpose 38400 baud to use the set custom baud rate.

First, test the unit to see if it is possible to open up the UART with a higher baud rate:

picocom -b 921600 /dev/ttymultidc

If the higher baud is unsupported, picocom will return a failure similar to the following:

FATAL: failed to add device /dev/ttymultidc: Invalid baud rate

If the above error is received, then the method below using setserial must be used.

Otherwise, the port can be closed, re-opened at 115200 baud to communicate with the modem, and then the following command can be used to tell the cell modem to enter a higher baud rate:


Now the port can be closed everything will function at the higher baud rate. Be sure to update the providers file. Using the example T-Mobile configuration, edit /etc/ppp/peers/tmobile and change 115200 to 38400. Starting pppd will now allow communication around 80-90KB/s (depending on your local cell tower's availability).

Common Baud Rates
Divisor Rate
1 921600
2 460800
3 307200
4 230400
5 184320
6 153600
7 131657
8 115200

Larger divisors will also work, but this should cover the common range. Using the setserial command you can specify the divisor. For example, to reach 115200 with the alternative baud base:

setserial /dev/ttymultidc spd_cust baud_base 921600 divisor 8

Next you will need to tell the modem to communicate at the faster baud rates. You can use a client like picocom or minicom to connect directly to the modem to send it commands.

picocom -b 38400 /dev/ttymultidc

Even though we are talking at 115200, 38400 must be specified since we are using a custom baud_base. You can test communication with the modem again by typing "AT", pressing enter, and receiving "OK". To reconfigure the modem to the faster 921600 baud rate you can send it this command:


This will respond with OK, but now you will need to quit out of picocom (ctrl a,x) and reconfigure the baud base to use divisor 1:

setserial /dev/ttymultidc spd_cust baud_base 921600 divisor 1

The only change now needed is in your providers file. Using the example T-Mobile configuration , edit /etc/ppp/peers/tmobile and change 115200 to 38400. Starting pppd will now allow communication around 80-90KB/s (depending on your local cell tower's availability).


If you are not able to obtain a ppp connection there are a few values you can check:

Troubleshooting: Cell Signal

Make sure ppp is not running, and execute these commands to check the signal strength.

stty raw -echo speed 115200 -F /dev/ttymultidc 
cat /dev/ttymultidc &
echo -e "AT+CSQ\r\n" > /dev/ttymultidc 
killall cat

The return value should be something like "+CSQ: 9,2", or with no connection, +CSQ: 99,99. The second argument is the signal strengh which follows this table:

RSSI return values
0 -113 dBm or less
1 -111 dBm
2 to 30 -109 to -53dBm
31 -51dBm or greater
99 not known or detectable

If you return 99, make sure the antenna is connected and that you are in an area with good signal from your provider. Even without a valid SIM card you can have a good connection. If you are in another country, you may need to adjust the band for those supported by your carrier. The default value is appropriate for most US based carriers. Refer to the +WMBS command in your AT command guide for more options.

Troubleshooting: SIM card

If you have a good signal strength but are not obtaining a connection you can verify that the modem is able to read the subscriber number. This proves your SIM card is valid.

stty raw -echo speed 115200 -F /dev/ttymultidc 
cat /dev/ttymultidc &
echo -e "AT+CNUM\r\n" > /dev/ttymultidc 
killall cat

With a valid SIM this will return something like:

+CNUM: "","12345678901",129

If the SIM not detected you will only read ERROR. Make sure in this case that the card is inserted in the right direction so the pads on the card line up with the socket.

Troubleshooting: Other Options

If neither of the above steps get you connected you may want to contact your service provider for more information about where your connection attempts are failing.

4.2 Installing New Software

Debian provides the apt-get system which allows management of pre-built applications. First apt will need a network connection to the internet. The update command will download a list of prebuilt packages and the current version.

Debian provides the apt-get system which lets you manage pre-built applications. Before you do this you need to update Debian's list of package versions and locations. This assumes you have a valid network connection to the internet.

apt-get update

A common example is installing Java runtime support for a system. Find the package name first with search, and then install it.

root@ts:~# apt-cache search openjdk
jvm-7-avian-jre - lightweight virtual machine using the OpenJDK class library
freemind - Java Program for creating and viewing Mindmaps
icedtea-7-plugin - web browser plugin based on OpenJDK and IcedTea to execute Java applets
default-jdk - Standard Java or Java compatible Development Kit
default-jdk-doc - Standard Java or Java compatible Development Kit (documentation)
default-jre - Standard Java or Java compatible Runtime
default-jre-headless - Standard Java or Java compatible Runtime (headless)
jtreg - Regression Test Harness for the OpenJDK platform
libreoffice - office productivity suite (metapackage)
icedtea-7-jre-jamvm - Alternative JVM for OpenJDK, using JamVM
openjdk-7-dbg - Java runtime based on OpenJDK (debugging symbols)
openjdk-7-demo - Java runtime based on OpenJDK (demos and examples)
openjdk-7-doc - OpenJDK Development Kit (JDK) documentation
openjdk-7-jdk - OpenJDK Development Kit (JDK)
openjdk-7-jre - OpenJDK Java runtime, using Hotspot Zero
openjdk-7-jre-headless - OpenJDK Java runtime, using Hotspot Zero (headless)
openjdk-7-jre-lib - OpenJDK Java runtime (architecture independent libraries)
openjdk-7-source - OpenJDK Development Kit (JDK) source files
uwsgi-app-integration-plugins - plugins for integration of uWSGI and application
uwsgi-plugin-jvm-openjdk-7 - Java plugin for uWSGI (OpenJDK 7)
uwsgi-plugin-jwsgi-openjdk-7 - JWSGI plugin for uWSGI (OpenJDK 7)

In this case you will want the openjdk-7-jre package. Names of packages are on Debian's wiki or the packages site.

With the package name apt-get install can be used to install the prebuilt packages.

apt-get install openjdk-7-jre
# More than one package can be installed at a time.
apt-get install openjdk-7-jre nano vim mplayer

For more information on using apt-get refer to Debian's documentation here.

4.3 Setting up SSH

To install ssh, install the package as normal with apt-get:

apt-get install openssh-server

Make sure the device is configured on the network, and set a password for your remote user. SSH will not allow remote connections without a password or a shared key.

passwd root

After this setup it is now possible to connect from a remote PC supporting SSH. On Linux/OS X this is the "ssh" command, or from Windows using a client such as putty.

Note: If a DNS server is not present on the target network, it is possible to save time at login by adding "UseDNS no" in /etc/ssh/sshd_config.

4.4 Starting Automatically

A systemd service can be created to start up headless applications. Create a file in /etc/systemd/system/yourapp.service

Description=Run an application on startup

If networking is a dependency add "" in the Unit section. Once you have this file in place add it to startup with:

# Start the app on startup, but will not start it now
systemctl enable yourapp.service
# Start the app now, but doesn't change auto startup
systemctl start yourapp.service
Note: See the systemd documentation for in depth documentation on services.

To start an application on bootup with X11 instead change the x-session-manager. By default the system starts xfce:

root@ts:~# ls -lah /usr/bin/x-session-manager 
lrwxrwxrwx 1 root root 35 May 26  2015 /usr/bin/x-session-manager -> /etc/alternatives/x-session-manager
root@ts:~# ls -lah /etc/alternatives/x-session-manager
lrwxrwxrwx 1 root root 19 May 26  2015 /etc/alternatives/x-session-manager -> /usr/bin/startxfce4

The x-session can be modified to only start specified processes. Create the file /usr/bin/mini-x-session with these contents:

matchbox-window-manager -use_titlebar no &
exec xfce4-terminal

You may need to "apt-get install matchbox-window-manager." first. This is a tiny window manager which also has a few flags that simplify embedded use. Now enable this session manager and restart slim to restart x11 and show it now.

chmod a+x /usr/bin/mini-x-session
rm /etc/alternatives/x-session-manager
ln -s /usr/bin/mini-x-session /etc/alternatives/x-session-manager
service slim restart

If the x-session-manager process ever closes x11 will restart. The exec command allows a new process to take over the existing PID. In the above example xfce4-terminal takes over the PID of x-session-manager. If the terminal is closed with commands like exit the slim/x11 processes will restart.

5 Backup / Restore

5.1 MicroSD Card

MicroSD8GB.png Click to download the latest tarball.

These instructions assume you have an SD card with one partition. Most SD cards ship this way by default. If the card has had its partition table modified this can be corrected with a tool like 'gparted' or 'fdisk'.

Plug the SD card into a USB reader and connect it to a linux workstation PC. Newer distributions include a utility called 'lsblk' which lists all block devices like a USB SD card reader:

 sdY      8:0    0   400G  0 disk 
 ├─sdY1   8:1    0   398G  0 part /
 ├─sdY2   8:2    0     1K  0 part 
 └─sdY5   8:5    0     2G  0 part [SWAP]
 sr0     11:0    1  1024M  0 rom  
 sdX      8:32   1   3.9G  0 disk 
 ├─sdX1   8:33   1   7.9M  0 part 
 ├─sdX2   8:34   1     2M  0 part 
 ├─sdX3   8:35   1     2M  0 part 
 └─sdX4   8:36   1   3.8G  0 part  

In this case the SD card is 4GB, so sdX is the target device. Note that on your system, sdX will not be a real device, it could be sda, sdb, mmcblk0, etc. Technologic Systems is not responsible for any damages cause by using the improper device node for imaging an SD card.

After plugging in the device after Linux has booted you can use dmesg to print out the kernel log. When the USB drive is added it will append to the end of that file. Try running:

dmesg | tail -n 100
 scsi 54:0:0:0: Direct-Access     Generic  Storage Device   0.00 PQ: 0 ANSI: 2
 sd 54:0:0:0: Attached scsi generic sg2 type 0
 sd 54:0:0:0: [sdX] 3862528 512-byte logical blocks: (3.97 GB/3.84 GiB)

In this case, sdXc is shown as a 3.97GB card. Note that on your system, sdX will not be a real device, it could be sda, sdb, mmcblk0, etc. Technologic Systems is not responsible for any damages cause by using the improper device node for imaging an SD card.

The following commands will reformat the first partition of the SD card, and unpack the latest filesystem on there:

# Verify nothing else has this mounted
sudo umount /dev/sdX1
sudo mkfs.ext3 /dev/sdX1
sudo mkdir /mnt/sd
sudo mount /dev/sdX1 /mnt/sd/
sudo tar -xf ts7553-V2-latest.tar.bz2 -C /mnt/sd
sudo umount /mnt/sd
Note: The ext4 filesystem can be used instead of ext3, but it may require additional options. U-Boot does not support the 64bit addressing added as the default behavior in recent revisions of mkfs.ext4. If using e2fsprogs 1.43 or newer, the options "-O ^64bit,^metadata_csum" must be used. Older versions of e2fsprogs do not need these options passed.

Once written, the files on disk can be verified to ensure they are the same as the source files in the archive. Reinsert the disk to flush the block cache completely, then run the following commands:

mount /dev/sdX1 /mnt/sd
cd /mnt/sd/
sudo md5sum --quiet -c md5sums.txt
cd -
umount /mnt/sd

The md5sum command will report what differences there are, if any, and return if it passed or failed.

5.2 eMMC

5.2.1 U-Boot UMS (USB mass storage)

U-Boot on the TS-7553-V2 supports the "ums" command to allow the eMMC device (or SD card, or USB device for that matter) to be accessible directly on a host PC via USB mass storage. This method is generally slower than direct access from linux on the TS-7553-V2 itself, but it allows for direct updating of the flash media.

Note: It is recommended to use a host PC with a native linux install. It has been observed that some VMs fail to correctly pass-through the USB device created on the TS-7553-V2 in U-Boot for UMS.

On the TS-7553-V2, set the U-Boot jumper before applying power. Insert the USB device cable to a host PC and open the serial console. At the U-Boot prompt, run the following command:

run emmc-ums

The USB serial will immediately disconnect, and the USB mass storage device provided by the TS-7553-V2 will begin to enumerate. The following commands can then be used to set up the eMMC, and unpack the latest tarball on to it. Note that the instructions refer to /dev/sdX, please verify the correct device node that is created on the host and adjust the instructions as necessary.

# Verify nothing else has the partition mounted
umount /dev/sdX1
mkfs.ext3 /dev/sdX1
mkdir /mnt/emmc
mount /dev/sdX1 /mnt/emmc
tar -xf ts7553-V2-latest.tar.bz2 -C /mnt/emmc
umount /mnt/emmc
Note: The ext4 filesystem can be used instead of ext3, but it may require additional options. U-Boot does not support the 64bit addressing added as the default behavior in recent revisions of mkfs.ext4. If using e2fsprogs 1.43 or newer, the options "-O ^64bit,^metadata_csum" must be used. Older versions of e2fsprogs do not need these options passed.

Once written, the files on disk can be verified to ensure they are the same as the source files in the archive. To do so, run the following commands:

mount /dev/sdX1 /mnt/emmc
cd /mnt/emmc/
md5sum --quiet -c md5sums.txt
cd -
umount /mnt/emmc

The md5sum command will report what differences there are, if any, and return if it passed or failed.

At this point, the device is unmounted and is sync'ed. The TS-7553-V2 can be turned off at this point. Be sure to disconnect the USB cable as well to ensure the system is fully powered off.

5.2.2 Booted from SD

These commands assume the TS-7553-V2 is booted from the SD card:

# Verify nothing else has the partition mounted
umount /dev/mmcblk1p1
mkfs.ext3 /dev/mmcblk1p1
mount /dev/mmcblk1p1 /mnt/emmc
tar -xf ts7553-V2-latest.tar.bz2 -C /mnt/emmc
umount /mnt/emmc
Note: The ext4 filesystem can be used instead of ext3, but it may require additional options. U-Boot does not support the 64bit addressing added as the default behavior in recent revisions of mkfs.ext4. If using e2fsprogs 1.43 or newer, the options "-O ^64bit,^metadata_csum" must be used. Older versions of e2fsprogs do not need these options passed.

Once written, the files on disk can be verified to ensure they are the same as the source files in the archive. To do so, run the following commands:

mount /dev/mmcblk1p1 /mnt/emmc
cd /mnt/emmc/
md5sum --quiet -c md5sums.txt
cd -
umount /mnt/emmc

The md5sum command will report what differences there are, if any, and return if it passed or failed.

6 Software Development

Most of our examples are going to be in C, but Debian will include support for many more programming languages. Including (but not limited to) C++, PERL, PHP, SH, Java, BASIC, TCL, and Python. Most of the functionality from our software examples can be done from using system calls to run our userspace utilities. For higher performance, you will need to either use C/C++ or find functionally equivalent ways to perform the same actions as our examples. Our userspace applications are all designed to go through a TCP interface. By looking at the source for these applications, you can learn our protocol for communicating with the hardware interfaces in any language.

The most common method of development is directly on the SBC. Since debian has space available on the SD card, we include the build-essentials package which comes with everything you need to do C/C++ development on the board.


Vim is a very common editor to use in Linux. While it isn't the most intuitive at a first glance, you can run 'vimtutor' to get a ~30 minute instruction on how to use this editor. Once you get past the initial learning curve it can make you very productive. You can find the vim documentation here.

Emacs is another very common editor. Similar to vim, it is difficult to learn but rewarding in productivity. You can find documentation on emacs here.

Nano while not as commonly used for development is the easiest. It doesn't have as many features to assist in code development, but is much simpler to begin using right away. If you've used 'edit' on Windows/DOS, this will be very familiar. You can find nano documentation here.


We only recommend the gnu compiler collection. There are many other commercial compilers which can also be used, but will not be supported by us. You can install gcc on most boards in Debian by simply running 'apt-get update && apt-get install build-essential'. This will include everything needed for standard development in c/c++.

You can find the gcc documentation here. You can find a simple hello world tutorial for c++ with gcc here.

Build tools

When developing your application typing out the compiler commands with all of your arguments would take forever. The most common way to handle these build systems is using a make file. This lets you define your project sources, libraries, linking, and desired targets. You can read more about makefiles here.

If you are building an application intended to be more portable than on this one system, you can also look into the automake tools which are intended to help make that easier. You can find an introduction to the autotools here.

Cmake is another alternative which generates a makefile. This is generally simpler than using automake, but is not as mature as the automake tools. You can find a tutorial here.


Linux has a few tools which are very helpful for debugging code. The first of which is gdb (part of the gnu compiler collection). This lets you run your code with breakpoints, get backgraces, step forward or backward, and pick apart memory while your application executes. You can find documentation on gdb here.

Strace will allow you to watch how your application interacts with the running kernel which can be useful for diagnostics. You can find the manual page here.

Ltrace will do the same thing with any generic library. You can find the manual page here.

6.1 Cross Compiling

Debian Jessie provides cross compilers from its distribution. An install on a workstation can build for the same release on other architectures. A PC, virtual machine, or chroot will need to be used for this. Install Debian Jessie for your workstation here.

From a Debian workstation (not the target), run these commands to set up the cross compiler:

# Run "lsb_release -a" and verify Debian 8.X is returned.  These instructions are not
# expected to work on any other version or distribution.
apt-get install curl build-essential
su root
echo "deb jessie main" > /etc/apt/sources.list.d/emdebian.list
curl | apt-key add -
# Note that while Ubuntu uses apt as well, Ubuntu host setup is slightly different, instead of the above commands use the following:
# echo "deb [arch=armhf] trusty main restricted universe multiverse" >> /etc/apt/sources.list
# echo "deb [arch=armhf] trusty-updates main restricted universe multiverse" >> /etc/apt/sources.list
# echo "deb [arch=armhf] trusty-security main restricted universe multiverse" >> /etc/apt/sources.list
dpkg --add-architecture armhf
apt-get update
apt-get install crossbuild-essential-armhf

This will install a toolchain that can be used with the prefix "arm-linux-gnueabihf-". The standard GCC tools will start with that name, eg "arm-linux-gnueabihf-gcc".

The toolchain can now compile a simple hello world application. Create hello-world.c on the Debian workstation:

#include <stdio.h>
int main(){
    printf("Hello World\n");

To compile this:

arm-linux-gnueabihf-gcc hello-world.c -o hello-world
file hello-world

This will return that the binary created is for ARM. Copy this to the target platform to run it there.

Debian Jessie supports multiarch which can install packages designed for other architectures. On workstations this is how 32-bit and 64-bit support is provided. This can also be used to install armhf packages on an x86 based workstation.

This cross compile environment can link to a shared library from the Debian root. The package would be installed in Debian on the workstation to provide headers and .so. This is included in most "-dev" packages. When run on the arm target it will also need a copy of the library installed, but it does not need the -dev package.

apt-get install libcurl4-openssl-dev:armhf
# Download the simple.c example from curl:
# After installing the supporting library, curl will link as compiling on the unit.
arm-linux-gnueabihf-gcc simple.c -o simple -lcurl

Copy the binary to the target platform and run on the target. This can be accomplished with network protocols like NFS, SCP, FTP, etc.

If any created binaries do not rely on hardware support like GPIO or CAN, they can be run using qemu.

# using the hello world example from before:
# Returns Exec format error
apt-get install qemu-user-static

6.2 Compile the Kernel

For adding new support to the kernel, or recompiling with more specific options you will need to have a compatible Linux workstation available that can handle the cross compiling. Compiling the kernel on the device is not supported or recommended.


A cross compiler is necessary, for recent Debian distributions, please follow the Cross Compiling instructions to install a compatible cross compiler.

For other distributions, please refer to their documentation to find equivalent tools.

Download sources and configure

git clone
cd linux-tsimx
git checkout ts-imx_4.1.15_2.0.0_ga
# These next commands set up some necessary environment variables
export ARCH=arm
export CROSS_COMPILE=arm-linux-gnueabihf-
export LOADADDR=0x80800000
# This sets up the default configuration that we ship with
make tsimx6ul_defconfig

Once you have the configuration ready you can make your changes to the kernel. Commonly a reason for recompiling is to add support that was not built into the standard image's kernel. You can get a menu to browse available options by running:

make menuconfig

You can use the "/" key to search for specific terms through the kernel.

Build the kernel

Once you have it configured you can begin building the kernel. This usually takes about 5-10 minutes. This group of commands will also output a uImage file used by U-Boot on the TS-7680.

make && make zImage && make modules

We recommend running 'make' with the -jX argument, where X is the number of CPU cores+1 present on the build machine. This will greatly increase build speed.

Install the kernel/initramfs, headers, and modules

Next you need to install the kernel and modules to the SD card. Use the following to update the kernel, headers, and modules, this assumes the SD card connected to the workstation is assigned the device node /dev/sdc, please adjust the first command based on your specific setup:

export DEV=/dev/sdc1
sudo mkdir /mnt/sd
sudo mount "$DEV" /mnt/sd
sudo cp arch/arm/boot/zImage  /mnt/sd/boot/
sudo cp arch/arm/boot/dts/imx6*ts*.dtb /mnt/sd/boot/
INSTALL_MOD_PATH="/mnt/sd" sudo -E make modules_install 
INSTALL_HDR_PATH="/mnt/sd" sudo -E make headers_install
sudo umount /mnt/sd/

7 Features

7.1 Battery Backed RTC

The TS-7553-V2 implements a M41T00S STMicro Battery Backed RTC using an external and replaceable coin cell battery. This RTC is connected to the CPU via I2C and is handled by the kernel and is presented as a standard RTC device in linux.

7.2 Bluetooth

The Wi-Fi option for the unit also includes a bluetooth 4.0 LE module. Both Wi-Fi and Bluetooth can be active at the same time. However, in order for bluetooth to function the Wi-Fi device must first be brought up to load the necessary firmware. After the WiFi is active, the Bluetooth module can be activated with the following commands:

hciattach /dev/ttymxc2 any 115200 noflow
hciconfig hci0 up
hcitool cmd 0x3F 0x0053 00 10 0E 00 01
stty -F /dev/ttymxc2 921600 crtscts

The Bluetooth module is now set up, and is running at 921600 baud with full flow control. At this point, the device is fully set up and can be controlled with various components of bluez-tools. For example, to do a scan of nearby devices:

hcitool scan

This will return a list of devices such as:

	14:74:11:XX:XX:XX	BlackBerry 8530

Bluez has support for many different profiles for HID, A2DP, and many more. Refer to the Bluez documentation for more information.

Please note that the Bluetooth module requires the modem control lines CTS and RTS as flow control.

7.3 CAN

Note: The TS-7553-V2 Rev. B PCB does not have software control of the CAN_EN# pin for the transceivers and they are always enabled. This will be addressed in the next hardware revision.

The i.MX6UL CPU has two FlexCAN ports that use the linux SocketCAN implementation. The ports can be set up and used with the following commands:

ip link set can0 up type can bitrate 1000000
ip link set can1 up type can bitrate 1000000

At this point the ports can be used with standard SocketCAN libraries. In debian we provide cansend and candump to test the ports or as a simple packet send/recv tool. In order to test the two ports together, tie CAN_H of both CAN ports together, and do the same for CAN_L. Then use the following commands:

candump can0 &
cansend can1 7Df#03010c
#This command will return
  can0  7DF  [3] 03010c

The above example packet is designed to work with the Ozen Elektronik myOByDic 1610 ECU simulator to read the RPM speed. In this case, the ECU simulator would return data from candump with:

 <0x7e8> [8] 04 41 0c 60 40 00 00 00 
 <0x7e9> [8] 04 41 0c 60 40 00 00 00 

In the output above, columns 6 and 7 are the current RPM value. This shows a simple way to prove out the communication before moving to another language.

The following example sends the same packet and parses the same response in C:

#include <stdio.h>
#include <pthread.h>
#include <net/if.h>
#include <string.h>
#include <unistd.h>
#include <net/if.h>
#include <sys/ioctl.h>
#include <assert.h>
#include <linux/can.h>
#include <linux/can/raw.h>
int main(void)
	int s;
	int nbytes;
	struct sockaddr_can addr;
	struct can_frame frame;
	struct ifreq ifr;
	struct iovec iov;
	struct msghdr msg;
	char ctrlmsg[CMSG_SPACE(sizeof(struct timeval)) + CMSG_SPACE(sizeof(__u32))];
	char *ifname = "can0";
	if((s = socket(PF_CAN, SOCK_RAW, CAN_RAW)) < 0) {
		perror("Error while opening socket");
		return -1;
	strcpy(ifr.ifr_name, ifname);
	ioctl(s, SIOCGIFINDEX, &ifr);
	addr.can_family  = AF_CAN;
	addr.can_ifindex = ifr.ifr_ifindex;
	if(bind(s, (struct sockaddr *)&addr, sizeof(addr)) < 0) {
		return -2;
 	/* For the ozen myOByDic 1610 this requests the RPM guage */
	frame.can_id  = 0x7df;
	frame.can_dlc = 3;[0] = 3;[1] = 1;[2] = 0x0c;
	nbytes = write(s, &frame, sizeof(struct can_frame));
	if(nbytes < 0) {
		return -3;
	iov.iov_base = &frame;
	msg.msg_name = &addr;
	msg.msg_iov = &iov;
	msg.msg_iovlen = 1;
	msg.msg_control = &ctrlmsg;
	iov.iov_len = sizeof(frame);
	msg.msg_namelen = sizeof(struct sockaddr_can);
	msg.msg_controllen = sizeof(ctrlmsg);  
	msg.msg_flags = 0;
	do {
		nbytes = recvmsg(s, &msg, 0);
		if (nbytes < 0) {
			return -4;
		if (nbytes < (int)sizeof(struct can_frame)) {
			fprintf(stderr, "read: incomplete CAN frame\n");
	} while(nbytes == 0);
	if([0] == 0x4)
		printf("RPM at %d of 255\n",[3]);
	return 0;

See the Kernel's CAN documentation here. Other languages have bindings to access CAN such as Python using C-types, Java using JNI.

7.4 CPU

This device features the i.MX6UL 528MHz or 696MHz Cortex-A7 from NXP. For more information about the processor and it's included peripherals, refer to the CPU manual.

7.5 DIO

The TS-7553-V2 offers DIO and a single Relay. The DIO exposed to various headers and terminals are controlled via the CPU. All DIOs are controlled via the kernel sysfs interface. See the kernel's documentation for more detail. All DIO are 3.3 V tolerant unless otherwise noted. All DIO pins have a pullup resistor to 3.3 V.

To interact with DIO pins through the sysfs interface, it first must be exported to userspace, for example, DIO 136 is the En. Relay pin:

echo "136" > /sys/class/gpio/export

If you receive a permission denied on a pin, that means it is claimed by another kernel driver. If the command is successful, there will be a /sys/class/gpio/gpio136/ directory. The relevant files in this directory are:

 direction - "out" or "in"
 value - write "1" or "0", or read "1" or "0" if direction is in
 edge - write with "rising", "falling", or "none"
# Set GPIO 136 high
echo "out" > /sys/class/gpio/gpio136/direction
echo "1" > /sys/class/gpio/gpio136/value
# Set GPIO 136 low
echo "0" > /sys/class/gpio/gpio136/value
# Read the value of GPIO 82, the Push Switch
echo "82" > /sys/class/gpio/export
echo "in" > /sys/class/gpio/gpio82/direction
cat /sys/class/gpio/gpio82/value
DIO Function Location
18 UART5 CTS CN9_8
19 UART5 RTS CN9_7
23 RS-232 Shutdown# N/A
40 XBee DTR CN5_9
41 XBee RTS CN5_16
46 XBee CTS CN5_12
82 Input Push Switch
84 XBee Reset# CN5_5
117 [1] Keypad 0 HD4_2
118 [1] Keypad 1 HD4_3
119 [1] Keypad 2 HD4_4
120 [1] Keypad 3 HD4_5
136 En. Relay N/A
  1. 1.0 1.1 1.2 1.3 Note that using this pin as standard DIO requires unloading the modules used by the Keypad.

As an output, the value file can be written to 0 for low (GND), or 1 for high (3.3V). As an input the GPIO pins have internal pullups. It is also possible to use any processor GPIO as an interrupt by writing the edge file, and then using select() or poll() on the value file for changes. Note that when the DIO is set as an output, the value file will always read back 0, regardless of actual output state.

7.5.1 Special DIO

The linux GPIO subsystem has a few shortcomings, specifically, inability to set default output state from the kernel device-tree. Because of this, a number of DIO are implemented as LEDs in the kernel; pins that control various power supplies. While there is also a regulator subsystem that these could be used with, the regulator controls have their own issues as well. The LED subsystem is a very straightforward way to control IO pins in a similar manner to linux GPIO.

To enable a particular output, write a 1 to the brightness file for one of these special DIO. For example, to enable 4 V on the CN5 XBee Socket header:

echo 1 > /sys/class/leds/en-modem-5v/brightness

To disable any of the outputs, write a 0 to the brightness file. For example, to disable power to the USB host port:

echo 0 > /sys/class/leds/en-usb-5v/brightness

DIO Function Location
en-modem-5v[1] Enable 4 V to CN5 XBee Socket CN9_1
en-usb-5v Enable 5 V to USB host Internal and external USB host
en-xbee-3v3[1] Enable 3.3 V to CN5 XBee Socket CN9_1
  1. 1.0 1.1 Only one of these can be enabled at any time. If en-xbee-3v3 is enabled, en-modem-5v will be disabled in hardware to prevent damage.

7.6 eMMC Interface

The i.MX6UL SD card controller supports the MMC specification, the TS-7553-V2 includes a soldered down eMMC IC to provide on-board flash media.

Our default software image contains 2 partitions:

Device Contents
/dev/mmcblk1 eMMC block device
/dev/mmcblk1boot0 eMMC boot partition
/dev/mmcblk1boot1 eMMC boot partition
/dev/mmcblk1p1 Full Debian linux partition

This platform includes a Micron eMMC module with builds that have "4096F" in the part number. Our off the shelf builds are 4GiB, but up to 64GiB are available for larger builds. The eMMC flash appears to Linux as an SD card at /dev/mmcblk1. Our default programming of the eMMC is the same as the SD card image for standard partitions, but includes additional boot partitions that are used by U-Boot and are not affected by the eMMC partition table.

The eMMC module has a similar concern by default to SD cards in that they should not be powered down during a write/erase cycle. However, this eMMC module includes support for setting a fuse for a "Write Reliability" mode, and a "psuedo SLC (pSLC)" mode. With both of these enabled then any writes will be atomic to 512B. If a sector is being written during a power loss, a block is guaranteed to have either the old or new data. Even in cases where the wrong data is present on the next boot, fsck is able to deal with the older data being present in a 512B block. The downsides to setting these modes are that it will reduce the overall write speed and halve the available space on the eMMC to roughly 1.759GiB.

The mmc-utils package is used to enable these modes.

WARNING: The Rev. B TS-7553-V2 is NOT COMPATIBLE with the following instructions at this time. Running them can brick the device. Please contact customer support with any questions about this matter.

WARNING: If you are using a custom configurated device with an eMMC sized larger than 4GB, contact us before using these commands. The numbers below will change with different flash sizes.
mmc write_reliability set -n 0 /dev/mmcblk2
mmc enh_area set -y 0 1847296 /dev/mmcblk2
WARNING: Setting either of those modes is permanent and using the wrong value it is possible to essentially brick eMMC which will not be covered by the warranty. Evaluation units with fuses set will not be accepted through returns.

After this is run, reboot the unit. On all future boots the eMMC will be detected at the smaller size.

7.7 Ethernet Port

The NXP processor implements a 10/100 ethernet controller with support built into the Linux kernel. Standard Linux utilities such as ifconfig/ip can be used to control this interface. See the Configuring the Network section for more details. For the specifics of this interface see the CPU manual.

7.8 External Reset

Note: This section is incomplete at this time.

Note: Use caution when using the push switch as a hardware reset mechanism. Filesystem corruption can occur if proper precautions are not taken and a hardware reset occurs.

This SBC has a multi-purpose tactile button at a right angle to the PCB. This button can be used as a mechanism to issue a hardware reset to the SBC or as a way to wake up the device from its sleep modes (see Sleep for more information). Additionally, it can be set up as a generic input for user applications.

To enable or disable the hardware reset functionality:

tsmicroctl --resetswitchon  #Enable hardware reset
tsmicroctl --resetswitchoff #Disable hardware reset

To read the state of the input pin, see the DIO section for information on reading the Push Switch.

7.9 FRAM

The unit supports an optional non-volatile Ferroelectric RAM (FRAM) device. The Cypress FM25L16B is a 2kbyte device, in a configuration not unlike an SPI EEPROM. However, the nature of FRAM means it is non-voltile, incredibly fast to write, and is specified with a 100 trillion read/write cycles, with a 150 year data retention. The device is connected to linux, and presents itself as a flat file that can be read and written like any standard linux file.

The EEPROM file can be found at /sys/class/spi_master/spi2/spi2.2/eeprom

7.10 I2C

The i.MX6UL CPU has two I2C peripherals, one of which is exposed on a pin header, HD1.

This interface is accessible via the linux i2c-dev subsystem, it is available on the device node /dev/i2c-2. See the kernel i2c-dev documentation for more information on using the I2C peripheral.

7.11 Jumpers

The TS-7553-V2 has a set of jumpers located near the SuperCaps on the edge of the SBC. These jumpers control a number of aspects of the TS-7553-V2's behavior. The jumpers are labeled on the silkscreen rather than numbered:

Label Description
NO Charge When jumper is set, disable charging of the SuperCaps. Beneficial for early development and testing.
SD Boot When jumper is set, boot kernel and Debian from the SD card. Otherwise boot kernel and Debian from eMMC. This jumper influences U-Boot behavior.
U Boot When jumper is set, pause booting in U-Boot and drop to a U-Boot shell. Otherwise boot straight to Debian.
CAN When jumper is set, adds a 120 ohm termination resistor across CAN1 H and L pins. (Note: the CAN2 interface always has a 120 ohm termination)
485 When jumper is set, adds a 120 ohm termination resistor across RS-485 + and - pins.

7.12 LCD + Keypad

The TS-7553-V2 supports an optional 128x64 px. monochrome LCD and 4 membrane switches all mounted in an enclosure. The LCD has an SPI interface, and through the use of libraries like Cairo complex graphics can be rendered. The keypad is a simple 4 button keypad that is attached to the system with a driver that behaves like a keyboard input. There are helper binaries as well as tests/demos for the LCD and keypad functionality. These can be found in the TS-7553-V2 Utilities github

7.12.1 LCD

In order for the LCD to run, there is a module that must first be loaded, ts-st7565p-fb. On the TS-7553-V2, this module is auto-loaded by systemd, it's specified in /etc/modules-load.d/lcd_keypad.conf

The 128x64 px. monochrome LCD is connected to the system via SPI and uses a userspace application to format the data, and a driver to send it to the device. The LCD can be used as a generic framebuffer with this setup. The userspace application and driver are included by default, but must be manually run to set up.


Note that its possible with systemd to set this up to auto run on startup, followed by the application that would utilize the screen. This application should start up after all of the necessary modules have been loaded.

Two example binaries are also included in order to demonstrate the LCD's capabilities.


Is a simple Cairo demonstration that draws a box, a line, a circle, and some text on to the display.


Will display a bouncing box on the screen.

See the sources for more information on these demos and how they operate.

7.12.2 Keypad

In order for the membrane switches to run properly, there are two modules that must be loaded, gpio_keys, and matrix_keymap. On the TS-7553-V2, these modules are auto-loaded by systemd, these are specified in /etc/modules-load.d/lcd_keypad.conf

The 4 button membrane keypad allows for a 4 button input. These are set up on GPIO pins, and are connected to the system as a standard input event device. The four keys are connected as arrow keys. An example binary is included in order to demonstrate the input capabilities of these buttons:


Will draw a box around the screen, with some text. But, whenever a button is pressed it will display a block on the LCD above the button that has been pressed. Please note that the LCD device must first be set up and operational before this binary will launch.

See the sources for more information on this demos and how it operates.

7.13 LEDs

On all of our SBCs we include 2 indicator LEDs which are under software control. You can manipulate these using "tshwctl --greenledon --redledon" or "tshwctl --greenledoff --redledoff". The LEDs have 4 behaviors from default software.

Green Behavior Red behavior Meaning
Solid On Off System is booted and running
Solid On On for approximately 20s, then off The red LED will remain on from power on until Debian has finished booting. The first boot of the unit will have the LED on longer as part of this process is generating SSH keys for the unit.
On for 10s, off for 100ms, and repeating On for 10s, off for 100ms, and repeating The watchdog is continuously resetting the board. This happens when the system cannot find a valid boot device, or the watchdog is otherwise not being fed. This is normally fed by the kernel once a valid boot media has started. See the #Watchdog section for more details.
Off Off The SBC is not able to boot. Typically either the board is not being supplied with enough voltage, or the SBC has been otherwise damaged. If a stable voltage is being provided and the supply is capable of providing at least 1A to the SBC, an RMA is suggested.
Blinking about 5ms on, about 10ms off. Blinking about 5ms on, about 10ms off. The board is receiving too little power, or something is drawing too much current from the unit's power rails.

The red and green LEDs can be controlled from userspace after bootup using the linux LED subsystem. For example, to turn on the red LED:

echo 1 > /sys/class/leds/red-led/brightness

A number of triggers are also available, including timers, disk activity, and heartbeat. See the kernel LED documentation for more information on triggers and general use of LED class devices

7.14 MicroSD Card Interface

The i.MX6ul SD card controller is used for the SD card present on the board which supports the SD and SDHC specifications. This controller has been tested with Sandisk Extreme SD cards which allow read speeds up to 20.5MB/s, and write speeds up to 21.5MB/s.

Our default software image contains a single partition:

Device Contents
/dev/mmcblk0 SD Card block device
/dev/mmcblk0p1 Full Debian linux partition

7.15 Reboot Source

The supervisory microcontroller is capable of saving and displaying the reason for the most recent reboot. This can be used to detect various errors that may occur in the field, as well as simple accounting of events. The source can be queried with tsmicroctl:

tsmicroctl -i

Possible sources and causes are:

Source Possible causes
poweron Power removed, Super Caps discharged, and then power applied
brownout Like "poweron," however the SuperCaps have not fully discharged
WDT WDT timeout; reboot command (which reboots via WDT)
resetswitch The reset switch has been enabled and has been asserted
sleep The system has woken up from a sleep command

7.16 Relay

The TS-7553-V2 has one SPDT relay rated for 5 A at 277 VAC or 30 VDC that can be toggled through a DIO pin. The PCH-105D2H relay closes in 10ms, and opens in 5ms. A very safe assumption would be that it will switch after 20ms. The common, NO (Normally Open), and NC (Normally Closed) connections are brought out on a pin header. See the DIO section of the manual for information on manipulating the relays.

Contact Location
COM P1_7
NO P1_8
NC P1_6

7.17 Sleep

Note: This section is incomplete at this time.
Note: As soon as the sleep command is issued the unit will go to sleep. If the proper precautions are not taken, filesystem corruption can result as the sleep mode removes all power from the CPU and other peripherals on the SBC

The addition of a microcontroller on board this SBC allows it to play a supervisory role over the CPU.

Low power sleep mode will remove power from all of the rails, turning off the CPU and every other peripheral save for the microcontroller. This mode offers extreme power savings, only requiring around 90 mW of power, with the ability to wake up after an arbitrary timeout (up to 1847297s, which is 21d 9h 8m 17s) with a 1s resolution. In order to enter this mode, issue the following command:

tsmicroctl --sleep --timewkup <time in seconds> --resetswitchwkup

Waking up from a sleep will take roughly 4-5s from when the timer expires or when the reset button is pressed. This is normal bootup time for the CPU.

Note that both --timewkup and --resetswitchwkup are optional arguments, you can pass none, one, or both. If no arguments are passed then the SBC will remain in sleep mode forever, until power is removed completely and re-applied. This can be useful instead of halting in linux as sleeping would consume far less power than simply halting the CPU. Be aware however, that if the Super Caps are installed they will keep power to the on-board microcontroller for a very long time. If the Super Caps are used than an external wakeup via timer or reset switch is highly recommended.

7.18 SPI

The i.MX6UL CPU has a native SPI peripheral that is used in a number of places on the TS-7553-V2. Additionally, kernel spidev support is added to allow SPI access from userspace. User SPI can be used for LCD access, a generic SPI connection on HD1, as well as user accessible FRAM.

The ECSPI peripheral in the i.MX6UL CPU is highly flexible and can even support SPI slave mode. For more information on the peripheral itself, please see the CPU reference manual.

The SPI peripheral is accessible as /dev/spidev2.x, where x is one of the three chip select lines. Additional chip select lines can be implemented if needed by adding them to the kernel device-tree by using GPIO.

CS Device
1 HD1

See the kernel spidev documentation for more information on interfacing with the SPI peripherals.

7.19 SuperCaps

Note: This section is incomplete at this time.

The TS-7553-V2 has an option to add two 2.7 V 10 F supercapacitors. These two SuperCaps can provide up to 20 seconds of power hold time automatically if the external power input is removed. The Power Fail input signal (see the DIO Section) can be used to determine if the exterior power has been removed or fallen below a valid input level. Using this signal, a proper shutdown can be issued to ensure that all data is flushed from cache to disk, and all disks are unmounted properly.

The SuperCaps charge and discharge is managed transparently by the supervisory microcontroller. A jumper is provided to disable the charging and use of the SuperCaps. This mode is very useful for development to allow for proper power-off conditions without having to wait for the SuperCaps to discharge. The supervisory microcontroller will also not allow the TS-7553-V2 to boot if power input is invalid. If the system reboots safely due to a power failure, it will remain in a powered off state until external power is re-applied, or the SuperCaps discharge below the sustainable threshold.

By default, a script is started with systemd to monitor the Power Fail pin, and present all logged in users with a message saying that the power has failed and a graceful shutdown is taking place if the power input has failed. This script is located at /usr/local/bin/tssilomon

Additionally, U-Boot can delay booting until the SuperCaps are charged to a certain percentage, and optionally print the current percentage once per second. These are controlled with the environment variables "chrg_pct" and "chrg_verb" By setting chrg_pct to anything other than 0 (0 means do not wait, which is the default behavior), booting will be delayed until that percentage is reached. Setting chrg_verb to 1 will enable the verbose printing of the current percentage every second. Note that the SuperCaps may be at "0%" for a large period of time, this is due to the charge level being below a voltage that can sustain the TS-7553-V2. See the U-Boot section for information on setting environment variables.

A recommended value is 100%. This value was chosen because it can ensure the system is powered long enough to boot up and safely shut down (and provide an additional 8 s of power) if power is immediately cut once booting has started. Please note that this only applies to the default stock image, any further changes to the TS-7553-V2 hardware or software, such as connecting powered devices like USB or adding additional applications may cause the recommended value to not sustain the TS-7553-V2 until a safe shutdown is completed. The time it takes to reach 100% charge will vary depending on the current charge of the SuperCaps. On average, it will take about 20 seconds to charge the SuperCaps to 100%; this is assuming the SuperCaps have very recently fallen below the threshold voltage to sustain the TS-7553-V2.

7.20 Temperature Sensor

Note: Pending software example

7.21 UARTs

The TS-7553-V2 CPU offers 8 UARTs. The table below lists the CPU UARTs with their pin locations.

Num. Dev. Name Type TX / + Loc. RX / - Loc. RTS Loc. CTS Loc.
0 ttymxc0 USB Console N/A N/A N/A N/A
1 ttymxc1 RS-485 CN9_1 / P1_3 CN9_6 / P1_4 N/A N/A
2 ttymxc2 Bluetooth N/A N/A N/A N/A
3 ttymxc3 RS-232[1] HD2_3 HD2_2 N/A N/A
4 ttymxc4 RS-232[1] HD2_7 HD2_8 N/A N/A
5 ttymxc5 RS-232[1] CN9_3 CN9_2 CN9_7[2] CN9_8[2]
6 ttymxc6 TTL HD1_12 HD1_10[3] N/A N/A
7 ttymxc7 XBee/TTL CN5_3 CN5_2 N/A N/A
  1. 1.0 1.1 1.2 RS-232 transceiver can be shut down to reduce power. See the DIO section.
  2. 2.0 2.1 Signal implemented as GPIO.
  3. 5 V tolerant input

7.21.1 RS-485

Note: As of all kernels built after May 11, 2017, TXEN is automatically enabled and this code snippet is no longer needed to enable it.

The TS-7553-V2 has a single RS-485 port that supports automatic TXEN via kernel driver features and a GPIO pin. The RS-485 kernel support allows for tuning of timing, as well as polarity of the TXEN signal. For full information on using this feature, see the RS-485 kernel documentation. See the UARTs section for the location of the RS-485 port.

Simple sample code to implement the auto-TXEN on the RS-485 port:

#include <linux/serial.h>
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
/* Driver-specific ioctl: */
#define TIOCSRS485      0x542F
struct serial_rs485 rs485conf;
int main(void)
        int fd = open ("/dev/ttymxc1", O_RDWR);
        if (fd < 0) {
                /* Error handling. See errno. */
        /* Enable RS485 mode: */
        rs485conf.flags |= SER_RS485_ENABLED;
        /* Set logical level for RTS pin equal to 1 when sending: */
        rs485conf.flags |= SER_RS485_RTS_ON_SEND;
        /*Set logical level for RTS pin equal to 0 after sending: */
        rs485conf.flags &= ~(SER_RS485_RTS_AFTER_SEND);
        if (ioctl (fd, TIOCSRS485, &rs485conf) < 0) {
                /* Error handling. See errno. */
        /* Use read() and write() syscalls here... */
        write(fd, "The quick brown fox jumps over the lazy dog.\r\n", 46);
        /* Close the device when finished: */
        if (close (fd) < 0) {
                /* Error handling. See errno. */

7.22 USB

The TS-7553-V2 offers multiple USB 2.0 host ports as well as OTG compatible ports. An on-board USB hub breaks out the host ports to multiple places, allowing the use of various devices. There is a single external USB A port, and a single internal USB A port. The internal port is provided by a USB A jack that is mounted in such a way to lay the connected USB dongle over the PCB, allowing most dongles to be contained within the TS-7553-V2 enclosure without issue.

The TS-7553-V2 has a single exposed USB B female device socket. By default, this USB device is the USB serial interface as provided by the supervisory microcontroller; however it is possible to route this USB interface to the CPU USB OTG port and enable USB gadget usage.

Power to the USB host can be controlled with the LED subsystem under the LED device: /sys/class/leds/en-usb-5v/ By writing to the "brightness" file in that folder a value greater than 0, it will enable USB power, setting it to 0 will turn it off.

Using the LED subsystem may seem odd, however the linux GPIO subsystem does not provide a mechanism to supply a default state of the IO pin while the LED subsystem does. See the LED section of the manual for more information on controlling the power pin as an LED.

7.22.1 USB Gadget

The USB B female jack by default provides a USB serial console, however once the linux kernel is booted it is possible to switch the jack to connect to the CPU USB OTG port and load standard linux USB gadget drivers. Below is an example to set up the USB ethernet gadget.

First, load the gadget drivers and bring the interface up:

modprobe g_ether
ifconfig usb0 up

Next, switch the USB mux so that the USB device port now connects to the CPU OTG port. Note that when this command is run, USB serial will immediately disconnect:

echo 71 > /sys/class/gpio/export
echo high > /sys/class/gpio/gpio71/direction

At this point the TS-7553-V2 will appear to the host system as a USB ethernet device, the TS-7553-V2 will have an IP of on the USB interface. The host PC can set an IP address in this same subnet and will be able to communicate with the TS-7553-V2. See the linux USB gadget documentation for more information on the full set of devices that are available.

7.23 Watchdog

The TS-7553-V2 implements a WDT inside the CPU. A standard kernel WDT driver is in place. As soon as the kernel starts it will start the WDT and feed it on 60 second timeouts every 30 seconds. If a userspace application opens and uses the watchdog file, the kernel will stop auto-feeding and the user application is now responsible for feeding the WDT. The kernel driver supports the "Magic Close" feature of the WDT. This means that a 'V' character must be fed in to the watchdog file before the file is closed in order to disable the WDT. Additionally, if the kernel is compiled with CONFIG_WATCHDOG_NOWAYOUT then the WDT can never be stopped once it is started at boot.

See the Linux WDT API documentation for more information.

8 External Interfaces

8.1 HD1 Pin Header

Pin Name
HD1_2 POE_78
HD1_4 POE_45
HD1_7 SPI_CS# 1
HD1_10 UART6 RXD [1]
HD1_11 USB Host -
HD1_13 USB Host +
HD1_14 I2C_CLK
HD1_15 5 V
HD1_16 5 V
HD1_19 3.3 V
Pin Layout
1 2
3 4
5 6
7 8
9 10
11 12
13 14
15 16
17 18
19 20
  1. 5V tolerant input

8.2 HD2 COM2 Header

10pin com header.png

Pin Name
HD2_1 UART1 RS-485 +
HD2_4 CAN1_H
HD2_6 UART1 RS-485 -
HD2_9 CAN1_L
HD2_10 NC

8.3 HD4 Keypad Interface

Pin Name
HD4_2 Keypad 0 / DIO 117 [1]
HD4_3 Keypad 1 / DIO 118 [1]
HD4_4 Keypad 2 / DIO 119 [1]
HD4_5 Keypad 3 / DIO 120 [1]
  1. 1.0 1.1 1.2 1.3 Note that using this pin as standard DIO requires unloading the modules used by the Keypad.

8.4 CN5 XBee Socket


Pin Name
CN5_1 VCC [1]
CN5_5 XBee reset# / DIO 84
CN5_6 5 V [2]
CN5_7 USB Host +
CN5_8 USB Host -
CN5_9 DIO 40
CN5_10 GND
CN5_11 GND
CN5_12 DIO 46
CN5_13 NC
CN5_14 3.3 V
CN5_15 GND
CN5_16 DIO 41
CN5_17 NC
CN5_18 NC
CN5_19 NC
CN5_20 GND
  1. This pin will provide 3.3 V or 4 V depending on if "XBee 3.3 V" or "MODEM 5 V" is enabled. See the DIO section for more information.
  2. Enabled with "MODEM 5 V". See the DIO section for more information.

8.5 P1 Pin Header

Pin Name
1 Power-in VCC
2 Power-in VSS
3 UART1 RS-485 +
4 UART1 RS-485 -
6 Relay NC
7 Relay COM
8 Relay NO

8.6 CN9 DB-9 Header


Pin Name
1 UART1 RS-485 +
4 CAN0_H
6 UART1 RS-485 -
9 CAN0_L
10 GND

9 Revisions and Changes

9.1 Microcontroller Changelog

9.2 PCB Revisions

Revision Changes
B Initial release

9.3 Software Images

10 Product Notes

10.1 FCC Advisory

This equipment generates, uses, and can radiate radio frequency energy and if not installed and used properly (that is, in strict accordance with the manufacturer's instructions), may cause interference to radio and television reception. It has been type tested and found to comply with the limits for a Class A digital device in accordance with the specifications in Part 15 of FCC Rules, which are designed to provide reasonable protection against such interference when operated in a commercial environment. Operation of this equipment in a residential area is likely to cause interference, in which case the owner will be required to correct the interference at his own expense.

If this equipment does cause interference, which can be determined by turning the unit on and off, the user is encouraged to try the following measures to correct the interference:

Reorient the receiving antenna. Relocate the unit with respect to the receiver. Plug the unit into a different outlet so that the unit and receiver are on different branch circuits. Ensure that mounting screws and connector attachment screws are tightly secured. Ensure that good quality, shielded, and grounded cables are used for all data communications. If necessary, the user should consult the dealer or an experienced radio/television technician for additional suggestions. The following booklets prepared by the Federal Communications Commission (FCC) may also prove helpful:

How to Identify and Resolve Radio-TV Interference Problems (Stock No. 004-000-000345-4) Interface Handbook (Stock No. 004-000-004505-7) These booklets may be purchased from the Superintendent of Documents, U.S. Government Printing Office, Washington, DC 20402.

10.2 Limited Warranty

Technologic Systems warrants this product to be free of defects in material and workmanship for a period of one year from date of purchase. During this warranty period Technologic Systems will repair or replace the defective unit in accordance with the following process:

A copy of the original invoice must be included when returning the defective unit to Technologic Systems, Inc. This limited warranty does not cover damages resulting from lightning or other power surges, misuse, abuse, abnormal conditions of operation, or attempts to alter or modify the function of the product.

This warranty is limited to the repair or replacement of the defective unit. In no event shall Technologic Systems be liable or responsible for any loss or damages, including but not limited to any lost profits, incidental or consequential damages, loss of business, or anticipatory profits arising from the use or inability to use this product.

Repairs made after the expiration of the warranty period are subject to a repair charge and the cost of return shipping. Please, contact Technologic Systems to arrange for any repair service and to obtain repair charge information.