Difference between revisions of "TS-7680"

From Technologic Systems Manuals
(→‎External Reset: Updated External Reset section)
Line 383: Line 383:
  
 
== External Reset ==
 
== External Reset ==
{{Note|Pending software example}}
+
The TS-7680 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|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:
 +
<source lang=bash>
 +
tsmicroctl --resetswitchon  #Enable hardware reset
 +
tsmicroctl --resetswitchoff #Disable hardware reset
 +
</source>
 +
 
 +
 
 +
To read the state of the input pin, see the [[#DIO|DIO]] section for information on reading the Push Switch.
  
 
== FPGA ==
 
== FPGA ==

Revision as of 14:40, 1 March 2016

Note: The TS-7680 is currently in engineering sample phase. This means software and features are very likely to change as the TS-7680 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.


TS-7680
Ts-7680.jpg
Product Page
Documentation
Schematic
Mechanical Drawing
FTP Path
Processor
Freescale i.MX286
454MHz ARM9
CPU Datasheet
RAM
128MB or 256MB DDR2
DIO
16x DIO
External Interfaces
USB 2.0 1 host 1 OTG
1x 10/100 Ethernet
2x CAN ports
5x UARTs
Internal Storage Media
2x SD
1x 2GB NAND
Power Requirements
8-28VDC
Operates around 1.1W
Runs as low as 0.6W

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-7680 has not been finalized and is subject to change at any time

The TS-7680 Rev. A has not been officially released as a standard product, it is currently in sampling phase. This is a small embedded board with a Freescale i.MX286 454Mhz ARM9 CPU with 128-256MB DDR2.

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 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.

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-7680 has an input voltage range of 8v to 28v DC or 24v AC through the main power connector which offers screw terminals for secure wiring. The TS-7680 will require approximately 1.4W at idle. An ideal power supply for the TS-7680 will allow up to 5W to allow peripherals to be powered as well.

Once you have applied power you should look for console output. The first output is from the bootrom:

HTLLCLLC

U-Boot 2014.10-g5bd269d (Nov 18 2015 - 12:26:21)

CPU:   Freescale i.MX28 rev1.2 at 454 MHz
BOOT:  SSP SPI #2, master, 3V3 NOR
I2C:   ready
SPI:   ready
DRAM:  256 MiB
MMC:   MXS MMC: 0, MXS MMC: 1
SF: Detected N25Q64 with page size 256 Bytes, erase size 4 KiB, total 8 MiB
In:    serial
Out:   serial
Err:   serial
Net:   FEC0 [PRIME]
gpio: pin 857 (gpio 857) value is 1
Booting from the SD Card ...
** File not found /boot/boot.ub **
** File not found /boot/ts7680-fpga.vme **
3212744 bytes read in 1020 ms (3 MiB/s)
21333 bytes read in 96 ms (216.8 KiB/s)
## Booting kernel from Legacy Image at 42000000 ...
   Image Name:   Linux-3.14.28-g8f0995c
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3212680 Bytes = 3.1 MiB
   Load Address: 40008000
   Entry Point:  40008000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 41000000
   Booting using the fdt blob at 0x41000000
   Loading Kernel Image ... OK
   Loading Device Tree to 4fb4e000, end 4fb56354 ... OK

Starting kernel ...


Welcome to Debian GNU/Linux 8 (jessie)!

[ SKIP ] Ordering cycle found, skipping LSB: RPC portmapper replacement
         Expecting device dev-ttyAMA0.device...
[  OK  ] Reached target Remote File Systems (Pre).
...
[  OK  ] Started Update UTMP about System Runlevel Changes.

Debian GNU/Linux 8 ts7680 ttyAMA0

ts7680 login:

The i.MX28 internal bootrom prints out the strings of letters to indicate various stages of its internal process. 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-7680 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, 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.

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 but requires some setup:

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

U-Boot is used on this device as the bootloader to launch the full operating system. When the i.MX28 processor starts, it loads U-Boot from the on-board SPI flash. This allows creation of a custom boot image on either the SD, eMMC, NFS, or USB. U-Boot is a general purpose bootloader that is capable of booting into common Linux distributions, Android, Windows, or custom software OSes.

On a normal boot the output will be similar to this:

HTLLCLLC

U-Boot 2014.10-g4d36657 (Dec 07 2016 - 12:19:27)

CPU:   Freescale i.MX28 rev1.2 at 454 MHz
BOOT:  SSP SPI #2, master, 3V3 NOR
I2C:   ready
SPI:   ready
DRAM:  256 MiB
MMC:   MXS MMC: 0, MXS MMC: 1
SF: Detected IS25LQ016B with page size 256 Bytes, erase size 4 KiB, total 2 MiB

In:    serial
Out:   serial
Err:   serial
Net:   FEC0 [PRIME]
NO CHRG jumper is set, not waiting for SuperCaps to charge
Booting from the SD Card ...
** File not found /boot/boot.ub **
3336928 bytes read in 1245 ms (2.6 MiB/s)
20378 bytes read in 265 ms (74.2 KiB/s)
## Booting kernel from Legacy Image at 42000000 ...
   Image Name:   Linux-3.14.28-g1a4251b
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3336864 Bytes = 3.2 MiB
   Load Address: 40008000
   Entry Point:  40008000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 41000000
   Booting using the fdt blob at 0x41000000
   Loading Kernel Image ... OK
   Loading Device Tree to 4fb4b000, end 4fb52f99 ... OK

Starting kernel ...

3.1 U-Boot Environment

On the SPI flash U-boot has both the U-boot application and the U-boot environment. Our default build has 8KB of environment which can be used for variables and scripts to control booting your operating system. These commands are relevant to manipulating the 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

For a production environment the best option for setting depends on the number of units. For a smaller number of units it may be simplest to update any required commands manually. For example, a custom cmdline option like "debug":

env set cmdline_append rw rootwait console=ttyAMA0,115200 loglevel=3 debug
env save

3.2 U-Boot Commands

These commands are agnostic to the operating system that is running, but may be useful for testing or scripting:

# The most important command is 
help
# This can also be used to see more information on a specific command
help mmc

# Boots into the binary at $loadaddr.  This file needs to have
# the uboot header from mkimage.  A uImage already contains this.
bootm
# 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
dhcp
# This sets ${ipaddr}, ${dnsip}, ${gatewayip}, ${netmask}
# and ${ip_dyn} which can be used to check if the dhcp was successful

# These commands are mainly used for scripting:
false # do nothing, unsuccessfully
true # do nothing, successfully

# 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:2 ${loadaddr} /boot/uImage
# Load kernel from USB
usb start
load usb 0:1 ${loadaddr} /boot/uImage

# View the fdt from u-boot with fdt
load mmc 0:2 ${fdtaddr} /boot/imx28-ts7680.dtb
fdt addr ${fdtaddr}
fdt print

# Blindly jump into any memory location
# This is similar to bootm, but it does not use the 
# u-boot header
load mmc 0:2 ${loadaddr} /boot/custombinary
go ${loadaddr}

# Browse fat,ext2,ext3,or ext4 filesystems:
ls mmc 0:2 /

# Similar to devmem in Linux, read/write arbitrary memory
# using mw and md
# write
mw 0x10000000 0xc0ffee00 1
# read
md 0x10000000 1

# Test memory.  Typically just used in production
mtest

# Read newly inserted SD card
mmc rescan
# Read SD card size
mmc dev 0
mmcinfo

# The NFS command is similar to 'load', but used over the network
dhcp
env set serverip 192.168.0.11
nfs ${loadaddr} 192.168.0.11:/path/to/somefile

# Test ICMP
dhcp
ping 192.168.0.11

# Reboot
reset

# 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

# It is possible to load HUSH scripts that have been created with mkimage
load mmc 0:2 ${loadaddr} /boot/ubootscript
source ${loadaddr}

# Most commands have return values that can be used to test
# success, and HUSH scripting supports comparisons similar to
# test in Bash, but much more minimal
if load mmc 0:2 ${fdtaddr} /boot/uImage;
	then echo Loaded Kernel
else
	echo Could not find kernel
fi

# Commands can be timed with "time" similar to Linux
time sf probe

# Print U-boot version/build information
version

3.3 Modify Linux Kernel cmdline

The Linux kernel cmdline can be customized by modifying the cmdline_append variable. Keeping the default options here is recommended, but additional arguments can be appended to this variable.

env set cmdline_append rw rootwait console=ttyAMA0,115200 loglevel=3
env save

You can also change the kernel command line from the onboard Linux. From the board's shell prompt run:

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

The boot.scr includes the plaintext commands to be run in u-boot on startup, and mkimage adds a checksum and header to this file which can be loaded by u-boot. The ub file should not be manually modified.

3.4 Linux NFS Boot

U-boot includes support for NFS which can be used to load your kernel, device tree binary, and root filesystem. Our default environment contains the nfsboot command which can be updated to boot NFS on your network:

# Set this to your NFS server ip
env set nfsip 192.168.0.11;

# Set this to your NFS root path.  The server root should be accessible at this path.
env set nfsroot /nfsroot/rootfs/
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.5 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 ext3 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 target. 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 'imx28 usb' -d tsinit.scr tsinit.ub

# DO NOT MANUALLY EDIT THE .UB FILE

if load usb 0:1 ${loadaddr} /boot/ts${model}-fpga.vme;
        then fpga load 0 ${loadaddr} ${filesize};
fi;

load usb 0:1 ${fdtaddr} /boot/imx28-ts${model}.dtb;

load usb 0:1 ${loadaddr} /boot/uImage;

setenv bootargs root=/dev/sda1 ${cmdline_append};
bootm ${loadaddr} - ${fdtaddr};

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

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

You may need to install u-boot-tools or the equivalent package for your distribution.

3.6 U-Boot Recovery

The development tool, TS-9468, can be used to recover the SBC. Set the flip switch in the "Up" position so it lights up red when powered on to boot from the SPI flash on the TS-9468; the TS-9468 may not ship with a switch, without the switch populated the TS-9468 will automatically boot to the SPI flash on the TS-9468. Use the instructions in Update U-Boot to download and copy in the latest U-Boot binary to SD and boot the unit. And instead of the command listed, use the following:

env set spi onboard
run update-uboot

The script output will include a message saying that it is writing to the onboard SPI flash. The environment variable "spi" can be set to "offboard" in order to force writing to the TS-9468 in order to update the binary on there. Note that if the variable is not set, the script will write to the SPI flash of the SBC or TS-9468 based on the switch position (if there is one).

4 Debian Configuration

For development, it is recommended to work directly in Debian on the SD card. Debian provides many more packages and a much more familiar environment for users already versed in Debian. Through Debian it is possible to configure the network, use the 'apt-get' suite to manage packages, and perform other configuration tasks. Out of the box the Debian distribution does not have any default username/password set. The account "root" is set up with no password configured. It is possible to log in via the serial console without a password but many services such as ssh will require a password set or will not allow root login at all. It is advised to set a root password and create a user account when the unit is first booted.

Note: Setting up a password for root is only feasible on the uSD image.

It is also possible to cross compile applications. Using a Debian host system will allow for installing a cross compiler to build applications. The advantage of using a Debian host system comes from compiling against libraries. Debian cross platform support allows one to install the necessary development libraries on the host, building the application on the host, and simply installing the runtime libraries on the target device. The library versions will be the same and completely compatible with each other. See the respective Debian cross compiling section for more information.

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 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 your route.  This is the server that provides your internet connection.
route add default gw 192.168.0.1

# Edit /etc/resolv.conf for your DNS server
echo "nameserver 192.168.0.1" > /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
dhclient


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.

/etc/systemd/network/eth.network

[Match]
Name=eth*

[Network]
DHCP=yes

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.

/etc/systemd/network/eth0.network

[Match]
Name=eth0

[Network]
Address=192.168.0.50/24
Gateway=192.168.0.1
DNS=192.168.0.1

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

[Unit]
Description=WPA supplicant daemon (interface-specific version)
Requires=sys-subsystem-net-devices-%i.device
After=sys-subsystem-net-devices-%i.device

[Service]
Type=simple
ExecStart=/sbin/wpa_supplicant -c/etc/wpa_supplicant/wpa_supplicant-%I.conf -i%I

[Install]
Alias=multi-user.target.wants/wpa_supplicant@%i.service


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

[Match]
Name=wlan0

[Network]
DHCP=yes

See the systemctl-networkd example for setting a static IP for a network interface. The wlan0.network can be configured the same way as an eth.network.


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 WIFI Access Point

First, hostapd needs to be installed in order to manage the access point on the device:

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


Note: The install process will start an unconfigured hostapd process. This process must be killed and restarted before a new hostapd.conf will take effect.

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

interface=wlan0
driver=nl80211
ssid=YourAPName
channel=1
Note: Refer to the kernel's hostapd documentation for more wireless configuration options.


To start the access point launch hostapd:

hostapd /etc/hostapd/hostapd.conf &

This will start up an access point that can be detected by WIFI clients. A DHCP server will likely be desired to assign IP addresses. Refer to Debian's documentation for more details on DHCP configuration.

4.2 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
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 the remote user. SSH will not allow remote connections without a password or a valid SSH key pair.

passwd root
Note: The default OpenSSH server will not permit root to login via SSH as a security precaution. To allow root to log in via ssh anyway, edit the /etc/ssh/sshd_config file and add the line PermitRootLogin yes in the authentication section. This change will take effect after reboot or after sshd service restart.

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

[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.

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:

#!/bin/bash
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

If you are using a Windows workstation there is no support for writing directly to block devices. However, as long as one of your booting methods still can boot a kernel and the initrd you can rewrite everything by using a usb drive. This is also a good way to blast many stock boards when moving your product into production. You can find more information about this method with an example script here.

Note: Note that the MBR installed by default on this board contains a 446 byte bootloader program that loads the initial power-on kernel and initrd from the first and second partitions. Replacing it with an MBR found on a PC would not work as a PC MBR contains an x86 code bootup program.

5.1 MicroSD Card

MicroSD8GB.png Click to download the latest 4GB SD card image.

Using other OSs

At this time, we're unable to provide assistance with writing SD cards for our products from non-Linux based operating systems. We acknowledge however, that there are methods to write images and files from a variety of difference operating systems. If a native installation of Linux is unavailable, we recommend using a Virtual Machine. See the Getting Started section for links to common virtualization software and Linux installation.

Using a Linux workstation

An SD card can be written to allow it to be bootable. Download the above file and write this from a Linux workstation using the information below. A USB SD adapter can be used to access the card; or if the workstation supports direct connection of SD cards, that can be used instead. Once inserted in to the workstation, it is necessary to discover which /dev/ device corresponds with the inserted SD card before the image can be written.

Option 1: using 'lsblk'


Newer distributions include a utility called 'lsblk' which allows simple identification of the intended card.

Note: This command may need to be run as the root user:
$ lsblk

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
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 and already contains 4 partitions. Note that sdX is not 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 instructions below to write to the device will destroy the partition table and any existing data!

Option 2: Using 'dmesg'


After plugging in the device, the 'dmesg' command can be used to list recent kernel events. When inserting a USB adapter, the last few lines of 'dmesg' output will be similar to the following (note that this command may need to be run as the root user):

$ dmesg
...
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, sdX is shown as a 3.97GB card with a single partition. Note that sdX is not 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 instructions below to write to the device will destroy the partition table and any existing data!


The instructions below use the latest stock image.

Once the target /dev/ device has been located, the 'dd' command can now be used to backup/restore the card to our stock image:

# Specify the correct block device obtained above instead of /dev/sdX
# Note that this is a whole disk image, be sure to use /dev/sdX instead
# of a partition, e.g. /dev/sdX1
wget https://files.embeddedarm.com/ts-arm-sbc/ts-7680-linux/binaries/ts-images/ts7680-latest.dd.bz2
bzcat ts7680-latest.dd.bz2 | dd conv=fsync bs=4M of=/dev/sdX


It is also possible to use this process to update the TS-7680 to the Linux 4.9 kernel with Debian Stretch image. Please take a look at the Caveats of using Linux 4.9 before proceeding in using this image.

# Specify the correct block device obtained above instead of /dev/sdX
# Note that this is a whole disk image, be sure to use /dev/sdX instead
# of a partition, e.g. /dev/sdX1
wget http://ftp.embeddedarm.com/ftp/ts-arm-sbc/ts-7680-linux/binaries/ts-images/ts7680-linux4.9-latest.dd.bz2
bzcat ts7680-linux4.9-latest.dd.bz2 | dd conv=fsync bs=4M of=/dev/sdX

5.2 eMMC

Note: It is generally not required to re-create the partition table. Skip ahead to the next section if the eMMC is otherwise unmodified.

These instructions assume the unit is booted to the SD card (either the stock image or the aftermarket image and the user is logged in as "root".

The eMMC partition table can be created from scratch with the following commands. The command 'parted' is required for re-creating the partition table and it may need to be installed first. Note that if booted to an SD card running Debian Stretch with Linux 4.9, the eMMC device node is different as noted in the caveats. Uncomment the correct bash variable below.

# The 'parted' tool is required and may need to be installed if not already
# apt-get update && apt-get install -y parted

# Uncomment the line below if booted from the stock 3.14 Linux image
# export EMMC_DEV="/dev/mmcblk2"

# Uncomment the line below if booted from the aftermarket 4.9 Debian Stretch image
# export EMMC_DEV="/dev/mmcblk1"

# Verify nothing else has the standard partitions mounted
umount "${EMMC_DEV}"p1
umount "${EMMC_DEV}"p2

dd if=/dev/zero bs=512 count=1 of="${EMMC_DEV}"
parted -s -a optimal "${EMMC_DEV}" mklabel msdos
parted -s -a optimal "${EMMC_DEV}" mkpart primary ext3 1MiB 9MiB
parted -s -a optimal "${EMMC_DEV}" mkpart primary ext3 9MiB 100%

Any number of other partitions can be created at this time, however, U-Boot expects the root filesystem to be on the second partition of the disk.

The instructions below will update the eMMC disk with the latest stock image, but it is also possible to use this process to update the TS-7680 to the Linux 4.9 kernel with Debian Stretch

If booted to an SD card running Debian Stretch with Linux 4.9, the eMMC device node is different as noted in the caveats. Uncomment the correct bash variable below.

# Uncomment the line below if booted from the stock 3.14 Linux image
# export EMMC_DEV="/dev/mmcblk2"

# Uncomment the line below if booted from the aftermarket 4.9 Debian Stretch image
# export EMMC_DEV="/dev/mmcblk1"

# Verify nothing else has the standard partitions mounted
umount "${EMMC_DEV}"p1
umount "${EMMC_DEV}"p2

# Mount, download and unpack filesystem tarball, and flush all cached data
mkfs.ext3 -F "${EMMC_DEV}"p2
mkdir /mnt/emmc
mount "${EMMC_DEV}"p2 /mnt/emmc

# Unpack stock image
wget ftp://ftp.embeddedarm.com/ts-arm-sbc/ts-7680-linux/distributions/ts7680-latest.tar.bz2
tar -xf ts7680-latest.tar.bz2 -C /mnt/emmc

# Comment the above two commands and use the following two commands instead to unpack the Linux 4.9 with Debian Stretch image
# wget http://ftp.embeddedarm.com/ftp/ts-arm-sbc/ts-7680-linux/distributions/ts7680-linux4.9-debian-stretch-arm-latest.tar.bz2
# tar -xf ts7680-linux4.9-debian-stretch-arm-latest.tar.bz2 -C /mnt/emmc

umount /mnt/emmc
sync

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.


Editors

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.

Compilers

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.

Debuggers

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

While it is recommend to develop entirely on the SBC itself, it is also possible to develop from an x86 compatible Linux system using a cross compiler. For this SBC use the cross compiler located here. The resulting binary will be for ARM.

[user@localhost]$ /path/to/arm-fsl-linux-gnueabi/bin/arm-linux-gcc hello.c -o hello
[user@localhost]$ file hello
hello: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), not stripped

This is one of the simplest examples. For working with a larger project a Makefile will typically be used. More information about Makefiles is available here. Another common requirement is linking to third party libraries provided by Debian on the SBC. There is no exact set of steps for every project when cross compiling, but the process will be very much the same. Provide the cross compiler with access to the necessary headers, libraries, and source files, and install the binary on the target. The following example will link to sqlite from Debian.

Install the sqlite library and header on the SBC:

apt-get update && apt-get install -y libsqlite3-0 libsqlite-dev

This will fetch the binaries from the internet and install them on the SBC. The installed files can then be listed with dpkg:

dpkg -L libsqlite3-0 libsqlite3-dev

The needed files from this output will be the .h and .so files, they will need to be copied to the project directory on the cross-compling host.

See the example with libsqlite3 below. This is not intended to provide any functionality, but just call functions provided by sqlite.

#include <stdio.h>
#include <stdlib.h>
#include "sqlite3.h"

int main(int argc, char **argv)
{
	sqlite3 *db;
	char *zErrMsg = 0;
	int rc;
	printf("opening test.db\n");
	rc = sqlite3_open("test.db", &db);
	if(rc){
		fprintf(stderr, "Can't open database: %s\n", sqlite3_errmsg(db));
		sqlite3_close(db);
		exit(1);
	}
	if(rc!=SQLITE_OK){
		fprintf(stderr, "SQL error: %s\n", zErrMsg);
	}
	printf("closing test.db\n");
	sqlite3_close(db);
	return 0;
}

To build this with the external libraries the makefile below can be used. This will have to be adjusted for the proper toolchain path. In this example, the headers are located in external/include and the library in external/lib.

CC=/opt/arm-2008q3/bin/arm-none-linux-gnueabi-gcc
CFLAGS=-c -Wall

all: sqlitetest

sqlitetest: sqlitetest.o
        $(CC) sqlitetest.o external/lib/libsqlite3.so.0 -o sqlitetest
sqlitetest.o: sqlitetest.c
        $(CC) $(CFLAGS) sqlitetest.c -Iexternal/include/

clean:  
        rm -rf *o sqlitetest.o sqlitetest

The resulting binary can be copied to the target and executed. There are many ways to transfer the compiled binaries to the board. Using a network filesystem such as sshfs or NFS will be the simplest to use if needed frequently during development, but will require a setup. See the host linux distribution's manual for more details. The simplest network method is using ssh/sftp. If running Windows, winscp can be used, or just scp in linux. Make sure a password is set for a user account, root or otherwise, in order to properly ssh or scp files to the target. From winscp, enter the ip address of the SBC, the root username, and the password; this will create an explorer window that can use drag-and-drop of files to copy them to the target.

For scp in linux, run:

#replace with the binary name and the SBC IP address
scp sqlitetest root@192.168.0.50:/root/

After transferring the file to the board, execute it:

ts:~# ./sqlitetest 
opening test.db
closing test.db

6.2 Compile the Kernel

For adding new support to the kernel, or recompiling with more specific options you will need to have an x86 compatible Linux host available that can handle the cross compiling. Compiling the kernel on the board is not supported or recommended. Before building the kernel you will need to install a few support libraries on your workstation:

Prerequisites

All systems:

Download and unpack the cross compiler:

Note: The cross compiler set up in the Cross Compiling section is 64-bit and can be used instead of the 32-bit cross compiler below. If using the aforementioned compiler, it is not necessary to install the 32-bit compatibility libraries as is it for the 32-bit cross compiler on a 64-bit Debian Jessie installation.
wget ftp://ftp.embeddedarm.com/ts-arm-sbc/ts-7680-linux/cross-toolchains/imx28-cross-glibc.tar.bz2
tar xvf imx28-cross-glibc.tar.bz2 -C /path/to/folder/

/path/to/folder can be any directory so long as the current user has permissions to write to it. Remember this path as its used later during the kernel build procedure.


RHEL/Fedora/CentOS:

yum install ncurses-devel ncurses
yum groupinstall "Development Tools" "Development Libraries"


Ubuntu/Debian:

sudo apt-get install build-essential libncurses5-dev libncursesw5-dev git u-boot-tools


If you are on a 64-bit system, then 32-bit libraries will be required for the toolchain, for newer Debian and Ubuntu distrubutions with Multiarch support, use the command:

sudo dpkg --add-architecture i386
sudo apt-get update
sudo apt-get install libc6-dev:i386 zlib1g-dev:i386

On older distributions:

sudo apt-get install ia32-libs


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


Download sources and configure

git clone https://github.com/embeddedarm/linux-3.14.28-imx28.git
cd linux-3.14.28-imx28/

# These next commands set up some necessary environment variables
export ARCH=arm
export CROSS_COMPILE=/path/to/folder/arm-fsl-linux-gnueabi/bin/arm-linux-
# If using the 64-bit cross compiler from the Cross Compiling section, the following CROSS_COMPILE variable can be
# used if the environment PATH is set up properly:
# export CROSS_COMPILE=arm-linux-gnueabi-
export LOADADDR=0x40008000

# This sets up the default configuration that we ship with
make ts76xx_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 uImage && 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. We provide a simple script to copy the kernel uImage file, kernel modules, and headers to the SD card to update everything at once.

For example, if your workstation's SD card is /dev/mmcblk0:

./install_hdr_mod mmcblk0p2


If your workstation's SD card is /dev/sdc:

./install_hdr_mod sdc2

7 Features

7.1 ADC

There are 6 Analog to Digital inputs on the TS-7680, 4 of which are on the internal header, and all 6 are available bottom row of the 24-position screw terminal. These are from the i.MX28 CPU LRDAC, the Low-Resolution Analog to Digital Converter peripheral. The CPU peripheral is 12bit, 1.85v input ADC with a 1.3% absolute error. The channels do have diode clamps in place for added over-volt protection.

Sample code to read the ADCs is provided by Technologic Systems, see mx28adcctl.c. This code can be used as-is, or integrated in to a C application. The code can also be translated in to other languages that allow for direct memory mapping and manipulation. The sample code will output the result of all 6 channels and the HSADC peripheral (which is not used on the TS-7680) in its raw value after sampling each channel 10 times and averaging the results.

For more information about the LRADCs, see the CPU manual

ADC Chan. Location(s)
LRADC_ADC0 HD4_14 / B_2
LRADC_ADC1 HD4_12 / B_3
LRADC_ADC2 HD4_10 / B_4
LRADC_ADC3 HD4_8 / B_5
LRADC_ADC4 B_6
LRADC_ADC5 B_7


7.2 Battery Backed RTC

The TS-7680 implements a M41T00S STMicro Battery Backed RTC using an external and replaceable coin cell battery.

7.3 Bluetooth

The WIFI option on the board also includes a bluetooth 4.0 LE module. To connect this to bluez first pulse the BT_EN pin, and then call hciattach:

echo 237 > /sys/class/gpio/export
echo low > /sys/class/gpio/gpio237/direction
echo high > /sys/class/gpio/gpio237/direction
sleep .1
hciattach /dev/ttyAPP0 texas 115200
hciconfig hci0 up

Once this is loaded you can scan for devices with:

hcitool scan

This will return a list of devices such as:

	14:74:11:A1:1E:C9	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.4 CAN

The i.MX28 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


Note: The CAN_EN# signal is connected to CPU DIO 126 and is active low. The pin is de-asserted until the TS systemd script runs and asserts the enable bit. See the DIO section for more information.


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) {
		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.

7.5 CPU

This board features the i.MX286 454 MHz ARM9 from NXP. For more information about the processor and it's included peripherals, refer to the CPU manual.

7.6 DAC

There are four 0-9 V DAC ports on the TS-7680. These DACs can be controlled via a PWM which passes through a low pass filter. The FPGA registers contain a 12-bit register (accessible as two 8-bit registers) for each DAC channel.

Note: Pending software example


The DAC ports are available on the following connectors:

Port Location(s)
0 HD4_5 / B_9
1 HD4_3 / B_10
2 HD4_1 / B_11
3 HD4_2 / B_12

7.7 DIO

The TS-7680 offers DIO, inputs, and low-side switches to accommodate nearly every application. The DIO exposed to various headers and terminals are controlled via the FPGA or CPU. All DIOs are controlled via the kernel sysfs interface. See the kernel's documentation here for more detail. The FPGA DIO pins all implement a crossbar switch and can be set to any combination of inputs and outputs. All DIO are 3.3 V tolerant unless otherwise noted. The low-side switches are able to sink 500 mA each with a maximum voltage input of 30 V (protected by a 30 V Zener diode). The low-side switches, when de-asserted, are high impedance inputs with a pullup resistor. A logical 0 input occurs from roughly 0 V to 1.5 V, while a logical 1 input occurs from roughly 1.6 V and higher on the low-side switches when in input mode.

To interact with DIO pins through the sysfs interface, it first must be exported to userspace, for example, DIO 237 is the BT_EN pin provided by the FPGA:

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

If you receive a permission denied on a pin that means it is claimed by another kernel driver. If it succeeds you will have a /sys/class/gpio/gpio237/ 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 237 high
echo "out" > /sys/class/gpio/gpio237/direction
echo "1" > /sys/class/gpio/gpio237/value
# Set GPIO 237 low
echo "0" > /sys/class/gpio/gpio237/value

# Read the value of GPIO 237
echo "in" > /sys/class/gpio/gpio237/direction
cat /sys/class/gpio/gpio237/value

As an output, the in can be written to 0 for low (GND), or 1 for high (3.3V). As an input the GPIO will have a 100k pullup. It is also possible to use any processor GPIO as an interrupt by writing the edge value, and then using select() or poll() on the value file for changes.


DIO Function Location
39 DIO HD1_14
40 DIO HD1_09
41 DIO HD1_07
52 Input Push Switch
59 Enable 5 V En. 5 V on USB host
73 Power fail N/A
125 DIO HD4_21
192 DIO / Crossbar HD4_22
193 DIO / Crossbar HD4_23
194 DIO / Crossbar HD4_24
195 DIO / Crossbar HD4_25
196 DIO / Crossbar HD4_26
197 DIO / Crossbar HD4_27
198 DIO / Crossbar HD4_28
199 DIO / Crossbar HD4_29
200 DIO / Crossbar HD4_30
201 DIO / Crossbar HD4_31
202 DIO / Crossbar HD4_32
203 DIO / Crossbar HD4_33
204 DIO / Crossbar HD4_34
205 DIO / Crossbar HD4_35
207 LS output HD4_13 / T_4
208 LS output HD4_11 / T_5
209 LS output HD4_09 / T_6
210 Enable Relay Relay 1 en
211 Enable Relay Relay 2 en
233 Enable 5V En. 5 V on HD1_15 / HD1_16
237 Enable BT N/A

7.8 eMMC Interface

The i.MX28 SD card controller support the MMC specification. This SBC includes a soldered down eMMC IC to provide on-board flash media.

Our default software image contains 2 partitions:

Device Contents
/dev/mmcblk2 eMMC block device
/dev/mmcblk2p1 Unused
/dev/mmcblk2p2 Full Debian linux partition

7.9 External Reset

The TS-7680 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.10 FPGA

The TS-7680 features an FPGA designed to accentuate the i.MX28 CPU peripherals with some additional peripherals and flexibility. The FPGA is connected to the CPU through an I2C bus.

See the Syscon section for more information about the FPGA register map.

7.10.1 FPGA Bitstreams

The FPGA has the capability to be reloaded on startup and reprogram itself with different configurations. The FPGA does have an internal configuration is stored, however the FPGA SRAM can be reloaded at bootup to provide an updated FPGA logic, or other custom implementations. U-Boot will automatically load the bitstream located at /boot/ts<model>-fpga.vme on the Debian root at startup.

The FPGA can be updated to the latest revision by booting to Debian and running:

cd /boot/
wget ftp://ftp.embeddedarm.com/ts-arm-sbc/ts-7680-linux/binaries/ts-bitstreams/ts7680-fpga.vme

The FPGA is loaded in to the FPGA SRAM on every poweron, so this file will need to exist for all future boots.


An FPGA revision changelog can be found in the Revisions and Changes section.

7.10.2 FPGA Programming

Currently, creating custom bitstreams is not supported. For more information contact Technologic Systems.

7.10.3 Crossbar

The FPGA includes a Crossbar mux. This allows nearly any output to be assigned any input. An input can be a physical pin, or the output of an FPGA peripheral such as the TXEN generator. Using the Crossbar, it is also possible to re-arrange UART port locations to put UARTs in various IO locations allowing for a large amount of flexibility of the SBC for a specific application.

A tool is provided for easy configuration of the Crossbar muxes. Using 'tshwctl' the current state of the Crossbar muxes can be read and written via environment variables:

root@ts7680:~# tshwctl --get
FPGA_22=GPIO
FPGA_23=GPIO
FPGA_24=GPIO
FPGA_25=GPIO
FPGA_26=GPIO
FPGA_27=GPIO
FPGA_28=GPIO
FPGA_29=GPIO
FPGA_30=GPIO
FPGA_31=GPIO
FPGA_32=GPIO
FPGA_33=GPIO
FPGA_34=GPIO
FPGA_35=GPIO
DC_TXD=UNCHANGED
COM1_TXD=UART1_TXD
COM2_TXD=UART4_TXD
MODBUS_TXD=UART2_TXD
MODBUS_TXEN=UART2_TXEN
RS_485_TXD=UART3_TXD
RS_485_TXEN=UART3_TXEN
BT_RXD=UART0_TXD
BT_CTS=UART0_RTS
UART0_RXD=BT_TXD
UART0_CTS=BT_RTS
UART1_RXD=COM1_RXD
UART2_RXD=MODBUS_RXD
UART3_RXD=RS_485_RXD
UART4_RXD=COM2_RXD
TTYMAX0_RXD=UNCHANGED
TTYMAX0_CTS=UNCHANGED
TTYMAX1_RXD=UNCHANGED
TTYMAX1_CTS=UNCHANGED
TTYMAX2_RXD=UNCHANGED
TTYMAX2_CTS=UNCHANGED

In order to change any of the above assignments, use the named environment variables. For example, to set UART4 to the pins for the daughtercard interface, the following commands can be used:

root@ts7680:~# export DC_TXD=UART4_TXD
root@ts7680:~# export UART4_RXD=DC_RXD
root@ts7680:~# export COM2_TXD=GPIO  #This is used to prevent the COM2 port from transmitting the data that is sent on UART4
root@ts7680:~# tshwctl --set
root@ts7680:~# tshwctl --get
...
DC_TXD=UART4_TXD
...
COM2_TXD=GPIO
...
UART4_RXD=DC_RXD
...

At this point, /dev/ttyAPP4 will now transmit and receive on the DC_TXD and DC_RXD pins.


Available outputs:

Output name Location Default input
FPGA_22 HD4_22 GPIO
FPGA_23 HD4_23 GPIO
FPGA_24 HD4_24 GPIO
FPGA_25 HD4_25 GPIO
FPGA_26 HD4_26 GPIO
FPGA_27 HD4_27 GPIO
FPGA_28 HD4_28 GPIO
FPGA_29 HD4_29 GPIO
FPGA_30 HD4_30 GPIO
FPGA_31 HD4_31 GPIO
FPGA_32 HD4_32 GPIO
FPGA_33 HD4_33 GPIO
FPGA_34 HD4_34 GPIO
FPGA_35 HD4_35 GPIO
DC_TXD HD1_12 UNCHANGED (Unassigned)
COM1_TXD U14 pin 11 UART1_TXD
COM2_TXD U14 pin 10 UART4_TXD
MODBUS_TXD U28 pin 4 UART2_TXD
MODBUS_TXEN U28 pin 2 & 3 UART2_TXEN
RS_485_TXD U29 pin 4 UART3_TXD
RS_485_TXEN U29 pin 2 & 3 UART3_TXEN
BT_RXD K5 pin 34 UART0_TXD
BT_CTS K5 pin 39 UART0_RTS
UART0_RXD U7 pin B8 BT_TXD
UART0_CTS U7 pin P4 BT_RTS
UART1_RXD U7 pin M9 COM1_RXD
UART2_RXD U7 pin N2 MODBUS_RXD
UART3_RXD U7 pin J1 RS_485_RXD
UART4_RXD U7 pin H2 COM2_RXD


Available input assignments:

Input name Location
UNCHANGED N/A
DC_RXD HD1_10
COM1_RXD U14 pin 12
COM2_RXD U14 pin 9
MODBUS_RXD U28 pin 1
RS_485_RXD U29 pin 1
BT_TXD K5 pin 36
BT_RTS K5 pin 35
UART0_TXD U7 pin J2
UART0_TXEN N/A
UART1_TXD U7 pin N5
UART1_TXEN N/A
UART2_TXD U7 pin F1
UART2_TXEN N/A
UART3_TXD U7 pin M2
UART3_TXEN N/A
UART4_TXD U7 pin K1
UART4_TXEN N/A
250KHZ_PHA0 N/A
250KHZ_PHA1 N/A
GPIO N/A
FPGA_22 HD4_22
FPGA_23 HD4_23
FPGA_24 HD4_24
FPGA_25 HD4_25
FPGA_26 HD4_26
FPGA_27 HD4_27
FPGA_28 HD4_28
FPGA_29 HD4_29
FPGA_30 HD4_30
FPGA_31 HD4_31
FPGA_32 HD4_32
FPGA_33 HD4_33
FPGA_34 HD4_34
FPGA_35 HD4_35
DIG_IN[1] HD4_07 / B_8
DIO_2_IN[2] HD4_13 / T_4
DIO_1_IN[2] HD4_11 / T_5
DIO_0_IN[2] HD4_09 / T_6
  1. 5 V tolerant input
  2. 2.0 2.1 2.2 30 V tolerant input

7.11 I2C

The i.MX28 CPU I2C pins are not exposed to any external interfaces on this SBC. Because of this, bitbanging is strongly recommended for any attached peripherals that would utilize I2C.

Technologic Systems recommends using direct bitbanging of I2C pins from userspace to drive an I2C interface. See the DIO section for further information on manipulating DIO pins.

Another option is to implement i2c-gpio in linux. This allows for an I2C physical interface on GPIO pins, but uses the kernel I2C software interface to read and write data on the I2C bus. See linux kernel documentation and i2c-dev for more information on this.

7.12 Jumpers

The TS-7680 has a set of jumpers located between the LEDs and the WiFi/BT module. These jumpers control a number of aspects of the TS-7680's behavior. The jumpers are labeled on the silkscreen rather than numbered:

Label Description
SD When jumper is set, boot kernel and Debian from the SD card. Otherwise boot kernel and Debian from eMMC
UBoot When jumper is set, pause booting in U-Boot and drop to a U-Boot shell. Otherwise booth straight to Debian.
CAN When jumper is set, adds a 120 ohm termination resistor across CAN0 H and L pins. (Note: the CAN1 interface always has a 120 ohm termination)
485 When jumper is set, adds a 120 ohm termination resistor across RS-485 + and - pins. (Note: this is for the RS-485 port, the MODBUS port always has a 120 ohm termination)

7.13 LEDs

On all of our SBCs we include 2 indicator LEDs which are under software control. You can manipulate these using the linux GPIO interface. 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.


Linux GPIO LED control:

LED DIO
Red# 7
Green# 5
Yellow# 58
Blue 56

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 Relays

The TS-7680 features 2 SPDT relays rated for 5A at 277VAC or 30VDC that the user can toggle through an FPGA register. 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 to multiple points. See the DIO section of the manual for information on manipulating the relays.

Relay 1
Contact Location(s)
COM T_8 / HD4_19
NO T_7 / HD4_15
NC T_9 / HD4_17
Relay 2
Contact Location(s)
COM T_11
NO T_10
NC T_12

7.16 Sleep

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. Note that as soon as the command to sleep is issued, the device will sleep as soon as possible. This has the ability to cause filesystem corruption if proper precautions are not taken before the SBC is put to sleep. In order to enter this mode, issue the following command:

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


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. Waking up from this mode 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.

7.17 SPI

This SBC utilizes all of the i.MX28 CPU SPI ports for the SD cards, therefore there is no externally available SPI peripheral from the CPU. Because of this, bitbanging is strongly recommended for any attached peripherals that would utilize SPI.

Technologic Systems recommends using direct bitbanging of SPI pins from userspace to drive an SPI interface. See the DIO section for further information on manipulating DIO pins.

Another option is to implement spi-gpio in linux. This allows for a SPI physical interface on GPIO pins, but uses the kernel SPI software interface to read and write data on the SPI bus. See linux kernel documentation, spi-gpio, and spidev for more information on this.

7.18 Syscon

All of the registers below are 8 bits wide and are accessed through the I2C interface. The FPGA is located at 7 bit address 0x28 on the linux device /dev/i2c-0. Accessing registers can either be done directly via tshwctl with the --peek and --poke options, using tshwctl options to abstract some of the access details away, or directly accessing and manipulating the linux I2C device. See the tshwctl sources for an example of how this is implemented


Offset GPIO # Bits Usage [Initial value/MUX]
0x0
192 7:2 FPGA_22 Crossbar [GPIO] (RW)
1 FPGA_22 value [0] (RW)
0 FPGA_22 output enable [0] (RW)
0x1
193 7:2 FPGA_23 Crossbar [GPIO] (RW)
1 FPGA_23 value [0] (RW)
0 FPGA_23 output enable [0] (RW)
0x2
194 7:2 FPGA_24 Crossbar [GPIO] (RW)
1 FPGA_24 value [0] (RW)
0 FPGA_24 output enable [0] (RW)
0x3
195 7:2 FPGA_25 Crossbar [GPIO] (RW)
1 FPGA_25 value [0] (RW)
0 FPGA_25 output enable [0] (RW)
0x4
196 7:2 FPGA_26 Crossbar [GPIO] (RW)
1 FPGA_26 value [0] (RW)
0 FPGA_26 output enable [0] (RW)
0x5
197 7:2 FPGA_27 Crossbar [GPIO] (RW)
1 FPGA_27 value [0] (RW)
0 FPGA_27 output enable [0] (RW)
0x6
198 7:2 FPGA_28 Crossbar [GPIO] (RW)
1 FPGA_28 value [0] (RW)
0 FPGA_28 output enable [0] (RW)
0x7
199 7:2 FPGA_29 Crossbar [GPIO] (RW)
1 FPGA_29 value [0] (RW)
0 FPGA_29 output enable [0] (RW)
0x8
200 7:2 FPGA_30 Crossbar [GPIO] (RW)
1 FPGA_30 value [0] (RW)
0 FPGA_30 output enable [0] (RW)
0x9
201 7:2 FPGA_31 Crossbar [GPIO] (RW)
1 FPGA_31 value [0] (RW)
0 FPGA_31 output enable [0] (RW)
0xA
202 7:2 FPGA_32 Crossbar [GPIO] (RW)
1 FPGA_32 value [0] (RW)
0 FPGA_32 output enable [0] (RW)
0xB
203 7:2 FPGA_33 Crossbar [GPIO] (RW)
1 FPGA_33 value [0] (RW)
0 FPGA_33 output enable [0] (RW)
0xC
204 7:2 FPGA_34 Crossbar [GPIO] (RW)
1 FPGA_34 value [0] (RW)
0 FPGA_34 output enable [0] (RW)
0xD
205 7:2 FPGA_35 Crossbar [GPIO] (RW)
1 FPGA_35 value [0] (RW)
0 FPGA_35 output enable [0] (RW)
0xE
N/A 7:4 Reserved
3 DIG_IN 5V (RO)
2 DIO_2_IN (RO)
1 DIO_1_IN (RO)
0 DIO_0_IN (RO)
0xF
207 7:2 Reserved
1 Enable LS_DIO_0 value [0] (RW)
0 Reserved
0x10
208 7:2 Reserved
1 Enable LS_DIO_1 value [0] (RW)
0 Reserved
0x11
209 7:2 Reserved
1 Enable LS_DIO_2 value [0] (RW)
0 Reserved
0x12
210 7:2 Reserved
1 Enable Relay 1 [0] (RW)
0 Reserved
0x13
211 7:2 Reserved
1 Enable Relay 2 [0] (RW)
0 Reserved
0x14
N/A 7:2 DC TXD Crossbar [Unassigned] (RW)
1 DC TXD value [0] (RW)
0 Reserved
0x15
N/A 7:2 COM1 TXD Crossbar [UART1_TXD] (RW)
1 COM1 TXD value [0] (RW)
0 Reserved
0x16
N/A 7:2 COM2 TXD Crossbar [UART4_TXD] (RW)
1 COM2 TXD value [0] (RW)
0 Reserved
0x17
N/A 7:2 MODBUS TXD Crossbar [UART2_TXD] (RW)
1 MODBUS TXD value [0] (RW)
0 Reserved
0x18
N/A 7:2 MODBUS TXEN Crossbar [UART2_TXEN] (RW)
1 MODBUS TXEN value [0] (RW)
0 Reserved
0x19
N/A 7:2 RS-485 TXD Crossbar [UART3_TXD] (RW)
1 RS-485 TXD value [0] (RW)
0 Reserved
0x1A
N/A 7:2 RS-485 TXEN Crossbar [UART3_TXEN] (RW)
1 RS-485 TXEN value [0] (RW)
0 Reserved
0x1B
N/A 7:2 Bluetooth RXD Crossbar [UART0_TXD] (RW)
1 Bluetooth RXD value [0] (RW)
0 Reserved
0x1C
N/A 7:2 Bluetooth CTS Crossbar [UART0_RTS] (RW)
1 Bluetooth CTS value [0] (RW)
0 Reserved
0x1D
N/A 7:2 UART0 RXD Crossbar [BT_TXD] (RW)
1 UART0 RXD value [0] (RW)
0 Reserved
0x1E
N/A 7:2 UART0 CTS Crossbar [BT_RTS] (RW)
1 UART0 CTS value [0] (RW)
0 Reserved
0x1F
N/A 7:2 UART1 RXD Crossbar [COM1_RXD] (RW)
1 UART1 RXD value [0] (RW)
0 Reserved
0x20
N/A 7:2 UART2 RXD Crossbar [MODBUS_RXD] (RW)
1 UART2 RXD value [0] (RW)
0 Reserved
0x21
N/A 7:2 UART3 RXD Crossbar [RS_485_RXD] (RW)
1 UART3 RXD value [0] (RW)
0 Reserved
0x22
N/A 7:2 UART4 RXD Crossbar [COM2_RXD] (RW)
1 UART4 RXD value [0] (RW)
0 Reserved
0x23
227 7:2 Reserved
1 En.# pullup AD0 [1] (RW)
0 Reserved
0x24
228 7:2 Reserved
1 En.# pullup AD1 [1] (RW)
0 Reserved
0x25
229 7:2 Reserved
1 En.# pullup AD2 [1] (RW)
0 Reserved
0x26
230 7:2 Reserved
1 En.# pullup AD3 [1] (RW)
0 Reserved
0x27
231 7:2 Reserved
1 En. Current loop AD 0-1 [0] (RW)
0 Reserved
0x28
232 7:2 Reserved
1 En. Current loop AD 2-3 [0] (RW)
0 Reserved
0x29
233 7:2 Reserved
1 En. 5v on DC header [0] (RW)
0 Reserved
0x2A
N/A 7:3 Reserved
2 Disable SPI interface (en. UART2 & 3) [0] (RW)
1 Boot SPI select; 0: offbd, 1: onbd [0] (RW)
0 Override automatic Boot SPI select [0] (RW)
0x2B
235 7:2 Reserved
1 Ethernet reset# [0] (RW)
0 Reserved
0x2C
236 7:2 Reserved
1 WLAN En. [0] (RW)
0 Reserved
0x2D
237 7:2 Reserved
1 Bluetooth En. [0] (RW)
0 Reserved
0x2E
N/A 7:4 Unused
3:0 Bits 11:8 of DAC0 PWM value [0] (RW)[1]
0x2F N/A 7:0 Bits 7:0 of DAC0 PWM value [0] (RW)
0x30
N/A 7:4 Unused
3:0 Bits 11:8 of DAC1 PWM value [0] (RW)[1]
0x31 N/A 7:0 Bits 7:0 of DAC1 PWM value [0] (RW)
0x32
N/A 7:4 Unused
3:0 Bits 11:8 of DAC2 PWM value [0] (RW)[1]
0x33 N/A 7:0 Bits 7:0 of DAC02 PWM value [0] (RW)
0x34
N/A 7:4 Unused
3:0 Bits 11:8 of DAC3 PWM value [0] (RW)[1]
0x35 N/A 7:0 Bits 7:0 of DAC3 PWM value [0] (RW)
0x36 N/A 7:0 Bits 23:16 of auto-485 #0 counter #0 [0] (RW)[1][2]
0x37 N/A 7:0 Bits 15:8 of auto-485 #0 counter #0 [0] (RW)[1][2]
0x38 N/A 7:0 Bits 7:0 of auto-485 #0 counter #0 [0] (RW)[2]
0x39 N/A 7:0 Bits 23:16 of auto-485 #0 counter #1 [0] (RW)[1][3]
0x3A N/A 7:0 Bits 15:8 of auto-485 #0 counter #1 [0] (RW)[1][3]
0x3B N/A 7:0 Bits 7:0 of auto-485 #0 counter #1 [0] (RW)[3]
0x3C N/A 7:0 Bits 23:16 of auto-485 #1 counter #0 [0] (RW)[1][2]
0x3D N/A 7:0 Bits 15:8 of auto-485 #1 counter #0 [0] (RW)[1][2]
0x3E N/A 7:0 Bits 7:0 of auto-485 #1 counter #0 [0] (RW)[2]
0x3F N/A 7:0 Bits 23:16 of auto-485 #1 counter #1 [0] (RW)[1][3]
0x40 N/A 7:0 Bits 15:8 of auto-485 #1 counter #1 [0] (RW)[1][3]
0x41 N/A 7:0 Bits 7:0 of auto-485 #1 counter #1 [0] (RW)[3]
0x42 N/A 7:0 Bits 23:16 of auto-485 #2 counter #0 [0] (RW)[1][2]
0x43 N/A 7:0 Bits 15:8 of auto-485 #2 counter #0 [0] (RW)[1][2]
0x44 N/A 7:0 Bits 7:0 of auto-485 #2 counter #0 [0] (RW)[2]
0x45 N/A 7:0 Bits 23:16 of auto-485 #2 counter #1 [0] (RW)[1][3]
0x46 N/A 7:0 Bits 15:8 of auto-485 #2 counter #1 [0] (RW)[1][3]
0x47 N/A 7:0 Bits 7:0 of auto-485 #2 counter #1 [0] (RW)[3]
0x48 N/A 7:0 Bits 23:16 of auto-485 #3 counter #0 [0] (RW)[1][2]
0x49 N/A 7:0 Bits 15:8 of auto-485 #3 counter #0 [0] (RW)[1][2]
0x4A N/A 7:0 Bits 7:0 of auto-485 #3 counter #0 [0] (RW)[2]
0x4B N/A 7:0 Bits 23:16 of auto-485 #3 counter #1 [0] (RW)[1][3]
0x4C N/A 7:0 Bits 15:8 of auto-485 #3 counter #1 [0] (RW)[1][3]
0x4D N/A 7:0 Bits 7:0 of auto-485 #3 counter #1 [0] (RW)[3]
0x4E N/A 7:0 Bits 23:16 of auto-485 #4 counter #0 [0] (RW)[1][2]
0x4F N/A 7:0 Bits 15:8 of auto-485 #4 counter #0 [0] (RW)[1][2]
0x50 N/A 7:0 Bits 7:0 of auto-485 #4 counter #0 [0] (RW)[2]
0x51 N/A 7:0 Bits 23:16 of auto-485 #4 counter #1 [0] (RW)[1][3]
0x52 N/A 7:0 Bits 15:8 of auto-485 #4 counter #1 [0] (RW)[1][3]
0x53 N/A 7:0 Bits 7:0 of auto-485 #4 counter #1 [0] (RW)[3]
0x7E
NA 7:3 Reserved
2 WiFi Module present
1:0 Reserved
0x7F NA 7:0 FPGA Revision
  1. 1.00 1.01 1.02 1.03 1.04 1.05 1.06 1.07 1.08 1.09 1.10 1.11 1.12 1.13 1.14 1.15 1.16 1.17 1.18 1.19 1.20 1.21 1.22 1.23 MUST be written before bits 7:0
  2. 2.00 2.01 2.02 2.03 2.04 2.05 2.06 2.07 2.08 2.09 2.10 2.11 2.12 2.13 2.14 Value of counter #0 must be set to count to the mid-point of the stop bit based on a 25MHz clock
  3. 3.00 3.01 3.02 3.03 3.04 3.05 3.06 3.07 3.08 3.09 3.10 3.11 3.12 3.13 3.14 Value of counter #1 must be set to count to one-half bit time based on a 25MHz clock

7.19 Temperature Sensor

Note: Pending software example

7.20 UARTs

The TS-7680 CPU offers 5 UARTs. All 5 of the CPU UARTs are run through the FPGA through the Crossbar mux to control where they go. The mux allows for extreme flexibility in use of UARTs and how they are set up. The table below lists the CPU UARTs with their default assignment and those default pin locations. The subsections list and describe the various external interfaces, including RS-232 and RS-485, any extra set up configurations, and their Crossbar mux input names.

Name Mux output Mux input Def. Assign. Def. Type Def. TX / + Def. RX / -
ttyAPP0[1] UART0_TXD UART0_RXD Bluetooth TTL N/A N/A
ttyAPP1 UART1_TXD UART1_RXD COM1 RS-232 J4_6 J4_5
ttyAPP2 UART2_TXD UART2_RXD MODBUS RS-485 J6_4 J6_5
ttyAPP3 UART3_TXD UART3_RXD RS-485 RS-485 T_2 T_3
ttyAPP4 UART4_TXD UART4_RXD COM2 RS-232 J4_8 J4_7
  1. Also brings out CTS and RTS as UART0_CTS and UART0_RTS Crossbar mux names.


7.20.1 RS-485

The TS-7680 offers two RS-485 ports. These ports default to CPU UART 2 and 3. The half-duplex transmit-enable is handled by the FPGA having two sets of values per-port to control the timing of the TXEN line. There are a total of 5 auto-TXEN blocks, each one is assigned to a UART. In order to set up these registers, the following command must be issued before the TXEN will function properly:

tshwctl --autotxen <uart number> --baud <baud>

Additionally, different modes can be passed to the command to adjust for the number of bits, for example:

tshwctl --autotxen <uart number> --baud <baud> --mode 8n1  #Default 8n1 mode, 8 data bits, no parity, 1 stop bit
tshwctl --autotxen <uart number> --baud <baud> --mode 7e2  #7 data bits, even parity, 2 stop bits

Note that the baud and mode actually used on the UART must match what is passed to tshwctl. Any differences will cause TXEN to be released too soon or held too long and cause unexpected issues on the bus. If the mode or baud rate of the UART is changed, the tshwctl commands must be re-issued with the new settings.

The RS-485 ports are available on the following external connectors and Crossbar mux settings:

Name Mux output Mux input + location - location
MODBUS MODBUS_TXD MODBUS_RXD J6_4 J6_5
RS-485 RS_485_TXD RS_485_RXD T_2 T_3


7.20.1.1 MODBUS

The J6 connector is set up for a standard 2W-MODBUS pinout that provides power. The voltage output is VIN minus a diode drop. The power can be enabled with the following command:

tshwctl --modbuspoweron
#Will return
modbuspoweron=1

The power on sequence will first apply 3 V, verify there is no short on the bus, and then apply the full voltage. If the command returns 'modbuspoweron=0' then that means there is a detected short on the other side of the bus due to mis-wiring or incorrect connection on the other side. The power can be turned off with:

tshwctl --modbuspoweroff

7.20.2 COM Ports

There are two RS-232 COM ports available on the TS-7680. These default to UART 1 and 4. These can be used through the standard linux interface to set up and control COM ports, there are no additional settings required.

The COM ports are available on the following external connectors and Crossbar mux settings:

Name Mux output Mux input TX location RX location
COM1 COM1_TXD COM1_RXD J4_6 J4_5
COM2 COM2_TXD COM2_RXD J4_8 J4_7


7.20.3 Misc. Ports

The TS-7680 has a 1.8 V TTL UART Bluetooth interface, and a pair of pins on a header dedicated to connect to a Daughter Card with a TTL UART connection. Additionally, with the Crossbar mux, nearly any IO pin can be set up to act as TX or RX for each of the UARTs.

The following table lists information about these two interfaces:

Name Mux output Mux input TX location RX location
Bluetooth[1] BT_RXD BT_TXD N/A N/A
Daughter Card DC_TXD DC_RXD HD1_12 HD1_10
  1. Note, the Bluetooth modules requires the control lines CTS and RTS, their Crossbar mux names are BT_CTS and BT_RTS

7.21 USB

The USB host port is a standard USB 2.0 at 480Mbps. The Linux kernel provides most of the USB support, and some devices may require a kernel recompile. For creating custom USB support, libusb may be the easiest route.

USB 5V Power can be disabled or re-enabled using DIO 69, marked EN_USB_5V on the schematic. See the syscon for more information on using this bit.

See the WIFI-N-USB manual for information on our WIFI support.

7.22 Watchdog

This SBC implements a Watch Dog Timer in a microcontroller on the SBC. An external WDT allows for high assurance operation of the WDT, as it uses external hardware, kernel level software, and userspace level software. If any of the three fail then the WDT will timeout and reboot the whole system. A standard kernel WDT driver is in place. As soon as the kernel starts it will start the WDT and feed it on 30 second timeouts every 15 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.

7.23 Wi-Fi

This SBC includes a TiWi-BLE SDIO module that uses the Texas Instruments WL1271L Transceiver. Linux provides support for this using the wl12xx driver. See the LSR site for detailed product information.

Summary Features:

  • IEEE 802.11 b/g/n
  • 2.4GHz
  • Linux drivers include support for client and AP mode
  • Industrial temp, -40 to 85C
  • Certifications
    • FCC Bluetooth® Grant
    • FCC WLAN Grant
    • IC
    • CE
    • SAR Testing
    • SAR Testing EU

Linux uses the "wireless-tools", "wpa-supplicant", and "hostapd" packages to support most of the functionality in this module. Refer to the distribution support for more information.

8 External Interfaces

8.1 HD1 Pin Header

Pin Name
HD1_1 VIN
HD1_2 POE_78
HD1_3 GND
HD1_4 POE_45
HD1_5 GND
HD1_6 POE_TX
HD1_7 DIO 41
HD1_8 POE_RX
HD1_9 DIO 40
HD1_10 DC_RXD [1]
HD1_11 USB OTG -
HD1_12 DC_RXD
HD1_13 USB OTG +
HD1_14 DIO 39
HD1_15 5 V (En. DIO 233)
HD1_16 5 V (En. DIO 233)
Pin Layout
1 2
3 4
5 6
7 8
9 10
11 12
13 14
15 16
  1. 5V tolerant input

8.2 HD4 Pin Header

Pin Name
HD4_1 DAC_2
HD4_2 DAC_3
HD4_3 DAC_1
HD4_4 AN5 / CAN0_H
HD4_5 DAC_0
HD4_6 AN4 / CAN0_L
HD4_7 DIG_IN [1]
HD4_8 AN3
HD4_9 LS output 207
HD4_10 AN2
HD4_11 LS output 208
HD4_12 AN1
HD4_13 LS output 209
HD4_14 AN0
HD4_15 Relay 1 NO
HD4_16 CAN0 TX
HD4_17 Relay 1 NC
HD4_18 CAN0 RX [1]
HD4_19 Relay 1 Com.
HD4_20 3.3 V
HD4_21 DIO 125
HD4_22 DIO 192
HD4_23 DIO 193
HD4_24 DIO 194
HD4_25 DIO 195
HD4_26 DIO 196
HD4_27 DIO 197
HD4_28 DIO 198
HD4_29 DIO 199
HD4_30 DIO 200
HD4_31 DIO 201
HD4_32 DIO 202
HD4_33 DIO 203
HD4_34 DIO 204
HD4_35 DIO 205
HD4_36 5 V
HD4_37 GND
HD4_38 VIN
Pin Layout
1 2
3 4
5 6
7 8
9 10
11 12
13 14
15 16
17 18
19 20
21 22
23 24
25 26
27 28
29 30
31 32
33 34
35 36
37 38
  1. 1.0 1.1 5V tolerant input

8.3 24 pos. Screw Terminal

7680-pinout.png

Top
Pin Name
T_1 GND
T_2 RS-485 +
T_3 RS-485 -
T_4 LS output 207
T_5 LS output 208
T_6 LS output 209
T_7 Relay 1 NO
T_8 Relay 1 Com.
T_9 Relay 1 NC
T_10 Relay 2 NO
T_11 Relay 2 Com.
T_12 Relay 2 NC
Bottom
Pin Name
B_1 GND
B_2 AN0
B_3 AN1
B_4 AN2
B_5 AN3
B_6 AN4 / CAN0_L
B_7 AN5 / CAN0_H
B_8 DIG_IN[1]
B_9 DAC_0
B_10 DAC_1
B_11 DAC_2
B_12 DAC_3
  1. 5 V tolerant input

8.4 J4 RJ-45

Pin Name
J4_1 CAN1_H
J4_2 CAN1_L
J4_3 GND
J4_4 GND
J4_5 COM1_RXD
J4_6 COM1_TXD
J4_7 COM2_RXD
J4_8 COM2_TXD

8.5 J6 RJ-45

Pin Name
J6_1 GND
J6_2 GND
J6_3 GND
J6_4 MODBUS +
J6_5 MODBUS -
J6_6 MODBUS Power
J6_7 MODBUS Power
J6_8 GND

9 Revisions and Changes

9.1 Microcontroller Changelog

Revision Changelog
0
  • Initial release
1
  • Read VIN to turn on CPU at 7.5V and turn off at 7V
  • Bugfix where ADC was being overdriven, resulting in improper results
2
  • Disabled WDT on bootup, needed for U-Boot at this time.
3
  • Transfer to SiLabs 8051 microcontroller
  • Updates for TS-7680 Rev. B PCB
  • Added support for Supercapacitor charging and discharging

9.2 FPGA Changelog

Revision Changelog
0
  • Initial release, contains no revision register
1
  • Fixed pinmaps to match TS-7680 rev A PCB
  • Set up revision register at 0x3f
  • Put bt_en on its own bit
  • set wl_en and bt_en to always drive high
2
  • Implemented fpga_spare_0_pad as global reset pin
  • Default to turn on bt_en and wl_en
  • Set bt_en and wl_en to be controlled via register
3
  • Reworked 485 input pins to use proper CPU UARTs
  • Inverted PWM output to set 0x0 to 0v
  • Inverted EN_PU_ADC polarity so 1 == enabled
4
  • Fixed race condition with auto485 TXEN logic
  • Cleaned up possible metastability issue on input signal
  • Added reset logic for PWM and auto485 blocks
5
  • Change wl_en and bt_en registers to match the GPIO registers with bit 1 as the actual enable bit
6
  • Change FPGA to Lattice MachXO2
  • Extended register map
  • Added crossbar mux support for more flexible IO configuration
  • Minor changes to accommodate TS-7680 Rev. B PCB
7
  • Cleaned up pull resistor directions
  • Fixed bug in logic for SPI boot selection
8
  • Added an SPI_DISABLE bit to disable CS assertion on SPI after bootup is complete

9.3 PCB Revisions

Revision Changelog
A
  • Initial release
B
  • Change from iCE40 to MachXO2 FPGA
  • Change from ARM M0 to 8051 microcontroller
  • Change from NAND to eMMC soldered down flash
  • Always boot to SPI
  • Changed RTC from ISL12022 to M41T005
  • Added Supercapacitors to provide power if main input voltage drops out
  • Set up UART lines to allow for BT functionality
  • Added jumper to break in to U-Boot shell

9.4 Software Images

Image File Changelog Known Issues
ts7680-jan092015.dd.bz2

ts7680-jan092015.ubifs

  • First official Engineering sample image release
  • WiFi interface cannot be brought down and back up again successfully. Does not affect normal behavior as a station, does break master mode however.
  • U-Boot expects environment to always be on SD card, whether booted from SD or NAND.
  • NAND images cannot be written from U-Boot, must be written from initramfs/Debian.
  • VLAN support is not enabled in kernel.
  • Extra user account support/support exists on the system and may pose a security risk.
  • Deprecated, we strongly recommend against using this image
ts7680-mar302015.dd.bz2

ts7680-mar302015.ubifs

  • Kernel is now 3.14
  • WiFi Device fully working
  • NAND does not function due to an issue with UBIFS
  • Integrated Bluetooth not functional
  • 3.14 breaks standby mode of the CPU
  • Deprecated, we strongly recommend against using this image
ts7680-sep212015.dd.bz2
  • BT fully working
  • Software updates to support hardware changes
  • Fixed up FPGA GPIO expander driver (tsgpio) to be more generic and support multiple modes
  • Set up pwm-clk driver to run PWM to FPGA for FPGA clock
  • Set up default VLAN mode for ethernet switch
  • Added netfilter modules to defconfig
  • Patch in proper support for mmc name aliasing
  • Pull cmdline from U-Boot, and fallback to kernel built-in
  • Switch starts up in switch mode, should default to VLAN
  • Both VLAN ports use the same MAC
  • Deprecated, we strongly recommend against using this image
ts7680-sep222015.dd.bz2
  • Patch in proper support for mmc name aliasing
  • Pull cmdline from U-Boot, and fallback to kernel built-in
  • Both VLAN ports use the same MAC
  • Deprecated, we strongly recommend against using this image
ts7680-nov192015.dd.bz2

ts7680-nov192015.tar.bz2

  • Changeover to Debian Jessie
  • Removed dependency on initramfs
  • Simplified and separated out functions in tshwctl
  • Added WDT kernel driver to support WDT in microcontroller
  • Enable UART4
  • Disable restart of PWM core on linux start
  • Switch VLAN mode can be configured via kernel command line
  • MAC addresses for VLAN mode are completely random
  • Short VLAN frames when the switch is in VLAN mode do not properly get passed through
ts7680-apr012016.dd.bz2

ts7680-apr012016.tar.bz2

  • VLAN MAC addresses are now correct TS assigned MAC addresses
  • Added tssupercapmon script and systemd service. Automatically shut down system safely if power is removed
  • Added DAC commands
  • Added tsmicroctl tool to image
  • /etc/shadow is world readable
  • Short VLAN frames when the switch is in VLAN mode do not properly get passed through
  • GPIO driver via linux sysfs has race condition when changing state and direction at the same time
ts7680-sep252018.dd.bz2

ts7680-sep252018.tar.bz2

  • Proper permissions set on /etc/shadow
  • Added support for MMA8451 accelerometer
  • Added support for FTDI and CP210x USB serial adapters
  • Add support for any future eMMC revision changes
  • GPIO driver via linux sysfs has race condition when changing state and direction at the same time (intentionally not updated for this release, may cause unexpected behavior change of stock image)
  • Short VLAN frames when the switch is in VLAN mode do not properly get passed through (intentionally not updated for this release, may cause unexpected behavior change of stock image)


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.

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.