TS-7100

From embeddedTS Manuals
Revision as of 17:42, 17 October 2019 by Kris (talk | contribs) (→‎GPIO: Adding rough layout of most FPGA GPIO pins)
Note: This manual is incomplete at this time and is subject to change without warning while the TS-7100 is in Engineering Sampling phase.


TS-7100-Z
Product Page
Documentation
Schematic
Mechanical Drawing
FTP Path
Processor
NXP i.MX6UL
528MHz or 696MHz
i.MX6UL Product Page
CPU Documentation


Overview

The TS-7100 is a small embedded CPU module with a 696 MHz NXP i.MX6UL CPU. The CPU module provides DDR3 RAM, soldered-down eMMC flash, 2KiB of non-volatile FRAM storage, support for a 16-bit 240x320 resistive-touch LCD display, and many more standard features.

Configuration flexibility can be achieved via the TS-7100's mated I/O board. The I/O board provides industrial-rated connectors and peripherals such as Ethernet, CAN, UARTs, WiFi and Bluetooth to expand functionality and interact with the real world.

The TS-7100-Z is the TS-7100 mated with the TS-7100-Z I/O board. The TS-7100-Z offers a DIN rail mountable enclosure with LCD and touch screen display, as well as wireless connectivity and industrial I/O. Peripherals available on the TS-7100-Z board include: soldered down WiFi with built in Bluetooth, our TS-SILO super capacitor technology for safe shutdown upon power loss, dual 10/100 Ethernet ports, two relays, dual USB host ports, 30 VDC high-current low-side switch outputs or digital inputs, dedicated 30 VDC digital inputs, dedicated high-side switch output, 0-12 V or 4-20 mA ADC inputs, with all I/O protected by a hardware over-voltage or over-current breaker system, and a 8 V to 48 V DC input range.


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 there is no personal distribution preference this is what we recommend for ease of use.

Virtualization

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.


Connect USB Console

The TS-7100 includes a USB Micro B device port; this uses a 8051 based microcontroller to create a debug/console serial interface on a host PC. The serial console is provided through this port at 115200 baud, 8n1, with no flow control. The USB serial device is a CP210x Virtual COM Port. Most operating systems have built-in support for this device. If not however, drivers are available for the device here.

Console from Linux

There are many serial terminal applications for Linux, three common used applications are picocom, screen, and minicom. These examples demonstrate all three applications and assume that the serial device is "/dev/ttyUSB0" which is common for USB adapters. Be sure to replace the serial device string with that of the device on your workstation.

picocom is a very small and simple client. 

sudo picocom -b 115200 /dev/ttyUSB0

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

sudo screen /dev/ttyUSB0 115200

Or a very commonly used client is minicom which is quite powerful but requires some setup: 

sudo 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

Powering Up

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.

Power input to the TS-7100 is supplied via the power input connector, refer to that section for information on voltage ranges for this device.

Once power is applied to the whole device, there will be output on the debug console port. The following section of the manual provides information on getting the serial console connected. 

U-Boot 2016.03-00408-gd450758c91 (Oct 10 2019 - 11:59:08 -0700)

CPU:   Freescale i.MX6UL rev1.2 at 396 MHz
Reset cause: POR
I2C:   ready
DRAM:  512 MiB
MMC:   FSL_SDHC: 0
Net:   FEC0 [PRIME]
Warning: FEC0 (eth0) using random MAC address - 72:12:64:ca:3e:4a

Press Ctrl+C to abort autoboot in 1 second(s)
starting USB...
USB0:   Port not available.
USB1:   USB EHCI 1.00
scanning bus 1 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
No storage devices, perhaps not 'usb start'ed..?
Booting from the eMMC ...
** File not found /boot/boot.ub **
31526 bytes read in 103 ms (298.8 KiB/s)
5253608 bytes read in 354 ms (14.2 MiB/s)
NO CHRG jumper is set, not waiting

Kernel image @ 0x80800000 [ 0x000000 - 0x500220 ]
root ## Flattened Device Tree blob at 83000000
   Booting using the fdt blob at 0x83000000
   Using Device Tree in place at 83000000, end 8300a909

Starting kernel ...
Note: The "*** Warning - bad CRC, using default environment" message can be safely ignored when the unit is first booted. This means that no environment variables have been saved to disk, and U-Boot is falling back to the default. If "env save" is run, this will save the environment to disk, and this message will go away unless there is a further issue.


The default U-Boot boot process will check for USB updates before attempting to boot from on-board eMMC. Details about the bootup process, features, and other U-Boot information can be found in the U-Boot sections.


First Linux Boot

When booting with the default settings, a shipped board will boot to the eMMC. The eMMC by default is pre-programmed with a Debian 10 Buster image. After Debian boots it will ask the user to log in with a username and password. Use "root" as the username with no password. After logging in, a password can be set with the passwd command. Note that this login will only work over the serial console. Debian SSH defaults to not only disallowing un-credentialed logins, but denying root logins altogether.

From the Linux prompt, the hardware can be tested out or application development can begin.

U-Boot

TS-7100 U-Boot Sections


Debian Stretch(9)

Getting Started

By default, the TS-7100 ships with a Debian image installed and ready to boot. It is not necessary to download and install the latest image below for operating the device. However please check the image changelog to verify the running image.

The stock image uses a Debian Stretch distribution and Linux kernel version 4.9. The latest image can be downloaded below.

This image can then be written to the on-board eMMC flash in order to be booted on the TS-7100.


Debian Networking

Note: The first physical port on the TS-7100, socket T1, is given the name "eth1", while the second port, socket T2, is "eth0".


By default, Debian Stretch does not configure any interfaces to be brought up or configured.

Debian can automatically set up the networking based on the contents of "/etc/network/interfaces.d/" files. For example, to enable DHCP for "eth0" by default on startup: 

echo "auto eth0
iface eth0 inet dhcp" > /etc/network/interfaces.d/eth0

To set up a static IP: 

echo "auto eth0
iface eth0 inet static
    address 192.168.0.50
    netmask 255.255.255.0
    gateway 192.168.0.1" > /etc/network/interfaces.d/eth0
echo "nameserver 1.1.1.1" > /etc/resolv.conf

To make this take effect immediately for either option: 

service networking restart

To configure other interfaces, replace "eth0" with the other network device name. Some interfaces may use predictable interface names. For example, the traditional name for an ethernet port might be "eth1", but some devices may use "enp1s0" for PCIe, or "enx00D069C0FFEE" (the MAC address appended) for USB ethernet interfaces. Run 'ifconfig -a' or 'ip a' to get a complete list of interfaces, including the ones that are not configured.


Debian Wi-Fi Client

Wireless interfaces are also managed with configuration files in "/etc/network/interfaces.d/". For example, to connect as a client to a WPA network with DHCP. Note some or all of this software may already be installed on the target SBC.

Install wpa_supplicant: 

apt-get update && apt-get install wpasupplicant -y

Run: 

wpa_passphrase youressid yourpassword

This command will output information similar to: 

 network={
 	ssid="youressid"
 	#psk="yourpassword"
 	psk=151790fab3bf3a1751a269618491b54984e192aa19319fc667397d45ec8dee5b
 }

Use the hashed PSK in the specific network interfaces file for added security. Create the file:

/etc/network/interfaces.d/wlan0 

allow-hotplug wlan0
iface wlan0 inet dhcp
    wpa-ssid youressid
    wpa-psk 151790fab3bf3a1751a269618491b54984e192aa19319fc667397d45ec8dee5b

To have this take effect immediately: 

service networking restart

For more information on configuring Wi-Fi, see Debian's guide here.


Debian Wi-Fi Access Point

This section will discuss setting up the WiFi device as an access point that is bridged to an ethernet port. That is, clients can connect to the AP and will be connected to the ethernet network through this network bridge. The ethernet network must provide a DHCP server; this will be passed through the bridge to WiFi client devices as they connect.

It is also possible to run a DHCP client on the platform itself. In this case the hostapd.conf file needs to be set up without bridging and a DHCP server needs to be configured. Refer to Debian's documentation for more details on DHCP server configuration.

The 'hostapd' utility is used to manage the access point of the device. This is usually installed by default, but can be installed with: 

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


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


Modify the file "/etc/hostapd/hostapd.conf" to have the following lines: 

ssid=YourWiFiName
wpa_passphrase=Somepassphrase
interface=wlan0
bridge=br0
auth_algs=3
channel=7
driver=nl80211
hw_mode=g
logger_stdout=-1
logger_stdout_level=2
max_num_sta=5
rsn_pairwise=CCMP
wpa=2
wpa_key_mgmt=WPA-PSK
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 Wi-Fi 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 Wi-Fi clients an IP address. This setup will allow Wi-Fi clients access to the same network as the ethernet port, and the bridge interface will allow the platform itself to access the network.


Set up hostapd

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

[Unit]
Description=Hostapd IEEE 802.11 AP
Wants=network.target
Before=network.target
Before=network.service
After=sys-subsystem-net-devices-wlan0.device
After=sys-subsystem-net-devices-br0.device
BindsTo=sys-subsystem-net-devices-wlan0.device
BindsTo=sys-subsystem-net-devices-br0.device

[Service]
Type=forking
PIDFile=/run/hostapd.pid
ExecStart=/usr/sbin/hostapd /etc/hostapd/hostapd.conf -P /run/hostapd.pid -B

[Install]
WantedBy=multi-user.target

Then enable this in systemd: 

systemctl enable hostapd_user.service
systemctl enable systemd-networkd


Set up bridging

Create the following files with the listed contents.


"/etc/systemd/network/br0.netdev" 

[NetDev]
Name=br0
Kind=bridge


"/etc/systemd/network/br0.network" 

[Match]
Name=br0

[Network]
DHCP=yes


"/etc/systemd/network/bridge.network" 

[Match]
Name=eth0

[Network]
Bridge=br0


Cellular Data Network

NimbeLink Skywire modem

The CN16 XBee Socket is able to support NimbeLink Skywire Embedded modems. Information on setting up and configuring the power and USB interface for Skywire modules can be found here. Please note that there are various models of the Skywire modules that all support different interfaces. These include "cdc_ether", "cdc_ncm", USB serial, and a simple TTL UART. Both the USB ethernet and NCM interfaces present a network device to the system, while the USB serial and UART interfaces require PPP to manage the connection.

Please see the NimbeLink documentation for the specific module in use for more detailed information on establishing connection with a cellular network via the modem.

Debian Application Development

Debian Stretch Cross Compiling

Debian Stretch provides cross compilers from the Debian apt repository archive for Debian Stretch. An install on a workstation can build for the same release on other architectures. A Linux desktop or laptop PC, virtual machine, or chroot will need to be used for this. Debian Stretch for a workstation can be downloaded from here.

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

# Run "lsb_release -a" and verify Debian 9.X is returned.  These instructions are not
# expected to work on any other version or distribution.
su root
# Not needed for the immediate apt-get install, but used
# so we can install package:armhf for cross compiling
dpkg --add-architecture armhf
apt-get update
apt-get install curl build-essential crossbuild-essential-armhf -y

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 Stretch 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 libraries. 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:
wget https://raw.githubusercontent.com/bagder/curl/master/docs/examples/simple.c
# 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:
./hello-world
# Returns Exec format error
apt-get install qemu-user-static
./hello-world


Debian Installing New Software

Debian provides the apt-get system which allows management of pre-built applications. The apt tools require a network connection to the internet in order to automatically download and install new software. The update command will download a list of the current versions of pre-built packages. 

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
default-jdk - Standard Java or Java compatible Development Kit
default-jdk-doc - Standard Java or Java compatible Development Kit (documentation)
default-jdk-headless - Standard Java or Java compatible Development Kit (headless)
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)
openjdk-8-dbg - Java runtime based on OpenJDK (debugging symbols)
openjdk-8-demo - Java runtime based on OpenJDK (demos and examples)
openjdk-8-doc - OpenJDK Development Kit (JDK) documentation
openjdk-8-jdk - OpenJDK Development Kit (JDK)
openjdk-8-jdk-headless - OpenJDK Development Kit (JDK) (headless)
openjdk-8-jre - OpenJDK Java runtime, using Hotspot JIT
openjdk-8-jre-headless - OpenJDK Java runtime, using Hotspot JIT (headless)
openjdk-8-jre-zero - Alternative JVM for OpenJDK, using Zero/Shark
openjdk-8-source - OpenJDK Development Kit (JDK) source files
uwsgi-app-integration-plugins - plugins for integration of uWSGI and application
uwsgi-plugin-jvm-openjdk-8 - Java plugin for uWSGI (OpenJDK 8)
uwsgi-plugin-jwsgi-openjdk-8 - JWSGI plugin for uWSGI (OpenJDK 8)
uwsgi-plugin-ring-openjdk-8 - Closure/Ring plugin for uWSGI (OpenJDK 8)
uwsgi-plugin-servlet-openjdk-8 - JWSGI plugin for uWSGI (OpenJDK 8)
java-package - Utility for creating Java Debian packages

In this case, the wanted package will likely be the "openjdk-8-jre" package. Names of packages can be found on Debian's wiki pages or the packages site.

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

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

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


Debian Setting up SSH

To install the SSH server, install the package with apt-get: 

apt-get install openssh-server


Debian Stretch by default disallows logins directly from the user "root". Additionally, SSH will not allow remote connections without a password or valid SSH key pair. This means in order to SSH to the device, a user account must first be created, and a password set: 

useradd --create-home --shell /bin/bash newuser
passwd newuser


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


Debian Starting Automatically

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

[Unit]
Description=Run an application on startup

[Service]
Type=simple
ExecStart=/usr/local/bin/your_app_or_script

[Install]
WantedBy=multi-user.target

If networking is a dependency add "After=network.target" 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.

Buildroot Configuration

The full-featured Debian image may be too cumbersome for some applications. Applications that require faster bootup time or a smaller root filesystem will benefit greatly from using a lighter distribution like Buildroot. Using Buildroot for generating images makes it easy to keep software up to date, both userspace and kernel. Additionally, the use of Buildroot allows for building full images completely from source, with semi-reproducable builds, and full software license reports.

To assist customers heading down this path, we maintain our own Buildroot br2-external tree. This tree includes upstream Buildroot as a submodule, which eases updating between Buildroot releases. See the Buildroot manual for more information on Buildroot and br2-external trees.

In order to provide an easy transition from a larger Linux distribution to Buildroot, we provide and maintain two levels of configurations:

  • The base configuration for each device brings in hardware support to get the unit booted, but offers minimal software support and relies mostly on tools provided by BusyBox.
  • An "extra packages" defconfig that can be merged in with any of the base configurations in order to provide many additional packages to create an environment that is more consistent with larger Linux distributions.

The larger Buildroot configuration averages about 10 seconds of boot time, much of which is spent on networking. The base configurations can reduce this time significantly.

Our Buildroot br2-external currently uses the linux-5.10.y branch of our Linux LTS kernel repository for the majority of its supported platforms.


Note: Note that our base configurations include that device's utilities package where possible. Normally, these utilities (e.g. tshwctl, tsmicroctl, etc.) list the git hash of the build source in the help output. However, due to the Buildroot process, the git hash in these utilities reflects the git hash of Buildroot-ts, NOT of the utilities repository. There is no way to work around this without building the utilities outside of Buildroot.


Installing Buildroot

We offer a pre-made filesystem tarball that is based on our default Buildroot configuration. Please contact technical support regarding access to it.

Using that tarball, it's possible to create a bootable eMMC for the TS-7100.

The default configuration was designed to be as close to our stock Debian distribution. This includes our ts7100-utils like tsmicroctl, our TS-SILO monitor daemon, drivers and firmware for the WiFi and Bluetooth module.


Building Buildroot

Buildroot is intended to be completely cross-compiled from a host Linux workstation. This process creates a cross-compiler which is then used to build all target applications, kernel, etc., and then output a bootable image / tarball. The following instructions will create a bootable image / tarball for the target system:

Clone the repository: 

git clone --recurse-submodules https://github.com/embeddedTS/buildroot-ts.git
cd buildroot-ts/
Note: Support for the TS-7100 and TS-7250-V3 in Buildroot are provided by the same configuration files.

Configure the build: 

# The following command uses a Buildroot script to merge two config files.
# The extra_packages_defconfig includes more usual packages to match our stock images
./buildroot/support/kconfig/merge_config.sh technologic/configs/extra_packages_defconfig technologic/configs/ts7250v3_defconfig

# A smaller base image can be made with bare hardware support using:
# make ts7250v3_defconfig

At this point, the default configuration can be modified if desired: 

make menuconfig

And finally, start the build process: 

make


The Buildroot process can take a large amount of time to build depending on available system resources. Note that if any changes occur in the config file, it is recommended to clean the build tree and start the process over. Buildroot ccache is not enabled by default, but can be to help speed up repeated builds. See the Buildroot manual for more information about ccache and Buildroot.


Configuring the Network

Note: See the section on Ethernet Ports for port details specific to your TS-7100 model.

Buildroot implements the ip, ifconfig, route, etc., commands to manipulate the settings of interfaces. The first Ethernet interface is set up to come up automatically with our default configuration. The interfaces can also be manually set up: 

# Bring up the CPU network interface
ifconfig eth0 up

# Set an IP address (assumes 255.255.255.0 subnet mask)
ifconfig eth0 192.168.0.50

# Set a specific subnet
ifconfig eth0 192.168.0.50 netmask 255.255.0.0

# Configure a default route. This is the server that provides an internet connection.
route add default gw 192.168.0.1

# Edit /etc/resolv.conf for the local DNS server
echo "nameserver 192.168.0.1" > /etc/resolv.conf

Most commonly, networks will offer DHCP which can be set up with one command: 

# To setup the default CPU Ethernet port
udhcpc -i eth0
# All Ethernet ports can be made active and request DHCP addresses with:
udhcpc


To have network settings take effect on startup in Buildroot, edit /etc/network/interfaces: 

# interface file auto-generated by Buildroot

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp
  pre-up /etc/network/nfs_check
  wait-delay 15

Note that the default network startup may timeout on some networks, e.g. network protocols such as STP can delay packet movement. This can be resolved in Buildroot by adding network configuration options to fail after a number of attempts (rather than a timeout) or retry for a DHCP lease indefinitely. For example, adding one of the following lines under the iface eth0 inet dhcp section:

  • udhcpc_opts -t 0 to infinitely retry
  • udhcpc_opts -t 5 to fail after five attempts.

See the man page for interfaces(5) for further information on the syntax of the interfaces file and all of the options that can be passed.

For more information on network configuration in general, Debian provides a great resource here that can be readily applied to Buildroot in most cases.

Installing New Software

Buildroot does not include a package manager by default (though it is possible to enable one). This means installing software directly on the platform can be cumbersome and is not the intended path when using Buildroot. It is recommended to modify the Buildroot configuration to include additional packages. See the Building Buildroot section for information on modifying the configuration to build additional packages.

If a desired package is not available in Buildroot, there are a number of options available moving forward. It is possible to add packages to the build process, though this does require some knowledge of Buildroot internals. Another option is to use the cross compiler that is output by Buildroot in order to compile packages on a host system and then copy them over to the target. It is also possible to install a toolchain directly on the device, and compile applications natively. The last option is the least recommended as it greatly increases the final image size and adds unnecessary complexity.


Setting up SSH

The default configuration has Dropbear set up. Dropbear is a lightweight SSH server.

Make sure the device is configured on the network and set a password for the remote user. SSH will not allow remote connections without a password set. The default configuration does not set a password for the root user, nor are any other users configured. 

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.


Starting Automatically

Buildroot defaults to using the BusyBox init system, and all of our provided configurations use this as well. The following custom startup script uses this format. For information on other init systems that Buildroot can use, as well as creating startup scripts for these, see the Buildroot manual.

The most straightforward way to add an application to startup is to create a startup script. This example startup script that will toggle the red LED on during startup, and off during shutdown. In this case the script is named customstartup which can be changed as needed.

Create the file /etc/init.d/S99customstartup with the following contents. Be sure to set the script as executable! 

#! /bin/sh
# /etc/init.d/customstartup

case "$1" in
  start)
    echo 1 > /sys/class/leds/red-led/brightness
    ## If you are launching a daemon or other long running processes
    ## this should be started with
    # nohup /usr/local/bin/yourdaemon &
    ;;
  stop)
    # if you have anything that needs to run on shutdown
    echo 0 > /sys/class/leds/red-led/brightness
    ;;
  *)
    echo "Usage: customstartup start|stop" >&2
    exit 3
    ;;
esac
  
exit 0
Note: The $PATH variable is not set up by default in init scripts so this will either need to be done manually or the full path to your application must be included.

Buildroot provides numerous mechanisms to create this file in the target filesystem at build time. See the Buildroot manual for more information on this.

This script will be automatically called at startup and shutdown thanks to the file location and naming. However, it can also be manually started or stopped: 

/etc/init.d/S99customstartup start
/etc/init.d/S99customstartup stop


Backup / Restore

Creating A Backup / Production Image

Note: This section is incomplete at this time.


Restoring Stock / Backup / Production Image

Booted from USB / NFS

These instructions assume the TS-7100 is booted to Linux from network via NFS or USB mass storage. They also assume that the eMMC is unmodified, with a single partition. If the partition table has been modified, a utility such as 'gparted' or 'fdisk' may be needed to remove the existing partition table and recreate it with a single partition. Note that the partition table must be "MBR" or "msdos", the "GPT" partition table format is not supported by U-Boot.

Once booted to any device that is not the eMMC: 

# Verify nothing else has the first eMMC partition mounted
umount /dev/mmcblk0p1

mkfs.ext3 /dev/mmcblk0p1
mount /dev/mmcblk0p1 /mnt/emmc
wget http://ftp.embeddedTS.com/ftp/ts-arm-sbc/ts-7100-linux/distributions/ts7100-linux4.9-latest.tar.xz
tar -xf ts7100-linux4.9-latest.tar.xz -C /mnt/emmc
umount /mnt/emmc
sync
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 with ext4 for proper compatibility. Older versions of e2fsprogs do not need these options passed nor are they needed for ext3.


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/mmcblk0p1 /mnt/emmc
cd /mnt/emmc/
md5sum --quiet -c md5sums.txt
cd -
umount /mnt/emmc
sync

The 'md5sum' command will report any differences between files and their checksums. Any differences are an indication of failure to write data or a damaged disk. Note that the "/md5sums.txt" file is present in our stock tarballs and is created in custom images as a part of our scripts to do so. This file may not be present in custom images created without our tools, or it may be present but not properly updated. This will result in reported errors.


Compile the Kernel

Compiling the kernel requires an armhf toolchain. We recommend development under Debian Stretch which includes an armhf compiler in the repositories. See the Debian Stretch cross compilation section for instructions on installing a proper cross compiler. 

git clone https://github.com/embeddedTS/linux-lts
# To do a shallow clone of just the latest snapshot of the linux-4.9.y branch, which results in a smaller download size and size on disk, the following command can be used:
# git clone --depth 1 https://github.com/embeddedTS/linux-lts -b linux-4.9.y
cd linux-4.9.y

# 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

## Make any changes in "make menuconfig" or driver modifications, then compile
make && make zImage && make modules


The following will install the kernel and modules to a temporary directory, and then pack them up in to a single tarball: 

TEMPDIR=$(mktemp -d)
mkdir "${TEMPDIR}/boot/"
cp arch/arm/boot/zImage "${TEMPDIR}"/boot/zImage
cp arch/arm/boot/dts/imx6ul*ts*.dtb  "${TEMPDIR}"/boot/
INSTALL_MOD_PATH="${TEMPDIR}" make modules_install
INSTALL_HDR_PATH="${TEMPDIR}" make headers_install 
tar czf linux-tsimx6ul-"$(cat include/config/kernel.release)"-"$(date +"%Y%m%d")".tar.gz -C "${TEMPDIR}" .
rm -rf "${TEMPDIR}"

This will output a tarball with the kernel version and short git hash, as well as the date the tarball was created. For example: linux-tsimx6ul-v4.9.171-60-g01e2117e-20190823.tar.gz

This tarball can be directly unpacked to the root folder of a bootable media for the device. It is also possible to unpack it directly on a booted system, however we do not recommend doing so on an active deployed system without extensive testing. 

# Unpack it to a mounted disk, this assumes the disk is mounted to "/mnt"
zcat linux-tsimx6ul...tar.gz | tar xh -C /mnt

# Unpack it to the root directory of a booted system
zcat linux-tsimx6ul...tar.gz | tar xh -C /


Production Mechanism

The TS-7100's U-Boot has the ability to locate and run a U-Boot script file named /tsinit.ub on the root of a USB drive. This process occurs when attempting to boot to the U-Boot shell. If this script exists, U-Boot will load and run it automatically. This is intended for the initial production of units and allows mass programming various media from a USB mass storage device.

The USB blasting image can be downloaded here. This includes a basic Linux kernel and a small initramfs that will mount the USB drive at "/mnt/usb/" and execute "/mnt/usb/blast.sh".

The blast image and scripts require a minimum of 50 MB; this plus any disk images or tarballs used dictate the minimum disk size required. The USB drive must have at least 1 partition, with the first partition being formatted ext2/3 or fat32/vfat.

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 with ext4 for proper compatibility. Older versions of e2fsprogs do not need these options passed nor are they needed for ext3. 
# This assumes USB drive is /dev/sdc:
sudo mkfs.ext3 /dev/sdc1
sudo mkdir /mnt/usb/
sudo mount /dev/sdc1 /mnt/usb/
sudo tar --numeric-owner -xf /path/to/tsimx6ul_usb_blaster-latest.tar.bz2 -C /mnt/usb/

At this point, disk images or tarballs would be copied to the /mnt/usb/ folder and named as noted below. The latest disk images we provide can be downloaded from our FTP site, see the backup and restore section for links to these files. Note that the script expects images and tarballs to have specific names. When using an ext* filesystem, symlinks can be used.

The formatted USB drive boots into a small Buildroot initramfs environment with filesystem and partitioning tools installed. This can be used to format SD, eMMC, or other disks. The Buildroot environment starts up and calls /blast.sh on the USB device. By default this script is set up to look for a number of of specific files on the USB disk and write these to media on the host device. Upon completion of the script the green or red LEDs will blink to visually indicate a pass or fail of the script. This script can be used without modification to write images from USB with these filenames:

SD Card sdimage.tar.{bz2,xz} Tar of the filesystem. This will repartition the SD card to 1 ext4 partition and extract this tar to the filesystem. If present, a /md5sums.txt file will be checked and every file can be verified on the filesystem. This md5sums file is optional and can be omitted, but it must not be blank if present.
sdimage.dd.{bz2,xz} Disk image of the card. This will be written to the SD card block device directly. If present, a sdimage.dd.md5 file be used to verify the data written to the SD card against this checksum.
eMMC emmcimage.tar.{bz2,xz} Tar of the filesystem. This will repartition the eMMC to 1 ext4 partition and extract this tar to the filesystem. If present, a /md5sums.txt file will be checked and every file can be verified on the filesystem. This md5sums file is optional and can be omitted, but it must not be blank if present.
emmcimage.dd.{bz2,xz} Disk image of the card. This will be written to mmcblk1 directly. If present, a emmcimage.dd.md5 file be used to verify the data written to the SD card against this checksum.

Most users should be able to use the above script without modification. Our buildroot sources are available from our github repo. To build the whole setup and create a USB drive, the following commands can be used. See the repository README for information on the project and how to make modifications. 

make tsimx6ul_usbprod_defconfig && make

The resulting output file tsimx6ul-usb-production-rootfs.tar.bz2 can be unpacked to the first partition of the USB drive as outlined above.


Features

ADC

Note: This section is incomplete at this time.

0-12 V

4-20 mA

Battery Backed RTC

The TS-7100 implements an STMicro "M41T00S" Battery Backed RTC using an external 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. On the TS-7100 series, the RTC is located on the CPU module with the battery backup located on the I/O board.

The TS-7100-Z I/O board provides battery backed power to the RTC via a replaceable CR1632 coin cell.


Bluetooth

Note: The latest image for this platform as of April 28th, 2022 has known issues with the Wi-Fi driver and BLE coexistence due to incompatibility with cfg80211 powersave modes.

If using both Wi-Fi and BLE, it is strongly recommended to bring up the Wi-Fi interface, and then run iw wlan0 set power_save off to disable powersave modes.

This issue will be addressed in future images and has already been addressed in our kernel sources. We will continue to provide updates as we receive them from the Wi-Fi module manufacturer.


The Wi-Fi option for this platform also includes a Bluetooth 5.0 LE module. Support for Bluetooth is provided by the BlueZ project. BlueZ has support for many different profiles for HID, A2DP, and many more. Refer to the BlueZ documentation for more information. Please see our BLE Examples page for information on installing the latest BlueZ release, getting started, and using demo applications.

Both Wi-Fi and Bluetooth can be active at the same time on this platform. Note however, that either the Wi-Fi interface needs to be not brought up if Wi-Fi is unused, or it needs to actively connect to an access point or act as an access point. The Bluetooth module can be activated with the following commands:

For Bluez versions found on Debian Stretch and below: 

# Enable Bluetooth, and load the firmware
echo BT_POWER_UP > /dev/wilc_bt
sleep 1
echo BT_DOWNLOAD_FW > /dev/wilc_bt
sleep 1

# Attach the BLE device to the system, increase the baud, and enable flow control
hciattach /dev/ttymxc2 any 115200 noflow
sleep 1
hcitool cmd 0x3F 0x0053 00 10 0E 00 01
stty -F /dev/ttymxc2 921600 crtscts

# Note that no other HCI commands should be used! In older versions of BlueZ, HCI commands exist alongside bluetoothd, however HCI commands can interfere with the bluetoothd stack.


For newer versions of BlueZ found on Debian Buster or newer, or newer versions of BlueZ built from source: 

echo BT_POWER_UP > /dev/wilc_bt
sleep 1
echo BT_DOWNLOAD_FW > /dev/wilc_bt
sleep 1

btattach -N -B /dev/ttymxc2 -S 115200 &
sleep 1
bluetoothctl power on
sleep 1
hcitool cmd 0x3F 0x0053 00 10 0E 00 01
kill %1 # This terminates the above btattach command
sleep 1
btattach -B /dev/ttymxc2 -S 921600 &


At this point, the device is running at 921600 baud with flow control, and is fully set up ready to be controlled by various components of BlueZ tools. For example, to do a scan of nearby devices: 

bluetoothctl
power on
scan on

This will return a list of devices such as: 

root@ts-imx6ul:~# bluetoothctl  
Agent registered
[CHG] Controller F8:F0:05:XX:XX:XX Pairable: yes
[bluetooth]# power on
Changing power on succeeded
[CHG] Controller F8:F0:05:XX:XX:XX Powered: yes
[bluetooth]# scan on
Discovery started
[CHG] Controller F8:F0:05:XX:XX:XX Discovering: yes
[NEW] Device 51:DD:C0:XX:XX:XX Device_Name
[NEW] Device 2A:20:E2:XX:XX:XX Device_Name
[CHG] Device 51:DD:C0:XX:XX:XX RSSI: -93
[CHG] Device 51:DD:C0:XX:XX:XX RSSI: -82
[NEW] Device E2:08:B5:XX:XX:XX Device_Name
[CHG] Device 51:DD:C0:XX:XX:XX RSSI: -93
[CHG] Device 2A:20:E2:XX:XX:XX RSSI: -94
[NEW] Device 68:62:92:XX:XX:XX Device_Name
[NEW] Device 68:79:12:XX:XX:XX Device_Name
[bluetooth]# quit

Please note that the Bluetooth module requires the modem control lines CTS and RTS as flow control when running at higher baud rates. It is possible to run the module at the initial 115200 baud if the flow control lines are unwanted.

The module supports some other commands as well: 

# Allow the BT chip to enter sleep mode
echo BT_FW_CHIP_ALLOW_SLEEP > /dev/wilc_bt

# Power down the BT radio when not in use
echo BT_POWER_DOWN > /dev/wilc_bt


CAN

The TS-7100-Z CPU has a single FlexCAN port that uses the Linux SocketCAN implementation. The port can be set up and used with the following command: 

ip link set can0 up type can bitrate 1000000


The CAN transceiver is automatically controlled by the kernel. If the interface is brought up in Linux then the transceiver will be enabled. By default when the kernel boots, the interface is down, and therefore the transceiver is disabled.

At this point, the port can be used with standard SocketCAN libraries. In Debian, we provide the utilities 'cansend' and 'candump' to test the ports or as a simple packet send/receive tool. In order to test the port, tie CAN_H to the CAN_H pin of the bus, doing the same for the CAN_L pin. Then use the following commands: 

candump can0
# This command will echo all data received on the bus to the terminal

cansend can0 7Df#03010c
#This command will send out the above CAN packet to the bus


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) {
		perror("socket");
		return -2;
	}
 
 	/* For the ozen myOByDic 1610 this requests the RPM guage */
	frame.can_id  = 0x7df;
	frame.can_dlc = 3;
	frame.data[0] = 3;
	frame.data[1] = 1;
	frame.data[2] = 0x0c;
 
	nbytes = write(s, &frame, sizeof(struct can_frame));
	if(nbytes < 0) {
		perror("write");
		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) {
			perror("read");
			return -4;
		}

		if (nbytes < (int)sizeof(struct can_frame)) {
			fprintf(stderr, "read: incomplete CAN frame\n");
		}
	} while(nbytes == 0);

	if(frame.data[0] == 0x4)
		printf("RPM at %d of 255\n", frame.data[3]);
 
	return 0;
}

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

In production use of CAN we also recommend setting a restart-ms for each active CAN port. 

ip link set can0 type can restart-ms 100

This allows the CAN bus to automatically recover in the event of a bus-off condition.


CPU

This device uses the i.MX6UL CPU, running at 696 MHz, based upon a Cortex-A7 core and targeting low power consumption.

Refer to NXP's documentation for more detailed information on the i.MX6UL.


GPIO

Note: This section is incomplete at this time.
Chip Pin Location
0 0 AIN 4 or 0-12 V Digital Input X on CN32 Terminal
0 4 AIN 0 or 0-12 V Digital Input X on CN32 Terminal
0 5 AIN 1 or 0-12 V Digital Input X on CN32 Terminal
0 8 AIN 2 or 0-12 V Digital Input X on CN32 Terminal
0 9 AIN 3 or 0-12 V Digital Input X on CN32 Terminal
0 18 CPU Red LED
0 19 CPU Green LED
4 0 Power Input Failure
4 1 FPGA Interrupt input pin
4 4 Relay 1 on CN32 Terminal
4 5 Relay 2 on CN32 Terminal
5 0 FPGA DIO 01 or PWM
5 1 FPGA DIO 02 or PWM
5 2 FPGA DIO 03
5 3 FPGA DIO 04
5 4 FPGA DIO 05
5 5 FPGA DIO 06
5 6 FPGA DIO 07
5 7 FPGA DIO 08
5 8 FPGA DIO 09
5 9 FPGA DIO 10 CL_EN
5 10 FPGA DIO 11 CL_EN
5 11 FPGA DIO 12 CL_EN
5 12 Reserved
5 13 Reserved
5 14 FPGA DIO 13 CL_EN
5 15 FPGA DIO 14 or HSPWM
6 1 en AIN 1 12 V
6 2 en AIN 2 12 V
6 3 en AIN 3 12 V
6 4 en AIN 4 12 V
6 5 en usb host 5v
6 6 eth PHY reset
6 7 wifi reset
6 8 TS-7100-Z red LED
6 9 TS-7100-Z green LED
6 12 Reserved
6 13 DIO or PWM
6 14 HSPWM enable
6 15 PWM enable, both OE and dat

eMMC Interface

Note: This section is incomplete at this time.

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

Our default software image contains 2 partitions:

Device Contents
/dev/mmcblk0 eMMC block device
/dev/mmcblk0boot0 eMMC boot partition
/dev/mmcblk0boot1 eMMC boot partition
/dev/mmcblk0p1 Full Debian Linux partition


This platform includes an eMMC device, a soldered down MMC flash device. Our off the shelf builds are 4 GB, but up to 64 GB are available for customized builds. The eMMC flash appears to Linux as an SD card at /dev/mmcblk0. The eMMC 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 all writes will be atomic to 512 B and each NAND cell will be treated as a single layer rather than a multi-layer cell. 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 often able to deal with the older data being present in a 512 B 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.759 GiB. Please note that even with these settings, Technologic Systems strongly recommends designing the end application to eliminate any situations where a power-loss event can occur while any disk is mounted as read/write. The TS-SILO option available on certain TS-7100 I/O boards can help to eliminate the dangerous situation.

The 'mmc-utils' package is used to enable these modes. The command is pre-installed on the latest image. Additionally we have created a script to safely enable the write reliability and pSLC modes. Since the U-Boot binary and environment reside on the eMMC, care must be taken to save the current state of the boot partitions, enable the modes, restore the boot partitions, and re-enable proper booting options. This script can be used in combination with the production mechanism scripting to complete these steps as part of an end application production process.


WARNING: Enabling these modes causes all data on the disk to become invalid and must be rewritten. Do not attempt to run the 'mmc' commands from the script individually, all steps in the script must occur as they are or the unit may be unable to boot. If there are any failures of the script, care must be taken to resolve any issues while the unit is still booted or it may fail to boot in the future.
Note: Enabling these modes is a one-way operation, it is not possible to undo them once they are made. Because of this, setting these eMMC modes will invalidate Technologic Systems' return/replacement warranty on the unit. See the warranty section for more information on this.


The 'emmc_reliability' script can be found in the TS-7100 utilities github repository.

The script must be run when boot from any media other than eMMC, such as NFS, or USB. No partition of the eMMC disk can be mounted when these commands are run. Doing so may result in corruption or inability for the unit to boot. Once the pSLC mode is enabled, all data on the disk will become invalid. This means the partition table will need to be re-created, the filesystems formatted, and all filesystem contents re-written to disk. This is why we recommend using this script in conjunction with the production mechanism scripting. The 'emmc_reliability' script can be run first, then the rest of the production script can create and format the partitions as well as write data to disk.

The script requires a single argument, the device node of the eMMC disk, and will output verbosely to stderr. Any specific errors will also be printed out on stderr.

Example usage: 

./emmc_reliability /dev/mmcblk0

Upon successful run, the script will return 0. Any errors will return a positive code. See the script for detailed error code information.


Ethernet Ports

The NXP processor implements two 10/100 ethernet controllers 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.


FRAM

This device supports an optional non-volatile Ferroelectric RAM (FRAM) device. The Fujitsu MB85RS16N is a 2 KiB device, in a configuration not unlike an SPI EEPROM. However, the nature of FRAM means it is non-volatile, incredibly fast to write, and is specified with 1 trillion read/write cycles per each byte and a 200 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/bus/spi/devices/spi32766.0/eeprom


I2C

The i.MX6UL supports standard I2C at 100 kHz, or using fast mode for 400 kHz operation.


The kernel makes the I2C available at /dev/i2c-# as noted above. Linux i2c-tools (i2cdetect, i2cget, i2cset) can be used to interface with devices, or custom clients can be written.


Interrupts

Note: This section is incomplete at this time.


LCD

Splash Screen

The LCD on this device is able to display a customizable splash screen immediately after power on. This is accomplished by the on-board FPGA reading data from an SPI NOR flash device, and writing it directly to the LCD in its SPI mode. This image is then left on the screen during the rest of the bootup process until the kernel takes over and drives the LCD in parallel RGB mode. The SPI NOR flash can be updated from userspace in Linux to write the new splash screen data.

Since the LCD is a 240x320 display, the final image needs to be formatted to fit this resolution and put in a binary format that the LCD can properly display. We have created a simple script to accomplish this. The script uses ImageMagick's 'convert' tool, as well as 'gcc'. The script will take an input file, translate it to fit the display, build a small tool from C sources, run the translated image through said tool in order to put the image in the correct byte ordering, and then clean up all temporary files. Additionally, a PNG image is output by the tool to be used as a sample reference of what the translated image looks like.

A simple conversion would look like the following: 

./splash-convert Logo.png

# Background color can also be passed:
./splash-convert -background blue NewLogo.jpg

# Any arguments to 'convert' can be arbitrarily passed:
./splash-convert -rotate 120 Logo.png

This will output "splash.out" which can be written directly to the SPI NOR flash as well as "splash.png" which is a sample image of what the splash screen will look like. Since ImageMagick is used to do the heavy lifting of the conversion process, the input file can be of nearly any image format.

The 'splash-convert' tool is available in the TS-7100 utilities repository.


The "splash.out" file can be written to the SPI NOR flash with the following command: 

dd if=/path/to/splash.out of=/dev/mtdblock0 bs=4096 conv=sync

Note that the "bs" and "conv" arguments should always be specified when writing to this SPI NOR device with 'dd' to ensure that the eraseblocks do not receive unnecessary erases and that a full eraseblock is written every time.

Also note that on the TS-7100, the SPI NOR flash is 2 MiB but the splash screen only consumes 152 KiB of space. The rest of this flash space can be used for general storage if wanted.

LEDs

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

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


The following LEDs are available on this system:

  • cpu-red-led
  • cpu-green-led
  • io-red-led
  • io-green-led

A number of triggers are also available, including timers, disk activity, and heartbeat. These allow the LEDs to represent various system activities as they occur. See the kernel LED documentation for more information on triggers and general use of LED class devices.


Relays

Note: This section is incomplete at this time.


Sleep

{{Note| This section is incomplete at this time.

Suspend-to-RAM

SPI

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


TS-SILO Supercapacitors

UARTs


RS-485

USB

The TS-7100-Z offers two USB 2.0 host ports. One port that is always available and usable is the bottom port of the USB A host port stack. The top port is switchable, and instead can be connected to the USB pins of an installed XBee device or NimbeLink modem inserted in to the CN16 socket.

Power to the host ports can be controlled with the LED subsystem under the LED device "/sys/class/leds/en-usb-5v/". By writing a value greater than 0 to the "brightness" file in that folder, it will enable USB power. While setting it to 0 will turn it off. See the DIO section of the manual for more information on this. The USB A host port stack can provide 1 A total power output shared between the two ports.


Watchdog

The TS-7100 implements a WDT inside the supervisory microcontroller. A standard kernel WDT driver is in place that manages the WDT via the I2C bus. The WDT requires a userspace feeding system as the kernel has no provisions for self-feeding. Our stock distribution uses the 'watchdog' utility to check system health, set feed length, and perform feeds. Any arbitrary timeout value between 10 ms through 42949672.95 seconds is possible, with a resolution of 10 ms. Setting a timeout of 0 and issuing a feed will disable the WDT in hardware.

At power-on, the WDT in the microcontroller is live and running. This means that any failures in the boot process will cause a reboot and another attempt. From there, feeds must be manually done in U-Boot or the system booted to Linux within the default 60 second timeout. Once the kernel initializes the WDT driver, it will change the timeout and issue a single feed (default 5 minutes). Userspace must be fully booted and able to take over feeding within this time frame.

The default Linux timeout of 5 minutes was designed to accommodate very slow external I/O. For example, performing an 'fsck' on an external HDD of large sizes via USB mass storage interface, may take a number of minutes worst case. This timeout can be adjusted via the FDT file for the TS-7100. Setting this timeout to 0 will cause the WDT to be disabled in hardware as soon as the kernel is started.

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. If this does not happen then the WDT is not stopped and it will continue it's countdown. This is the default behavior of our stock kernel.

Additionally, if the kernel is compiled with CONFIG_WATCHDOG_NOWAYOUT then the WDT can never be stopped once it is started at boot. This is not enabled by default in our stock kernel

See the Linux WDT API documentation for more information.


WiFi

This board uses an ATWILC3000-MR110CA IEEE 802.11 b/g/n Link Controller Module With Integrated Bluetooth® 4.0. Linux provides support for this module using the wilc3000 driver.

Summary features:

  • IEEE 802.11 b/g/n RF/PHY/MAC SOC
  • IEEE 802.11 b/g/n (1x1) for up to 72 Mbps PHY rate
  • Single spatial stream in 2.4GHz ISM band
  • Integrated PA and T/R Switch Integrated Chip Antenna
  • Superior Sensitivity and Range via advanced PHY signal processing
  • Advanced Equalization and Channel Estimation
  • Advanced Carrier and Timing Synchronization
  • Wi-Fi Direct and Soft-AP support
  • Supports IEEE 802.11 WEP, WPA, and WPA2 Security
  • Supports China WAPI security
  • Operating temperature range of -40°C to +85°C

Specifications

Note: This section is incomplete at this time.

Power Specifications

The TS-7100-Z accepts a range of voltages from 8 V to 28 V DC.


Power Consumption

TS-SILO SuperCaps

External Interfaces

Note: This section is incomplete at this time.


Revisions and Changes

Note: This section is incomplete at this time.

FPGA Changelog

Microcontroller Changelog

PCB Revisions

Software Images

Debian Changelog

U-Boot

Product Notes

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.

Limited Warranty

See our Terms and Conditions for more details.

WARNING: Writing ANY of the CPU's One-Time Programmable registers will immediately void ALL of our return policies and replacement warranties. This includes but is not limited to: the 45-day full money back evaluation period; any returns outside of the 45-day evaluation period; warranty returns within the 1 year warranty period that would require SBC replacement. Our 1 year limited warranty still applies, however it is at our discretion to decide if the SBC can be repaired, no warranty replacements will be provided if the OTP registers have been written.


WARNING: Setting any of the eMMC's write-once registers (e.g. enabling enhanced area and/or write reliability) will immediately void ALL of our return policies and replacement warranties. This includes but is not limited to: the 45-day full money back evaluation period; any returns outside of the 45-day evaluation period; warranty returns within the 1 year warranty period that would require SBC replacement. Our 1 year limited warranty still applies, however it is at our discretion to decide if the SBC can be repaired, no warranty replacements will be provided if the OTP registers have been written.
Retrieved from "http://docs.embeddedTS.com/index.php?title=TS-7100&oldid=11030"