TS-7680
 | |
| Product Page | |
| Product Images | |
| Specifications | |
| Documentation | |
|---|---|
| Schematic | |
| Mechanical Drawing | |
| FTP Path | |
| Processor | |
| NXP i.MX286 | |
| 454 MHz Arm®v5TE Arm9™26EJ-S | |
| i.MX286 Product Page | |
| CPU Reference Manual |
Overview
The TS-7680 has been officially released in April 2016. This is a small embedded board with an NXP i.MX286 454 Mhz ARM9 CPU with 128-256MB DDR2.
Getting Started
A Linux workstation is recommended and assumed for development using this documentation. For users in Windows or OSX, we recommend virtualizing Linux. Most of our platforms run Debian, which is recommended for ease of use if there is no personal distribution preference.
Virtualization
Suggested Linux Distributions
Development using a Windows or OSX system may be possible but is not supported. Development will include accessing drives formatted for Linux and often Linux-based tools.
Get a Console
Serial Console
The TS-7680 includes a USB device port, this uses an 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.
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.
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. |
The TS-7680 has an input voltage range of 8 to 40 VDC or 10 to 28 VAC through the main power connector which offers screw terminals for secure wiring. See the CN5 Power connector for pinout information. 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.
Power can additionally be supplied via 802.3af/at PoE when using the TS-DC767-POE accessory. This turns the first ethernet jack, T1, in to a 802.3af/at compliant PoE powered device connection to power the whole TS-7680. The TS-DC767-POE regulates this input power to 13 VDC, and feeds that back in to VIN via the HD1 daughter card pin header.
Once power has been applied, the whole system will begin to boot up and output information on the serial console. A normal bootup will look similar to the following:
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 **
** File not found /boot/ts7680-fpga.vme **
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 ...
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:
| 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 from the U-Boot shell, this will save the environment to disk, and this message will go away unless there is a further issue. |
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.
First Linux Boot
When booting with the default settings, a shipped device will boot to the eMMC or SD card depending on the "SD" jumper. The eMMC and any purchased SD cards by default are pre-programmed with our default Debian 8 Jessie image. After Debian boots it will ask the user to log in with a username and password. This uses "root" as the username with no password. This can be changed after logging in with the command 'passwd' to set an account password. Note that this login will only work over the serial console. Debian SSH defaults to disallowing password-less logins.
From the Linux prompt, the hardware can be tested out or application development can be begin.
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 ...
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
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
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.
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
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.
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).
Update U-Boot
| WARNING: | Installing your own u-boot is not recommended and may cause the board to fail to boot. |
The latest U-Boot binary can be downloaded from the TS-7680 FTP site. Copy this file to /boot/u-boot.sb on the 2nd partition of the SD card. The SPI flash can be updated by inserting that SD card in to the TS-7680, setting the U-Boot and SD card jumpers, and powering up the unit. At the U-Boot prompt, the following command can be used:
run update-uboot
The above script will use the /boot/u-boot.sb file from the SD card or eMMC, depending on the state of the SD Boot jumper.
U-Boot Development
We do provide our u-boot sources, but we do not recommend rebuilding a custom uboot if it can be avoided. If you still want to proceed with building a custom u-boot, use the master branch from the github here: https://github.com/embeddedTS/u-boot
Set the PATH variable to include the cross compiler used for the TS-7680. The U-Boot binary can be built with the following:
./build-mx28 ts7680
This will output a u-boot.sb file you can use to write the SPI flash as listed in the Update U-Boot section
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.
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:
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
Host a 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
channel=7
driver=nl80211
logger_stdout=-1
logger_stdout_level=2
wpa=2
wpa_key_mgmt=WPA-PSK
| 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, modify the hostapd configuration to understand the bridge interface:
echo "bridge=br0" >> /etc/hostapd/hostapd.conf
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
Additionally, it is strongly recommended on this platform to install haveged, a tool for increasing system entropy. The increased system entropy will allow for WPA2 connections to establish quicker:
apt-get update && apt-get install haveged -y
Cellular Data Network
The TS-7680 includes support for Multitech SocketModems (we've specifically tested MTSMC-G2 and MTSMC-H5, but most modules should be compatible) which can connect to the internet using pppd. The modem is attached to the HD1 Header, also called the Daughter Card interface. This interface does not by default have any UART attached to it, see the Crossbar section for more information on setting this up. Using the example in the Crossbar section, the UART is set up to UART 4, the modem itself can be configured with the following command:
ln -s /dev/ttyAPP4 /dev/ttymultidc
Additionally, the DIO pin that connects to the RTS pin of the modem needs to be set to an output and driven low in order to allow communication with the modem:
echo "40" > /sys/class/gpio/export
echo "out" > /sys/class/gpio/gpio40/direction
echo "0" > /sys/class/gpio/gpio40/value
The pppd application must be installed and any required modules loaded:
apt-get update && apt-get install -y ppp
This example is configured for T-Mobile in the US:
/etc/ppp/peers/tmobile
/dev/ttymultidc noauth 115200 debug usepeerdns persist defaultroute connect "/usr/sbin/chat -v -f /etc/ppp/chatscripts/tmobile" disconnect "/usr/sbin/chat -v -f /etc/ppp/chatscripts/tmobile-disconnect"
/etc/ppp/chatscripts/tmobile
TIMEOUT 10 ABORT 'BUSY' ABORT 'NO ANSWER' ABORT 'ERROR' "" "\p\p\p\p\p\p\p\p\p\p\p\p+++\p\p\p\p\p\p\p\p\p\p\p\p" "" "ATH0" "OK" 'AT+CGDCONT=1,"IP","wap.voicestream.com"' ABORT 'NO CARRIER' OK 'ATD*99***1#' CONNECT
/etc/ppp/chatscripts/tmobile-disconnect
"" "\K" "" "+++ATH0"
Using a different carrier you will likely only need to replace wap.voicestream.com with the access point for your carrier.
To start pppd:
pppd call tmobile
# Or for more logging information:
# pppd nodetach call tmobile
This will create a ppp0 interface that can now be used as a standard network interface, and should set up a default route to the internet. For other carriers, typically you will only need a different access point listed in the AT+CGDCONT call, but further adjustments may be necessary.
| Note: | We have observed that the MTSMC-H5 connected to some networks has issues at or below 115200 baud. The issues observed are connection timeouts with the network itself. The connection between the modem and host device remain rock solid. While many applications are tolerant to the connection being reset, we have found some network downloads will abort without being able to recover. Running the unit at a faster baud rate, 230400 or higher, has been observed to eliminate this issue entirely. This does mean, however, that every time the device is started up, the modem must be issued an AT+IPR command (as noted below) at 115200 baud, then pppd started with the matched and higher baud rate in the peer script as shown above. |
Faster Data Rates
While the MTSMC-G2 (GPRS) is limited to 115200 baud, the MTSMC-H5 (HDSPA) can communicate over serial up to 921600 allowing actual transfer rates around 80-90KB/s.
To set a custom baudrate in Linux, the method depends on the CPU and kernel support. More recent UART peripherals have a higher clock and a smarter driver, and can therefore use custom baud rates inherently. However, some systems require the use of 'setserial' using the spd_cust flag and some manual settings. When the spd_cust baud rate is set, Linux will re-purpose 38400 baud to use the set custom baud rate.
First, test the unit to see if it is possible to open up the UART with a higher baud rate:
picocom -b 921600 /dev/ttymultidc
If the higher baud is unsupported, picocom will return a failure similar to the following:
FATAL: failed to add device /dev/ttymultidc: Invalid baud rate
If the above error is received, then the method below using setserial must be used.
Otherwise, the port can be closed, re-opened at 115200 baud to communicate with the modem, and then the following command can be used to tell the cell modem to enter a higher baud rate:
AT+IPR=921600
Now the port can be closed everything will function at the higher baud rate. Be sure to update the providers file. Using the example T-Mobile configuration, edit /etc/ppp/peers/tmobile and change 115200 to 38400. Starting pppd will now allow communication around 80-90KB/s (depending on your local cell tower's availability).
| Divisor | Rate |
|---|---|
| 1 | 921600 |
| 2 | 460800 |
| 3 | 307200 |
| 4 | 230400 |
| 5 | 184320 |
| 6 | 153600 |
| 7 | 131657 |
| 8 | 115200 |
Larger divisors will also work, but this should cover the common range. Using the setserial command you can specify the divisor. For example, to reach 115200 with the alternative baud base:
setserial /dev/ttymultidc spd_cust baud_base 921600 divisor 8
Next you will need to tell the modem to communicate at the faster baud rates. You can use a client like picocom or minicom to connect directly to the modem to send it commands.
picocom -b 38400 /dev/ttymultidc
Even though we are talking at 115200, 38400 must be specified since we are using a custom baud_base. You can test communication with the modem again by typing "AT", pressing enter, and receiving "OK". To reconfigure the modem to the faster 921600 baud rate you can send it this command:
AT+IPR=921600
This will respond with OK, but now you will need to quit out of picocom (ctrl a,x) and reconfigure the baud base to use divisor 1:
setserial /dev/ttymultidc spd_cust baud_base 921600 divisor 1
The only change now needed is in your providers file. Using the example T-Mobile configuration , edit /etc/ppp/peers/tmobile and change 115200 to 38400. Starting pppd will now allow communication around 80-90KB/s (depending on your local cell tower's availability).
Troubleshooting
If you are not able to obtain a ppp connection there are a few values you can check:
Troubleshooting: Cell Signal
Make sure ppp is not running, and execute these commands to check the signal strength.
stty raw -echo speed 115200 -F /dev/ttymultidc
cat /dev/ttymultidc &
echo -e "AT+CSQ\r\n" > /dev/ttymultidc
killall cat
The return value should be something like "+CSQ: 9,2", or with no connection, +CSQ: 99,99. The second argument is the signal strengh which follows this table:
| 0 | -113 dBm or less |
| 1 | -111 dBm |
| 2 to 30 | -109 to -53dBm |
| 31 | -51dBm or greater |
| 99 | not known or detectable |
If you return 99, make sure the antenna is connected and that you are in an area with good signal from your provider. Even without a valid SIM card you can have a good connection. If you are in another country, you may need to adjust the band for those supported by your carrier. The default value is appropriate for most US based carriers. Refer to the +WMBS command in your AT command guide for more options.
Troubleshooting: SIM card
If you have a good signal strength but are not obtaining a connection you can verify that the modem is able to read the subscriber number. This proves your SIM card is valid.
stty raw -echo speed 115200 -F /dev/ttymultidc
cat /dev/ttymultidc &
echo -e "AT+CNUM\r\n" > /dev/ttymultidc
killall cat
With a valid SIM this will return something like:
+CNUM: "","12345678901",129
If the SIM not detected you will only read ERROR. Make sure in this case that the card is inserted in the right direction so the pads on the card line up with the socket.
Troubleshooting: Other Options
If neither of the above steps get you connected you may want to contact your service provider for more information about where your connection attempts are failing.
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.
Older Debian releases are moved to a different server to indicate it is no longer getting security updates. To download packages for these older distributions, edit /etc/apt/sources.list to only have the following lines:
Jessie:
deb http://archive.debian.org/debian/ jessie main deb-src http://archive.debian.org/debian/ jessie main
Wheezy:
deb http://archive.debian.org/debian/ wheezy main deb-src http://archive.debian.org/debian/ wheezy main
After modifying that file, be sure to update the package list:
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.
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. |
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.
Backup / Restore
microSD Card
|
Click to download the latest 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. embeddedTS 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. embeddedTS 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.embeddedTS.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.embeddedTS.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
eMMC
The following instructions can be used to restore the eMMC with one of our filesystems, or to update the disk with a custom filesystem in a production type scenario. The instructions as they are below will write our stock image to the device, while booted from a stock SD card by default. However, there are comments to provide guidance on writing our 4.9 Linux kernel with Debian Stretch image, and/or if the device is booted from an SD card already formatted with our 4.9 Linux kernel with Debian Stretch image.
The TS-7680 supports a port of Linux 4.9.y using Debian Stretch. When moving to this, it is recommended to do a complete rewrite of the boot media rather than an upgrade to ensure complete compatibility. Please take a look at the Caveats of using Linux 4.9 before proceeding in using this image.
Partition table
| Note: | It is generally not required to re-create the partition table since it already exists on our stock units. 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 4.9 Linux kernel 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
# Remove, and re-set the partition table
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.
Filesystem
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.embeddedTS.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 https://files.embeddedTS.com/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
Creating A Production Image
It is usually desired to create a golden image to use for unit production after development is complete. This process can vary greatly from application to application but there are a few steps that are going to be most often wanted. These include cleaning up temporary files, removing files that should be unique and re-generated on the first boot (SSH keys, machine-id files, etc.), setting up the hostname, and so on. We have created a script that will automate most of this process and provides hooks for additional scripts to be called as well. The script is simply passed the device node of the development disk or an existing .dd file. From this, it will create a new .dd file based on the partition scheme with all modifications made to the new image. The image source is left completely untouched and is read only. The script also assumes that the last partition on the disk is the bootable linux partition. If this is not the case or there are multiple partitions that are used in the end application, the script will need to be modified in order to accommodate this fact.
| Note: | The script uses output from various commands. The output format of linux utilities can vary greatly from distribution to distribution, or even within versions of the distribution. It is strongly recommended to verify the final processed image contains everything necessary for the application and that all processes completed without issue. |
The simplest use of the script is:
./prep_customer_image /dev/sdX <output base name>
Note that "/dev/sdX" will need to be changed accordingly. Be sure to pass the whole disk and not just a partition.
The "<output base name>" is used as the base for all files output. For example, if "TechnologicSystems-latest" was used, then the compressed tarball output would be named "TechnologicSystems-latest.tar.bz2" (or it may end with ".tar.xz" depending on the compression used by the script). If no base name is provided, then the current date is used.
Additionally, there are two hooks available in the 'prep_customer_image' script, "prep" and "post". The top of the file has two variables, `PREP_SCRIPTS=""` and `POST_SCRIPTS=""`. Adding in a space separated list of script names to those variables will cause them to be called in order. For example, setting `PREP_SCRIPTS="add_application change_hostname"` will cause the 'prep_customer_image' script to run through its initial steps, then call './add_application', then call './change_hostname', and then will continue with the rest of the script steps.
Every script for "prep" and "post" is called with a single argument, the name of the image file. This specifically will be "<output base name>.dd". At the time of calling the prep scripts, the folder "./mount_point/" will have the last partition of the image file mounted as read/write. It is not wise to modify the image file directly since it is already mounted. All of the post scripts are called after the last partition of the image file is unmounted. This can be useful for creating additional file outputs, extracting specific partition images, etc., from the image itself. We have used these hooks in the past to remove special files and create additional images for our DoubleStore based devices.
It is also possible to run this script directly on the device when booted. This can be used to take an image of eMMC for example, when booted from the SD card. We always recommend doing initial development on SD, creating an image from that on a host PC, and then transferring it to the eMMC. This process makes development and image creation faster. If using the 'prep_customer_image' script from a booted device, be sure there is enough free space as the script creates a disk image of the target disk and then copies that in to a tarball, compressing everything as the final step.
The "prep_customer_image" script can be found in the TS-7680 utilities github.
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.
Cross Compiling
Debian Jessie previously provided cross compilers via the Emdebian project. However, Emdebian has been unmaintained for a number of years and is no longer able to provide a viable install package. In order to cross compile from a Debian Jessie workstation, a third party cross compiler is required.
A Debian Jessie install on a workstation has the ability to build for the same release on other architectures using Debian binary libraries. A PC, virtual machine, or chroot will need to be used for this. Install Debian Jessie for your workstation here.
From a Debian workstation (not the target), run the following commands to set up the cross compiler. Note that this expects a 64-bit Debian Jessie install on the workstation. 32-bit installations are not supported at this time.
# Run "lsb_release -a" and verify Debian 8.X is returned. These instructions are not
# expected to work on any other version or distribution.
cd ~
wget http://ftp.embeddedTS.com/ftp/ts-arm-sbc/ts-7680-linux/cross-toolchains/gcc-linaro-4.9-2016.02-x86_64_arm-linux-gnueabi.tar.xz
# The above toolchain is from Linaro. Other cross compilers can be used but have not been tested.
mkdir cross_compiler
tar xvf gcc-linaro-4.9-2016.02-x86_64_arm-linux-gnueabi.tar.xz -C ~/cross_compiler
export PATH=$PATH:~/cross_compiler/gcc-linaro-4.9-2016.02-x86_64_arm-linux-gnueabi/bin/
# The 'export' command needs to be run every time the user logs in. It is possible to add this command to the user's ".bashrc" file
# in their home directory to ensure it is automatically run every time the user is logged in.
su root
dpkg --add-architecture armel
apt-get update
apt-get install build-essential
This will install a toolchain that can be used with the prefix "arm-linux-gnueabi-". All of the standard GCC tools will start with that name, eg "arm-linux-gnueabi-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-gnueabi-gcc hello-world.c -o hello-world
file hello-world
This will return that the binary created is for ARM. Copy this to the target platform to run it there.
Debian Jessie supports multiarch which can install packages designed for other architectures. On workstations this is how 32-bit and 64-bit support is provided. This can also be used to install armel packages on an x86 based workstation.
This cross compile environment can link to a shared library from the Debian root. The package would be installed in Debian on the workstation to provide headers and ".so" files. 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. Note that since the cross compiler used is 3rd party and not directly from Debian, some compile commands that include libraries will need additional arguments to tell the compiler and linker where on the workstation to find the necessary headers and libraries. Usually, the additional arguments will look like the following string, however adjustments may need to be made depending on the application.
-I/usr/include -L/usr/lib/arm-linux-gnueabi -L/lib/arm-linux-gnueabi -Wl,-rpath=/usr/lib/arm-linux-gnueabi,-rpath=/lib/arm-linux-gnueabi
apt-get install libcurl4-openssl-dev:armel
# 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 just as compiling on the unit.
arm-linux-gnueabi-gcc -I/usr/include -L/usr/lib/arm-linux-gnueabi -L/lib/arm-linux-gnueabi -Wl,-rpath=/usr/lib/arm-linux-gnueabi,-rpath=/lib/arm-linux-gnueabi simple.c -o simple -lcurl
The binary can now be copied over to the target platform and executed using the curl library that will be loaded at runtime from the target.
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 Stretch Cross Compilation
| Note: | This section only applies when using Linux 4.9.y with Debian Stretch based images. |
Debian Stretch provides cross compilers from its distribution. 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 under "Release". These instructions are not
# expected to work on any other version or distribution.
lsb_release -a
su root
# Not needed for the immediate apt-get install, but used
# so we can install package:armel for cross compiling
dpkg --add-architecture armel
apt-get update
apt-get install curl build-essential crossbuild-essential-armel -y
This will install a toolchain that can be used with the prefix "arm-linux-gnueabi-". The standard GCC tools will start with that name, eg "arm-linux-gnueabi-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-gnueabi-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 armel 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:armel
# 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-gnueabi-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.
It is also possible to run binaries that are cross compiled for ARM. 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
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.embeddedTS.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/embeddedTS/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
Linux 4.9.y
| Note: | The 4.9.y kernel is intended to be used with the Rev C PCB. No testing was done with previous PCB revisions. |
Linux 4.9 is an LTS kernel release that will be maintained by the linux community until 2023, including back-porting of security patches. Along with an update to 4.9, the TS-7680 has also received a port of Debian Stretch. This means the TS-7680 is an ideal candidate for current applications that need the latest security patches applied.
The TS-7680 4.9 kernel is pulled directly from the main vanilla kernel git (https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git), has minor patches applied to support the TS-7680, and is maintained on our public github. This platform uses the ts_imx28_defconfig.
The filesystem is a minimal build of Debian Stretch with a handful of changes to ensure complete compatibility with the TS-7680. The utilities we install can be found in our TS-7680 utilities github repo.
Bootable images and distribution tarballs can be downloaded here. Instructions for writing the image to SD card can be found here. Booting from eMMC requires a more complex process which can be found here. This process can be automated with USB update scripting from U-Boot.
Caveats
While we have attempted to maintain backwards compatibility as much as possible, many of the APIs have changed or kernel support has been added to various drivers that we now recommend over direct memory manipulation.
- LEDs are under kernel control, via /sys/class/leds/ interface. See kernel documentation for information on controlling the LEDs.
- eMMC is now attached as "/dev/mmcblk1" This causes an issue with the stock U-Boot and booting to eMMC. The kernel cmdline from U-Boot passed mmbclk2 as the eMMC device. Due to this, a script has been added to the filesystem at "/boot/boot.ub". This is a U-Boot script that is parsed on every boot, if the SD Boot jumper is not set, then the script will set the correct device node in the cmdline. See the modify Linux kernel cmdline section for more details about how this script is set up.
- Accelerometer is supported by the kernel IIO subsystem. It appears as various files in "/sys/bus/iio/devices/iio\:device0/".
- The 20190220 image is unable to be booted from a USB mass storage device. In order to properly boot from USB, the USB mass storage device needs to have a kernel built from sources after September 2019. Git commit 13c56f64fe adds USB controller controller as a built-in rather than a module.
Kernel Compilation
Compiling the kernel requires an armel toolchain. We recommend development using Debian Stretch workstation which includes an armel compiler in the repositories. See the Debian Stretch cross compile section for instructions on installing the 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-gnueabi-
export LOADADDR=0x40008000
# This sets up the default configuration that we ship with
make ts_imx28_defconfig
## Make any changes in "make menuconfig" or driver modifications, then compile
make && make uImage
To install the kernel and modules to an SD card, attach it to the PC and assuming the the SD card shows up as /dev/sdc, run the following:
export DEV=/dev/sdc2
sudo mount "$DEV" /mnt/sd
sudo rm /mnt/sd/boot/uImage
sudo cp arch/arm/boot/uImage /mnt/sd/boot/uImage
sudo cp arch/arm/boot/dts/imx28*ts*.dtb /mnt/sd/boot/
INSTALL_MOD_PATH="/mnt/sd" sudo -E make modules_install
sudo -E make headers_install INSTALL_HDR_PATH="/mnt/sd/usr"
sudo umount /mnt/sd/
sync
Creating Custom Images
We have created a script that will take a source disk or image and output an image that has been sanitized for use across multiple units. This includes removing host SSH keys and other temporary or unique files.
| Note: | We strongly recommend reading the script carefully before use. All images produced by the script should be checked before being released. Technologic Systems assumes no responsibility for the end use of this script. |
The script is available from the TS-7680 utilities github. It is 'scripts/prep_customer_image' and can be run on a host linux PC with:
./prep_customer_image /dev/<whole SD device node> <imagename>
This will output .dd.bz2, .dd.md5, .dd.bz2.md5, .tar.bz2, and .tar.bz2.md5 files that can be written to SD card or eMMC.
Features
Accelerometer
| Note: | The current shipping image, Apr012016 does not have support for the accelerometer. In order to add support the kernel must be compiled from the latest sources from github. Support for the accelerometer will be standard in all future image releases. |
This SBC contains an NXP MMA8451 3-axis accelerometer. It is connected to the kernel as an input device and can be accessed through the input event layers. The kernel driver is only polling and the accelerometer's IRQs are not supported. The accelerometer supports a ±2, ±4, and ±8 g dynamically selectable scale.
On a stock system with no other peripherals attached, the accelerometer will show up as
/dev/input/event0
If other peripherals, such as mice, keyboards, or other HID devices are attached at boot, then this device may change.
In order to read from the accelerometer it must first be enabled:
echo 1 > /sys/devices/virtual/input/input0/enable
The scale mode can be changed by writing a 0 (±2 g), 1 (±4 g), or 2 (±8 g) to the scalemode sys file:
#Set the scale mode to 8 g
echo 2 > /sys/devices/virtual/input/input0/scalemode
Note that the input0 above may change if other input devices are present in the system.
From here, a tool such as 'evtest' can be installed and run to verify output:
apt-get update
apt-get install evtest
evtest /dev/input/event0
The 'evtest' command will have output similar to the following:
Event: time 1466445467.909559, -------------- EV_SYN ------------ Event: time 1466445468.029557, type 3 (EV_ABS), code 0 (ABS_X), value -123 Event: time 1466445468.029557, type 3 (EV_ABS), code 1 (ABS_Y), value -35 Event: time 1466445468.029557, type 3 (EV_ABS), code 2 (ABS_Z), value 16294 Event: time 1466445468.029557, -------------- EV_SYN ------------ Event: time 1466445468.149557, type 3 (EV_ABS), code 1 (ABS_Y), value -17 Event: time 1466445468.149557, type 3 (EV_ABS), code 2 (ABS_Z), value 16224 Event: time 1466445468.149557, -------------- EV_SYN ------------ Event: time 1466445468.269598, type 3 (EV_ABS), code 0 (ABS_X), value -149 Event: time 1466445468.269598, -------------- EV_SYN ------------ Event: time 1466445468.389560, type 3 (EV_ABS), code 1 (ABS_Y), value -48 Event: time 1466445468.389560, type 3 (EV_ABS), code 2 (ABS_Z), value 16416
Readings from the accelerometer are read from the kernel input event interface. The linux documentation for the input system as well as event types are the best resource for creating an application to read from the device:
https://www.kernel.org/doc/Documentation/input/input.txt
https://www.kernel.org/doc/Documentation/input/event-codes.txt
Additionally, the Openmoko documentation has a great breakdown of the input event data:
http://wiki.openmoko.org/wiki/Accelerometer_data_retrieval#Data_structure
ADC
CPU
There are 4 Analog to Digital inputs on the TS-7680 made available on the internal header as well as the 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 12-bit ADC, with a 1.3% absolute error, using an internally generated 1.85 V reference, separate channels for single cycle acquisition of multiple inputs, and a maximum sample rate of 428 kHz. Each channel has a voltage divider allowing for 0-10 V input at the screw terminals and internal pin header, and each pair of channels can be put in to 4-20 mA measurement mode via the current loop enable GPIO.
Sample code to read the ADCs is provided by Technologic Systems, see mx28adcctl.c in the TS-7680 utilities sources. 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. Additionally, the sample code provides example math for converting the readings in to actual voltage or current readings.
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 |
Current Loops
The LRADC channels can be used as a current loop sensor for 4-20 mA input. Current loops are enabled in channel pairs; LRADC_ADC0 and LRADC_ADC1 have a single enable, LRADC_ADC2 and LRADC_ADC3 have a single enable. When the current loops are enabled, each channel has a 240 ohm load resistor for measurement. The sample code mx28adcctl.c in the TS-7680 utilities sources contains math for calculating the current input in uA units.
Linux GPIOs to enable current loops on ADC channels
| ADC Channel | GPIO |
|---|---|
| LRADC_ADC0 | 231 |
| LRADC_ADC1 | |
| LRADC_ADC2 | 232 |
| LRADC_ADC3 |
Pull-ups
The LRADC channels have a pull-up that can be enabled to bias the input line. Each pull-up is to 3.3 V and is run through a Schottky diode to prevent input voltage from feeding back in to the 3.3 V rail. The pull-up enables for each channel are active low.
| Note: | FPGA revision 0x9 and lower have the pull-ups enabled by default. See the FPGA Programming section for information on updating to the latest FPGA revision |
Linux GPIOs (active low) to enable pull-up resistors on ADC channels
| ADC Channel | GPIO |
|---|---|
| LRADC_ADC0 | 227 |
| LRADC_ADC1 | 228 |
| LRADC_ADC2 | 229 |
| LRADC_ADC3 | 230 |
Microcontroller
The on-board microcontroller has 11 ADC channels that are used to monitor internal voltages. The internal ADC is a single-ended unipolar 10bit ADC with a 2.5 V full scale reference. The inputs can be queried with a call to tsmicroctl:
tsmicroctl -i
P1_2=0x3da
P1_3=0x3da
P1_4=0x3a8
P2_0=0x145
P2_1=0x3ab
P2_2=0x2ad
P2_3=0x2ed
P2_4=0x26c
P2_5=0x3d9
P2_6=0x2e7
P2_7=0x2b8
The PX_Y output are the various ADC channels, their inputs are the following:
| Channel | Input source | Scale |
|---|---|---|
| P1_2 | Super Cap balance output[1] | 100% |
| P1_3 | Super Cap tot. voltage[2] | 50% |
| P1_4 | Super Cap pre-boost voltage[3] | 44.6% |
| P2_0 | VIN | 5.57% |
| P2_1 | 5 V Boost regulator output | 44.6% |
| P2_2 | Aux. 3.3 V | 50% |
| P2_3 | CPU 1.8 V | 100% |
| P2_4 | CPU Core 1.5 V | 100% |
| P2_5 | Super Cap charging voltage | 50% |
| P2_6 | RAM 1.8 V | 100% |
| P2_7 | CPU 3.3 V | 50% |
BACnet
The TS-7680 was designed with BACnet support in mind; including multiple ethernet ports, RS-485 support, and 24 V AC/DC operation. BACnet communication is provided by a software layer, using the BACnet Stack project. Technologic Systems does not offer any customized APIs, and instead, highly recommends the BACnet Stack project for BACnet support.
We have created a brief introduction to BACnet, as well as a real world example using BACnet Stack, it can be found here.
Battery Backed RTC
The TS-7680 implements a M41T00S STMicro Battery Backed RTC using an external and replaceable coin cell battery. This RTC is connected to the CPU via I2C and is handled by the kernel and is presented as a standard RTC device in linux.
Bluetooth
The Wi-Fi option for this platform also includes a Bluetooth 2.1+EDR and Bluetooth 4.0 LE radio. 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.
To connect this to the system 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:XX:XX:XX BlackBerry 8530
Please note that the Bluetooth module requires the modem control lines CTS and RTS as flow control.
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.
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 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.
DAC
There are four 0-10 V DAC ports on the TS-7680. These DACs can be controlled via a PWM which passes through a low pass filter. The FPGA syscon contains a 12-bit register (accessible as two 8-bit registers) for each DAC channel.
| Note: | For full 0-10 V output, a minimum input voltage of 13 V is required. The max DAC output voltage settles at about 11.4 V, and this happens at 15 V input voltage. Anything less than 15 V input will have a lower maximum output voltage which will require different calculations to convert the desired output voltage to a PWM value. |
With a minimum 15 V input voltage, the PWM value can be determined within 5% accuracy with the following:
PWMval=(Vdesired*360)
Once PWMval is determined, this value can be plugged in to the appropriate switches for tshwctl:
tshwctl --dac0 PWMval
tshwctl --dac1 PWMval
tshwctl --dac2 PWMval
tshwctl --dac3 PWMval
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 |
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 "0" or non-zero value. 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
| Note: | As an input, the value file will read as a "0" when the input is low, and a non-zero value when the input is high. |
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, note that DIO 39, 40, and 41 do NOT have internal pullups and instead have internal keeper functions from the i.MX28 CPU. It is also possible to use CPU GPIO (any DIO lower than DIO 192) 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 [1] |
| 52 | Input | Push Switch |
| 59 | Enable 5 V | En. 5 V on USB host |
| 73 | Power fail | N/A |
| 125 | DIO | HD4_21 |
| 126 | En.# CAN | N/A |
| 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[2] |
| 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 1 | N/A |
| 211 | Enable relay 2 | N/A |
| 233 | Enable 5V | En. 5 V on HD1_15 / HD1_16 |
| 237 | Enable BT | N/A |
LS Output
There are three Low-Side outputs that can sink up to 500 mA at 30 VDC. The output can be asserted via the linux GPIO interface.
When the output is deasserted, the pin can be read as a DIO. Voltages about 1.3 V or lower are read as a logic 0, while anything higher (or the pin is left floating) will register as a logic 1. Due to the nature of the LS outputs, the input value is not attainable through the Linux GPIO system, and an FPGA register needs to be read directly. See the Syscon section for more information. The relevant register for the read data is register 0xE.
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 |
This platform includes a Micron eMMC module with builds that have "4096F" in the part number. Our off the shelf builds are 4GiB, but up to 64GiB are available for larger builds. The eMMC flash appears to Linux as an SD card at /dev/mmcblk2. Our default programming of the eMMC is the same as the SD card image.
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" mode. With both of these enabled then any writes will be atomic to 512B. If a sector is being written during a power loss, a block is guaranteed to have either the old or new data. Even in cases where the wrong data is present on the next boot, fsck is able to deal with the older data being present in a 512B block. The downsides to setting these modes are that it will reduce the overall write speed and halve the available space on the eMMC to roughly 1.759GiB.
The mmc-utils package is used to enable these modes.
| WARNING: | THESE COMMANDS WILL ERASE THE EMMC MEDIA. |
| WARNING: | If you are using a custom built TS-7680 with an eMMC sized larger than 4GB, contact us before using these commands. The SLC partition will be specified different on larger disks. |
MAX_ENH_SIZE=$(mmc extcsd read /dev/mmcblk2 | grep "\\[MAX_ENH_SIZE_MULT\\]" -A 1 | sed -n '2p' | cut -f 3 -d ' ')
mmc write_reliability set -n 0 /dev/mmcblk2
mmc enh_area set -y 0 "$MAX_ENH_SIZE" /dev/mmcblk2
| WARNING: | Setting either of those modes is permanent and using the wrong value it is possible to essentially brick eMMC which will not be covered by the warranty. Evaluation units with fuses set will not be accepted through returns. |
After this is run, reboot the unit. On all future boots the eMMC will be detected at the smaller size.
This can be applied automatically from a bash script:
#!/bin/bash
mmc extcsd read /dev/mmcblk2 > /tmp/csd
PART_DONE=$(grep PARTITION_SETTING_COMPLETED < /tmp/csd | cut -f 2 -d ':' | tr -d '[:space:]')
if [ "$PART_DONE" == "0x00" ]; then
WR_REL_SET=$(grep "\\[WR_REL_SET\\]" < /tmp/csd | cut -f 2 -d ':' | tr -d '[:space:]')
MAX_ENH_SIZE=$(grep "\\[MAX_ENH_SIZE_MULT\\]" < /tmp/csd -A 1 | sed -n '2p' | cut -f 3 -d ' ')
# Some eMMC devices ship with this enabled already
if [ "$WR_REL_SET" == "0x00" ]; then
mmc write_reliability set -n 0 /dev/mmcblk2
fi
mmc enh_area set -y 0 "$MAX_ENH_SIZE" /dev/mmcblk2
# This requires a power cycle on the eMMC for these settings.
reboot
else
echo "Paritioning is completed!"
exit 0
fi
External Reset
| Note: | Use caution when using the push switch as a hardware reset mechanism. Filesystem corruption can occur if proper precautions are not taken and a hardware reset occurs. |
This SBC has a multi-purpose tactile button at a right angle to the PCB. This button can be used as a mechanism to issue a hardware reset to the SBC or as a way to wake up the device from its sleep modes (see Sleep for more information). Additionally, it can be set up as a generic input for user applications.
To enable or disable the hardware reset functionality:
tsmicroctl --resetswitchon #Enable hardware reset
tsmicroctl --resetswitchoff #Disable hardware reset
To read the state of the input pin, see the DIO section for information on reading the Push Switch.
Ethernet
The i.MX28 processor implements a 10/100 ethernet controller with support built into the Linux kernel. The TS-7680 includes an integrated Marvell Ethernet switch that allows multiple interfaces from one 10/100 port. This allows a total bandwidth of 100MB/s between both ports.
|
Switch
The default shipping configuration of the Marvell switch is to be in switch mode. This mode uses a single linux device, eth0, and the two ethernet jacks will transparently pass packets as a normal layer 2 ethernet switch.
VLAN
Additionally, the Ethernet switch can have VLANs configured, one for each physical port. In this mode, linux will create eth0.1 and eth0.2 ports that are the actual VLAN ports. Routing and bridging can be set up on these ports as well if needed. DHCP clients are run on both of the ports by default. A number of systemd scripts are also implemented to correctly handle this mode. This includes systemd-network configuration to create and set up the VLAN ports, as well as a script to parse the eth0 MAC address, and set the eth0.1 and eth0.2 MAC addresses based on that address. In this mode, eth0 is not a valid interface port, only eth0.1 and eth0.2 ports are valid, however eth0 must remain up and active for proper operation.
To enable the VLAN mode, a change must be made to the kernel command line, add the switch tsvlan to it. The easiest way to do this is through U-Boot scripting:
env set cmdline_append rw rootwait console=ttyAMA0,115200 loglevel=3 tsvlan
# Note, if in the U-Boot shell, 'env save' can be run after the above command to save the updated cmdline to U-Boot to use on all future boots
| Note: | As of the Sept. 18, 2018 release of U-Boot, switching to VLAN mode only happens once the kernel is booted. This leaves some time of the switch IC in its standard switch mode before Linux can configure it. As this may not be safe for some applications, we've released an updated U-Boot that can address this by disabling a single Ethernet port until Linux configures the VLAN settings. At this time, there are no plans to push this update in to production. See this page for information on updating U-Boot and enabling this mode to disable a single port until Linux boots. |
Link status
The Marvell switch does not have a Linux driver associated with it. Due to this, all of the configuration is handled from a userspace tool, 'switchctl'. Because there is no proper driver, there is no way through the Linux standard tools to query the actual link status of each port. The 'switchctl' application can be used to do this:
switchctl --ethinfo
switch_model=88E6020
switch_ports="a b"
switchporta_link=1
switchporta_speed=100FD
switchportb_link=0
switchportb_speed=10HD
vtu_total=0
802.3af PoE PD
When coupled with the optional TS-DC767-POE daughter card (available on the "Order" page for the TS-7680) the TS-7680 is an 802.3af compliant PD (powered device). With the TS-DC767-POE installed, the T1 Ethernet jack is able to accept a connection to an 802.3af/at PSE device to power the whole TS-7680. Note that the TS-DC767-POE outputs a 13 VDC supply to the VIN of the whole system. This allows for proper power control from the supervisory microcontroller.
| Note: | The PoE input is not able to accept passive PoE input in any form. Doing so may damage the TS-DC767-POE or the TS-7680. |
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.
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.embeddedTS.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.
FPGA Programming
Currently, creating custom bitstreams is not supported. For more information contact Technologic Systems.
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 |
| Note: | When assigning an input signal to an FPGA_XX DIO output, that DIO needs to be set as an output. See the DIO section for more information. |
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_0_IN[2] | HD4_13 / T_4 |
| DIO_1_IN[2] | HD4_11 / T_5 |
| DIO_2_IN[2] | HD4_09 / T_6 |
| Note: | When assigning an output signal to an FPGA_XX DIO input, that DIO needs to be set as an input. See the DIO section for more information. |
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 [0] (RW) | ||
| 0 | Reserved | ||
| 0x10 | |||
| 208 | 7:2 | Reserved | |
| 1 | Enable LS_DIO_1 [0] (RW) | ||
| 0 | Reserved | ||
| 0x11 | |||
| 209 | 7:2 | Reserved | |
| 1 | Enable LS_DIO_2 [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.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.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.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
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.
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 boot 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) |
| NO CHRG | When jumper is set, disable charging of the SuperCaps. Beneficial for early development and testing. |
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 |
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 |
Reboot Source
The supervisory microcontroller is capable of saving and displaying the reason for the most recent reboot. This can be used to detect various errors that may occur in the field, as well as simple accounting of events. The source can be queried with tsmicroctl:
tsmicroctl -i
reboot_source=poweron
Possible sources and causes are:
| Source | Possible causes |
|---|---|
| poweron | Power removed, Super Caps discharged, and then power applied |
| brownout | Like "poweron," however the SuperCaps have not fully discharged |
| WDT | WDT timeout; reboot command (which reboots via WDT) |
| resetswitch | The reset switch has been enabled and has been asserted |
| sleep | The system has woken up from a sleep command |
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.
|
|
Sleep
| Note: | As soon as the sleep command is issued the unit will go to sleep. If the proper precautions are not taken, filesystem corruption can result as the sleep mode removes all power from the CPU and other peripherals on the SBC |
The addition of a microcontroller on board this SBC allows it to play a supervisory role over the CPU.
Low power sleep mode will remove power from all of the rails, turning off the CPU and every other peripheral save for the microcontroller. This mode offers extreme power savings, only requiring around 90 mW of power, with the ability to wake up after an arbitrary timeout (up to 1847297s, which is 21d 9h 8m 17s) with a 1s resolution. In order to enter this mode, issue the following command:
tsmicroctl --sleep --timewkup <time in seconds> --resetswitchwkup
Waking up from a sleep will take roughly 4-5s from when the timer expires or when the reset button is pressed. This is normal bootup time for the CPU.
Note that both --timewkup and --resetswitchwkup are optional arguments, you can pass none, one, or both. If no arguments are passed then the SBC will remain in sleep mode forever, until power is removed completely and re-applied. This can be useful instead of halting in linux as sleeping would consume far less power than simply halting the CPU. Be aware however, that if the Super Caps are installed they will keep power to the on-board microcontroller for a very long time. If the Super Caps are used than an external wakeup via timer or reset switch is highly recommended.
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.
SuperCaps
The TS-7680 has an option to add two 2.7 V 25 F supercapacitors. These two supercapacitors can provide up to 20 seconds of power hold time automatically if the external power input is removed. The Power Fail input signal (see the DIO Section) can be used to determine if the exterior power has been removed or fallen below a valid input level. Using this signal, a proper reboot can be issued to ensure that all data is flushed from cache to disk, and all disks are unmounted properly.
Using a reboot is important as issuing a shutdown command will put the kernel in a halted state with no way to cycle it back on so long as the supercapacitors are providing backup power. A reboot will get the system in to a state that will monitor the Power Fail input and will only continue to boot to the operating system if input power is valid.
The SuperCaps charge and discharge is managed transparently by the supervisory microcontroller. A jumper is provided on Rev. C and later PCBs to disable the charging and use of the SuperCaps. This mode is very useful for development to allow for proper power-off conditions without having to wait for the SuperCaps to discharge. The supervisory microcontroller will also not allow the TS-7680 to boot if power input is invalid. If the system reboots safely due to a power failure, it will remain in a powered off state until external power is re-applied, or the SuperCaps discharge below the sustainable threshold. Note that it is required to have at least 8.5 VDC input when charging completely flat supercapacitors, otherwise the TS-7680 will not power on properly due to the voltage brownout experienced from the supercapacitor charging.
By default, a script is started with systemd to monitor the Power Fail pin, and present all logged in users with a message saying that the power has failed and a graceful shutdown is taking place if the power input has failed. This script is located at /usr/local/bin/tssupercapmon
Additionally, U-Boot can delay booting until the SuperCaps are charged to a certain percentage, and optionally print the current percentage once per second. These are controlled with the environment variables chrg_pct and chrg_verb By setting chrg_pct to anything other than 0 (meaning "do not wait," which is the default behavior), booting will be delayed until that percentage is reached. Setting chrg_verb to 1 will enable the verbose printing of the current percentage every second. Note that the SuperCaps may be at "0%" for a large period of time, this is due to the charge level being below a voltage that can sustain the TS-7680. See the U-Boot section for information on setting environment variables.
A recommended starting point is 60%. This value was chosen because it can ensure the system is powered long enough to boot up and safely shut down (and provide an additional 10 s of power) if power is immediately cut once booting has started. Please note that this only applies to the default stock image, any further changes to the TS-7680 hardware or software, such as connecting powered devices like USB or adding additional applications may cause the recommended value to not sustain the TS-7680 until a safe reboot is completed. The time it takes to reach 60% charge will vary depending on the current charge of the SuperCaps. On average, it will take about 20 seconds to charge the SuperCaps to 60%; this is assuming the SuperCaps have very recently fallen below the threshold voltage to sustain the TS-7680.
Temperature Sensor
The on-board supervisory microcontroller contains an internal temperature sensor that can measure near ambient temperature on the SBC. The temperature sensor shares the same charastics of the ADC, that is, 10 bit with a 2.5 V reference voltage. The current value of the temperature sensor can be read with tsmicroctl:
tsmicroctl -i
...
temp_sensor=0x160
...
The temperature sensor has a 2.87 mV/°C slope, with an offset of 764 mV at 0 °C. The final output has a linearity of ±0.5 °C, an output error of ±128 uV/°C, and an offset error of ±15 mV.
Note that the actual temperature will be higher than true ambient. This is due to internal die heating, as well as overall heating of the PCB from operation.
UARTs
All of these UARTs are accessed using the standard /dev/ interfaces. See these resources for information on programming with UARTs in Linux.
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 |
- ↑ Also brings out CTS and RTS as UART0_CTS and UART0_RTS Crossbar mux names.
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 |
MODBUS Power
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
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 |
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 |
- ↑ Note, the Bluetooth modules requires the control lines CTS and RTS, their Crossbar mux names are BT_CTS and BT_RTS
USB
The USB host port is a standard USB 2.0 at 480 Mbps. The Linux kernel provides USB support. Adding additional device driver support for USB may require a kernel recompile. For creating custom USB support, libusb may be the easiest route.
Additionally, a USB host port is available on the HD1 Pin Header for use in daughter card applications. Note that this port can be configured for OTG behavior however the default device-tree sets this up statically as a host interface.
USB 5 V power to the vertical USB A jack can be disabled or re-enabled using DIO 59, marked EN_HOST_USB_5V on the schematic. See the syscon for more information on using this bit.
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.
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.
See the Network Configuration section for information on setup and configuring the WiFi device.
External Interfaces
CN5 Power
The TS-7680 includes a 3 pin power connector that has internal threads that allow for a screw down terminal connection. The TS-7680 is capable of accepting 8 to 40 VDC or 10 to 28 VAC input. When using DC, positive voltage can be applied to either of the two pins in the photo below with red wires, with ground return being connected to the green wire on the right. When using AC, hot and neutral are connected to the red wires. Please note that the connecting terminal shipped with the TS-7680 may differ from what is depicted in the photo.
HD1 Pin Header
|
|
HD4 Pin Header
|
|
24 pos. Screw Terminal
|
|
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 |
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 |
Revisions and Changes
Microcontroller Changelog
| Revision | Changelog |
|---|---|
| 0x0 |
|
| 0x1 |
|
| 0x2 |
|
| 0x3 |
|
| 0x4 |
|
| 0x5 |
|
| 0x6 |
Internal-only release |
| 0x7 |
|
| 0x8 |
|
| 0x9 |
|
| 0xA-0xC |
Internal-only releases |
| 0xD |
|
FPGA Changelog
| Revision | Changelog |
|---|---|
| 0x0 |
|
| 0x1 |
|
| 0x2 |
|
| 0x3 |
|
| 0x4 |
|
| 0x5 |
|
| 0x6 |
|
| 0x7 |
|
| 0x8 |
|
| 0x9 |
|
| 0xA |
|
PCB Revisions
| Revision | Changelog |
|---|---|
| A |
|
| B |
|
| C |
|
Software Images
| Image File | Changelog | Known Issues |
|---|---|---|
| ts7680-jan092015.dd.bz2 |
|
|
| ts7680-mar302015.dd.bz2 |
|
|
| ts7680-sep212015.dd.bz2 |
|
|
| ts7680-sep222015.dd.bz2 |
|
|
| ts7680-nov192015.dd.bz2 |
|
|
| ts7680-apr012016.dd.bz2 |
|
|
| ts7680-sep252018.dd.bz2 |
|
|
Linux 4.9.y Images
| Image File | Changelog | Known Issues |
|---|---|---|
| ts7680-linux4.9-20190220.dd.bz2 |
|
Linux 5.10.y Images
| Image File | Changelog | Known Issues |
|---|---|---|
| ts7680-debian-bookworm-headless-20240904.dd.xz md5 |
|
U-Boot
| Revision | Changelog |
|---|---|
| September 22th, 2015 |
|
| November 18th, 2015 |
|
| January 12th, 2016 |
|
| April 1st, 2016 |
|
| November 14th, 2016 |
|
| July 20th, 2018 |
|
| September 18, 2018 |
|
Product Change Notices
SPI Flash Vendor Change
Due to an EOL notice, the SPI flash on this product is changing. The new qualified part is an ISSI IS25LP016D.
Most applications will not be affected by this change as all units that ship with the new SPI flash part will have a U-Boot binary that supports it. Applications which simply modify the U-Boot environment will NOT require an update, while applications that use a custom U-Boot binary will need to be re-built from updated sources.
U-Boot Changes
Rebuilding the latest U-Boot in our git will include support for these these changes, but the specific commit where the fix is applied is available here: TS-7680 U-Boot
This change specifically adds support for the SPI device under the general ISSI struct of supported parts. This was necessary for the ISSI drivers to properly identify the part and be able to interact with it.
U-Boot releases with support
Any U-Boot built by us on or after July 20, 2018 will include support for this new SPI flash.
eMMC Flash Revision
Due to reasons beyond our control, the eMMC devices used on this product will possibly change during the lifetime of the TS-7680. The eMMC devices have a revision number inside to denote the eMMC command revision supported. A kernel modification is necessary in order to allow supporting of newer eMMC revisions. Without these updates the kernel will refuse to set up the eMMC device making it appear absent from the system.
All new shipping units will have the proper kernel installed on both eMMC and any pre-formatted SD cards that are ordered as well. Any applications that leave the stock kernel intact will not require any updating. However, applications which use custom kernel builds or use complete flash media images will need to have their images updated in order to properly support new eMMC devices.
Kernel Changes
Rebuilding the latest kernel in our git will include support for these these changes, but the specific commit where the fix is applied is available here: TS-7680 kernel
Image releases with support
Any images after and including our September 25, 2018 image will have the necessary changes to support new eMMC revisions moving forward.
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. |
Trademarks
Arm9 is a trademark, and Arm is a registered trademark, of Arm Limited (or its subsidiaries) in the US and/or elsewhere.