Difference between revisions of "TS-7250-V3"

From Technologic Systems Manuals
Line 111: Line 111:
{|class="wikitable sortable"
{|class="wikitable sortable"
! Schematic Net Name
! Chip
! Chip
! Pin
! Pin
! Location
! Location
| AN_CH1
| 0
| 0
| [[#ADC Header|ADC Pin 1]]
| AN_CH2
| 0
| 1
| [[#ADC Header|ADC Pin 3]]
| 0
| 4
| Onboard
| AN_CH3
| 0
| 5
| [[#ADC Header|ADC Pin 5]]
| AN_CH4
| 0
| 8
| [[#ADC Header|ADC Pin 7]]
| AN_CH5
| 0
| 9
| [[#ADC Header|ADC Pin 9]]
| 4
| 0
| Onboard
| 4
| 1
| Onboard
| EN_EMMC_3.3V
| 4
| 2
| Onboard
| EN_CL_1
| 4
| 7
| [[#ADC Header]]
| EN_CL_2
| 4
| 8
| [[#ADC Header]]
| EN_CL_3
| 4
| 9
| [[#ADC Header]]
| 0
| 18
| [[#LEDs]]

Revision as of 09:17, 4 December 2019

Note: This manual is incomplete at this time and is subject to change without warning while the TS-7250-V3 is in Engineering Sampling phase.

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

1 Overview

The TS-7250-V3 is a PC104 form factor SBC with a PC104 bus, mikroBus, Digi XBEE header, soldered down eMMC flash, dual Ethernet, microSD, and wifi. This board also provides a migration path from the TS-7250-V2 and TS-7250 series systems.

2 Getting Started

A Linux PC is recommended for development. For developers who use Windows, virtualized Linux using VMWare or virtualbox is recommended in order to make the full power of Linux available. The developer will need to be comfortable with Linux anyway in order to work with embedded Linux on the macrocontroller. The main reasons that Linux is useful are:

  • Linux filesystems on the microSD card can be accessed on the PC.
  • More ARM cross-compilers are available.
  • If recovery is needed, a bootable medium can be written.
  • A network filesystem can be served.

Once you have a development environment, you should continue on and power up the board.

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

3 U-Boot

TS-7250-V3 U-Boot Sections

4 Debian Buster(10)

TS-7250-V3 buster

5 Buildroot Configuration

TS-7250v3 buildroot

6 Backup / Restore

6.1 Creating A Backup / Production Image

Note: This section is incomplete at this time.

6.2 Restoring Stock / Backup / Production Image

6.2.1 Booted from USB / NFS

TS-7250-V3 eMMC Restore

7 Compile the Kernel

The kernel can be compiled on its own using the Debian 10 Cross Compiler. This should be run from a workstation, and not directly on the board. As with the Debian development, this requires setting up the docker for cross compiling.

Enter the cross compile environment:

# Create a place to store the kernel:
mkdir -p ~/Projects/tsimx6ul/kernel/
cd ~/Projects/tsimx6ul/kernel/
docker run -it --volume $(pwd):/work armhf-buster-toolchain bash

Inside the docker run:

cd /work/
git clone https://github.com/embeddedarm/linux-4.9.y.git --depth 1 linux
cd linux/

export ARCH=arm
export CROSS_COMPILE=arm-linux-gnueabihf-
make tsimx6ul_defconfig

# Make source or config customizations here

export TEMP=$(mktemp -d)
make -j $(nproc --all) all zImage
mkdir "$TEMP/boot/"
cp arch/arm/boot/zImage "$TEMP"/boot/zImage
cp arch/arm/boot/dts/imx6*-ts*.dtb "$TEMP"/boot/ 
INSTALL_MOD_PATH="$TEMP" make modules_install
tar czf kernel.tar.gz -C "$TEMP" .

After building this will output a kernel to ~/Projects/tsimx6ul/kernel/linux/kernel.tar.gz. This file can be copied to the board, and then installed with:

tar -xf kernel.tar.gz -C /

This can also be added to an image with:

mkdir /tmp/image/
sudo tar --numeric-owner -xf old-image.tar.bz2 -C /tmp/image/
sudo tar -xf kernel.tar.gz -C /tmp/image/
sudo tar --numeric-owner -cjf new-image.tar.bz2 -C /tmp/image .

8 Production Mechanism

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

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

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

Note: The ext4 filesystem can be used instead of ext3, but it may require additional options. U-Boot does not support the 64bit addressing added as the default behavior in recent revisions of mkfs.ext4. If using e2fsprogs 1.43 or newer, the options "-O ^64bit,^metadata_csum" must be used with ext4 for proper compatibility. Older versions of e2fsprogs do not need these options passed nor are they needed for ext3.
# This assumes USB drive is /dev/sdc:
sudo mkfs.ext3 /dev/sdc1
sudo mkdir /mnt/usb/
sudo mount /dev/sdc1 /mnt/usb/
sudo tar --numeric-owner -xf /path/to/tsimx6ul_usb_blaster-latest.tar.bz2 -C /mnt/usb/

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

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

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

Most users should be able to use the above script without modification. Our buildroot sources are available from our github repo. To build the whole setup and create a USB drive, the following commands can be used. This will wipe any data on the specified partition and replace it with an ext2 formatted filesystem. This filesystem will have all of the necessary files written to it to create a bootable USB drive. Note that this must be the first partition of the disk.

# Assuming /dev/sdc1 is your usb drive's first partition
make tsimx6ul_defconfig && make && sudo ./make_usb_prog.sh /dev/sdc1 tsimx6ul

9 Features

9.1 ADC

9.2 Battery Backed RTC

This board includes the STMicro "M41T00S" Battery Backed RTC using an external battery. This RTC is connected to the CPU via I2C and is handled by the kernel and is presented as a standard RTC device in Linux. TS-7250-V3 board provides battery backed power to the RTC via a replaceable CR1632 coin cell.

TS-7250-V3 board provides battery backed power to the RTC via a replaceable CR1632 coin cell.

9.3 Bluetooth

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

# Ensure that the Wi-Fi device is active
ifconfig wlan0 up 
# Enable Bluetooth, and load the driver firmware
echo BT_POWER_UP > /dev/wilc_bt
echo BT_DOWNLOAD_FW > /dev/wilc_bt
echo BT_FW_CHIP_WAKEUP > /dev/wilc_bt

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

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

hcitool lescan

This will return a list of devices such as:

3C:A3:08:XX:XX:XX Device_Name

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

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

The module supports some other commands as well:

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

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

9.4 CAN

The TS-7250-V3 CPU has two FlexCAN ports that use the Linux SocketCAN implementation. These are available on the #COM3 Header

These interfaces can be brought up with:

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

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

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

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

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

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

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

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

#include <stdio.h>
#include <pthread.h>
#include <net/if.h>
#include <string.h>
#include <unistd.h>
#include <net/if.h>
#include <sys/ioctl.h>
#include <assert.h>
#include <linux/can.h>
#include <linux/can/raw.h>

int main(void)
	int s;
	int nbytes;
	struct sockaddr_can addr;
	struct can_frame frame;
	struct ifreq ifr;
	struct iovec iov;
	struct msghdr msg;
	char ctrlmsg[CMSG_SPACE(sizeof(struct timeval)) + CMSG_SPACE(sizeof(__u32))];
	char *ifname = "can0";
	if((s = socket(PF_CAN, SOCK_RAW, CAN_RAW)) < 0) {
		perror("Error while opening socket");
		return -1;
	strcpy(ifr.ifr_name, ifname);
	ioctl(s, SIOCGIFINDEX, &ifr);
	addr.can_family  = AF_CAN;
	addr.can_ifindex = ifr.ifr_ifindex;
	if(bind(s, (struct sockaddr *)&addr, sizeof(addr)) < 0) {
		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) {
		return -3;

	iov.iov_base = &frame;
	msg.msg_name = &addr;
	msg.msg_iov = &iov;
	msg.msg_iovlen = 1;
	msg.msg_control = &ctrlmsg;
	iov.iov_len = sizeof(frame);
	msg.msg_namelen = sizeof(struct sockaddr_can);
	msg.msg_controllen = sizeof(ctrlmsg);  
	msg.msg_flags = 0;

	do {
		nbytes = recvmsg(s, &msg, 0);
		if (nbytes < 0) {
			return -4;

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

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

9.5 CPU

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

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

9.6 GPIO

Note: This section is incomplete at this time.

The i.MX6UL CPU and FPGA GPIO are exposed using a kernel character device. This interface provides a set of files and directories for interacting with GPIO which can be used from any language that interact with special files in linux using ioctl() or similar. For our platforms, we pre-install the "libgpiod" library and binaries. Documentation on these tools can be found here. This section only covers using these userspace tools and does not provide guidance on using the libgpiod library in end applications. Please see the libgpiod documentation for this purpose.

A user with suitable permissions to read and write /dev/gpiochip* files can immediately interact with GPIO pins. For example, to see if input power has failed:

gpioget 4 0

Multiple pins in the same chip can be read simultaneously by passing multiple pin numbers separated by spaces.

To write to a pin, the 'gpioset' command is used. For example, to set Relay 1:

gpioset 4 4=1

Multiple pins in the same chip can be set simultaneously by passing multiple pin=value pairs separated by spaces.

If a call with 'gpioset' or 'gpioget' fails with "Device or resource busy," that means that specific GPIO is claimed by another device. The command 'cat /sys/kernel/debug/gpio' can be used to get a list of all of the system GPIO and what has claimed them.

The 'gpiomon' tool can be used to monitor pins for changes.

Schematic Net Name Chip Pin Location
AN_CH1 0 0 ADC Pin 1
AN_CH2 0 1 ADC Pin 3
EN_SD_CARD_3.3V 0 4 Onboard
AN_CH3 0 5 ADC Pin 5
AN_CH4 0 8 ADC Pin 7
AN_CH5 0 9 ADC Pin 9
GYRO_INT 4 0 Onboard
FPGA_IRQ 4 1 Onboard
EN_EMMC_3.3V 4 2 Onboard
EN_CL_1 4 7 #ADC Header
EN_CL_2 4 8 #ADC Header
EN_CL_3 4 9 #ADC Header
EN_RED_LED# 0 18 #LEDs

9.7 eMMC Interface

Note: This section is incomplete at this time.

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

Our default software image contains 2 partitions:

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

This platform includes an eMMC device, a soldered down MMC flash device. Our off the shelf builds are 4 GB, but up to 64 GB are available for customized builds. The eMMC flash appears to Linux as an SD card at /dev/mmcblk0. The eMMC includes additional boot partitions that are used by U-Boot and are not affected by the eMMC partition table.

The eMMC module has a similar concern by default to SD cards in that they should not be powered down during a write/erase cycle. However, this eMMC module includes support for setting a fuse for a "Write Reliability" mode, and a "psuedo SLC (pSLC)" mode. With both of these enabled all writes will be atomic to 512 B and each NAND cell will be treated as a single layer rather than a multi-layer cell. If a sector is being written during a power loss, a block is guaranteed to have either the old or new data. Even in cases where the wrong data is present on the next boot, fsck is often able to deal with the older data being present in a 512 B block. The downsides to setting these modes are that it will reduce the overall write speed and halve the available space on the eMMC to roughly 1.759 GiB. Please note that even with these settings, Technologic Systems strongly recommends designing the end application to eliminate any situations where a power-loss event can occur while any disk is mounted as read/write. The TS-SILO option available on certain TS-7100 I/O boards can help to eliminate the dangerous situation.

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

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

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

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

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

Example usage:

./emmc_reliability /dev/mmcblk0

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

9.8 Ethernet Ports

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

9.9 FPGA

9.9.1 FPGA Registers

The TS-7250-V3 FPGA is connected to the CPU over the WEIM bus. This provides 8-bit, 16-bit, or 32-bit access to the FPGA mapped at 0x5000_0000.

For example, to read the FPGA information at the first register of the syscon:

root@ts-imx6ul:~# memtool md -l 0x50004000+4
50004000: 00000006
Offset Description
0x0000 UART 16550 #0
0x0100 Opencore SPI controller #0
0x0120 Opencore SPI controller #1
0x4000 FPGA Syscon FPGA 16550

This FPGA includes a 16550 UART peripheral that can be used as a standard Linux serial port. It is not recommended to interact directly with these registers. FPGA SPI

This FPGA includes a pair of SPI master devices. These are used for the FRAM memory, accessing the flash used for the LCD splash screen image, and the LCD touch screen itself. All of these operations are handled via the Linux kernel. It is not recommended to interact directly with these registers FPGA Syscon

The FPGA syscon is the main system control block of the FPGA. Contained in this region is the FPGA GPIO, PWM, and IRQ control. It is not recommended to interact directly with these registers unless directed to do so by other manual sections.

Some registers are dual purpose, having separate read and write functionality; while others may only have write functionality. Registers that do not read and write the same are indicated with "(RD)" and "(WR)" notation. All other registers read and write the same data set. Any unlisted register addresses are Reserved / Undefined.

Offset Bits Description
0x00 (RD) 31:0 Revision and Info Register.
0x10 (RD) 15:0 DIO bank 0 Pin State
0x10 (WR) 15:0 DIO bank 0 Data Set
0x12 (WR) 15:0 DIO bank 0 Output Enable Set
0x14 (RD) 15:0 DIO bank 0 Data
0x14 (WR) 15:0 DIO bank 0 Data Clear
0x16 (RD) 15:0 DIO bank 0 Output Enable
0x16 (WR) 15:0 DIO bank 0 Output Enable Clear
0x20 (WR) 31:0 Fractional clock generator [1]
0x24 (RD) 31:0 IRQ Status
0x24 (WR) 31:0 Fractional PWM generator
0x40 (RD) 15:0 DIO bank 1 Pin State
0x40 (WR) 15:0 DIO bank 1 Data Set
0x42 (WR) 15:0 DIO bank 1 Output Enable Set
0x44 (RD) 15:0 DIO bank 1 Data
0x44 (WR) 15:0 DIO bank 1 Data Clear
0x46 (RD) 15:0 DIO bank 1 Output Enable
0x46 (WR) 15:0 DIO bank 1 Output Enable Clear
0x48 31:0 IRQ mask
0x50 (RD) 15:0 DIO bank 2 Pin State
0x50 (WR) 15:0 DIO bank 2 Data Set
0x52 (WR) 15:0 DIO bank 2 Output Enable Set
0x54 (RD) 15:0 DIO bank 2 Data
0x54 (WR) 15:0 DIO bank 2 Data Clear
0x56 (RD) 15:0 DIO bank 2 Output Enable
0x56 (WR) 15:0 DIO bank 2 Output Enable Clear
  1. Note that this is also used for UART clock generation. FPGA IRQs

Bit Description
31:17 Reserved
16 Touch Screen IRQ
15:13 Reserved
12 DIO Fault Breaker IRQ
11 Reserved
10 Opencore SPI Controller #1 IRQ
9 Opencore SPI Controller #0 IRQ
8:1 Reserved

9.10 FRAM

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

The EEPROM file can be found at /sys/bus/spi/devices/spi32766.0/eeprom

9.11 I2C

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

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

9.12 Interrupts

Note: This section is incomplete at this time.

9.13 LCD

9.13.1 Splash Screen

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

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

A simple conversion would look like the following:

./splash-convert Logo.png

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

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

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

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

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

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

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

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

9.14 LEDs

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

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

The following LEDs are available on this system:

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

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

9.15 Relays

Note: This section is incomplete at this time.

9.16 Sleep

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

9.16.1 Suspend-to-RAM

9.17 SPI

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

9.18 TS-SILO Supercapacitors

9.19 UARTs

The TS-7100-Z offers 4 total UARTs for communication:

UART Dev. Type TX / + Loc. RX / - Loc.
ttymxc1 RS-232 CN32 Terminal, pin 1 CN32 Terminal, pin 7
ttymxc2 Bluetooth N/A N/A
ttymxc4 RS-232 CN32 Terminal, pin 3 CN32 Terminal, pin 5
ttyS0 RS-485 CN32 Terminal, pin 29 CN32 Terminal, pin 31

9.19.1 RS-485

RS-485 is implemented via a UART interface inside of the FPGA. This device handles automatic TXEN assertion and de-assertion for half-duplex RS-485 communication. See the UARTs section for the location of the RS-485 port.

9.20 USB

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

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

9.21 Watchdog

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

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

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

The kernel driver supports the "Magic Close" feature of the WDT. This means that a 'V' character must be fed in to the watchdog file before the file is closed in order to disable the WDT. If this does not happen then the WDT is not stopped and it will continue it's countdown. This is the default behavior of our stock kernel.

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

See the Linux WDT API documentation for more information.

9.22 WiFi

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

Summary features:

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

10 Specifications

Note: This section is incomplete at this time.

10.1 Power Specifications

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

10.2 Power Consumption

10.2.1 TS-SILO SuperCaps

11 External Interfaces

11.1 ADC Header

The ADC header supports 5 channels of 0-30VDC ADC. Of these 5, 3 channels support sampling 0-20mA current loops. These channels are sampled from /sys/devices/platform/soc/2100000.aips-bus/2198000.adc/iio:device0#/.

For example:

# Disable current loops:
Signals Pin Layout
Pin Signal
10 GND


11.2 Battery Connector

The #RTC uses removable lithium cr1632 batteries.


11.3 COM2 Header

The COM2 header is a 0.1" pitch 2x5 header supporting RS-485, RS-422 and RS-232.

Signals Pin Layout
Pin Signal
1 ttyS11 RS485+
2 ttyS9 RS-232 RXD
3 ttyS9 RS-232 TXD
4 ttyS12 RS485+
6 ttyS11 RS485-
7 ttyS9 RS-232 RTS
8 ttyS9 RS-232 CTS
9 ttyS12 RS485-
10 NC


11.4 COM3 Header

The COM3 header is a 0.1" pitch 2x5 header supporting CAN and RS-232.

Signals Pin Layout
Pin Signal
1 CAN2_H
2 ttyS10 RS-232 RXD
3 ttyS10 RS-232 TXD
4 CAN1_H
6 CAN2_L
7 ttyS10 RS-232 RTS
8 ttyS10 RS-232 CTS
9 CAN1_L
10 NC


11.5 DB9 Connector

The DB9 (DE-9) connector provides an RS-232 port with full handshakes.

Signals Pin Layout
Pin Signal
1 ttyS8 RS-232 DCD
2 ttyS8 RS-232 RXD
3 ttyS8 RS-232 TXD
4 ttyS8 RS-232 DTR
6 ttyS8 RS-232 DSR
7 ttyS8 RS-232 RTS
8 ttyS8 RS-232 CTS
9 ttyS8 RS-232 RI


11.6 DIO Header

The DIO header is a 0.1" pitch 2x8 header including SPI and GPIO. All pins on this header are 5V tolerant except SPI output pins. All of these DIO includes pullups.

Signals Pin Layout
Pin Signal
1 GPIO Bank 5 IO 1
3 GPIO Bank 5 IO 2
4 Current Sink Output Bank 2 IO 27 [1]
5 GPIO Bank 5 IO 3
6 spidev 0.1 Chip Select
7 GPIO Bank 5 IO 4
8 GPIO Bank 5 IO 5
9 GPIO Bank 5 IO 6
10 spidev 0.1 MISO
11 GPIO Bank 5 IO 7
12 spidev 0.1 MOSI
13 GPIO Bank 5 IO 8
14 spidev 0.1 CLK
15 GPIO Bank 5 IO 9
16 3.3V

TS-7250-V3-DIO Header.svg

  1. When this pin is a high output it enables a FET to ground.

The DIO header is designed to provide compatibility with the KPAD accessory. This is a 4x4 numerical keypad. This is supported in userspace with the keypad.c source code, or the "keypad" utility which is included in the shiping image.

This debounces presses to 50ms, and does not repeat when numbers are held. This will output a string containing the key that is pressed. Eg:

root@tsimx6:~# keypad

11.7 Ethernet connectors

The TS-7250-V3 supports two independent 10/100 Ethernet ports. See the Configuring the Network section of the manual for more information on configuration.

TS-7250-V3 Eth.svg

11.8 LCD Header

The LCD header is a 0.1" pitch 2x7 header including GPIO. This is designed around compatibility with the HD44780 LCD controller which includes our LCD-LED. The LCD Data pins (7-14) are 5V tolerant. These will output up to 3.3V, and the remaining control IO and PWM are 3.3V tolerant.

Signals Pin Layout
Pin Signal
1 5V
3 LCD_RS GPIO Bank 2 IO 23
4 LCD_BIAS PWM0 / GPIO Bank 2 IO 24 [1]
5 LCD_EN GPIO Bank 5 IO 20
6 LCD_WR GPIO Bank 5 IO 19
7 LCD D1 GPIO Bank 2 IO 9
8 LCD D0 GPIO Bank 5 IO 10
9 LCD D3 GPIO Bank 5 IO 11
10 LCD D2 GPIO Bank 5 IO 12
11 LCD D5 GPIO Bank 5 IO 15
12 LCD D4 GPIO Bank 5 IO 16
13 LCD_D7 GPIO Bank 5 IO 17
14 LCD_D6 GPIO Bank 5 IO 18

TS-7250-V3-LCD Header.svg

  1. This pin is used to dynamically adjust contract on the LCD. This may need to be tuned depending on the environment or altitude where the display is used.

The TS-7250-V3 Debian images include a command lcdmesg. This can be used to write to our LCD-LED display.

For example, this would write to the display:

lcdmesg "line 1" "line 2"
# Messages can also be piped to lcdmesg:
echo -e "line 1\nline 2\n" | lcdmesg

For example, running:

lcdmesg Technologic Systems

will display:

LCD LED example.jpg

11.9 microBus Header

TS-7250-V3 microBus Header

11.10 MicroSD Connector

TS-7250-V3 MicroSD Connector

11.11 MicroUSB Connector

The TS-7250-V3 features an onboard supervisory microcontroller that converts the onboard 3.3V TTL console UART (ttymxc0) into a CP2103 USB serial device.

TS-7250-V3 USB Console.jpg

11.12 PC104 Header

The PC104 connector consists of four rows of pins labelled A-D. The PC104 standard implements an ISA bus over these headers, but we also include the ability for almost all of the pins to be used as DIO.

TS-7250-V3 PC104 pinout.svg

Pin Name GPIO Pin Name GPIO Pin Name GPIO Pin Name GPIO
B31 GND N/A A31 ISA_ADD_00 N/A
B30 ISA_14_3_MHZ N/A A30 ISA_ADD_01 N/A
B29 5V N/A A29 ISA_ADD_02 N/A
B28 ISA_BALE Bank 6 IO 1 A28 ISA_ADD_03 N/A C19 GND N/A D19 GND N/A
B27 ISA_TC Bank 6 IO 2 A27 ISA_ADD_04 N/A C18 ISA_DAT_15 N/A D18 GND N/A
B26 ISA_DACK2 Bank 6 IO 10 A26 ISA_ADD_05 N/A C17 ISA_DAT_14 N/A D17 Unused N/A
B25 ISA_IRQ3 N/A A25 ISA_ADD_06 N/A C16 ISA_DAT_13 N/A D16 +5V N/A
B24 GND N/A A24 ISA_ADD_07 N/A C15 ISA_DAT_12 N/A D15 ISA_DRQ7 101
B23 ISA_IRQ5 14 A23 ISA_ADD_08 49 C14 ISA_DAT_11 36 D14 ISA_DACK7 100
B22 ISA_IRQ6 15 A22 ISA_ADD_09 50 C13 ISA_DAT_10 35 D13 ISA_DRQ6 99
B21 ISA_IRQ7 16 A21 ISA_ADD_10 51 C12 ISA_DAT_09 34 D12 ISA_DACK6 98
B20 ISA_BCLK 21 A20 ISA_ADD_11 52 C11 ISA_DAT_08 33 D11 ISA_DRQ5 97
B19 ISA_REFRESH 8 A19 ISA_ADD_12 53 C10 Unused N/A D10 ISA_DACK5 96
B18 ISA_DRQ1 19 A18 ISA_ADD_13 54 C09 Unused N/A D09 ISA_DRQ0 95
B17 ISA_DACK1 18 A17 ISA_ADD_14 55 C08 Unused N/A D08 ISA_DACK0 94
B16 ISA_DRQ3 11 A16 ISA_ADD_15 56 C07 Unused N/A D07 ISA_IRQ14 93
B15 ISA_DACK3 13 A15 ISA_ADD_16 57 C06 Unused N/A D06 ISA_IRQ15 92
B14 ISA_IOR 0 A14 ISA_ADD_17 58 C05 N/A Unused D05 ISA_IRQ12 91
B13 ISA_IOW 1 A13 ISA_ADD_18 59 C04 Unused N/A D04 ISA_IRQ11 90
B12 ISA_MEMR 3 A12 ISA_ADD_19 60 C03 Unused N/A D03 ISA_IRQ10 89
B11 ISA_MEMW 2 A11 ISA_AEN 7 C02 Unused N/A D02 ISA_IO16 88
B10 GND N/A A10 ISA_IORDY 10 C01 Unused N/A D01 ISA_MEM16 87
B09 Unused N/A A09 ISA_DAT_00 25 C00 GND N/A D00 GND N/A
B08 ISA_ENDX 6 A08 ISA_DAT_01 26
B07 Unused N/A A07 ISA_DAT_03 28
B06 ISA_DRQ2 12 A06 ISA_DAT_04 29
B05 3.3V [1] N/A A05 ISA_DAT_05 30
B04 ISA_IRQ9 17 A04 ISA_DAT_02 27
B03 Unused N/A A03 ISA_DAT_06 31
B02 ISA_RESET 4 A02 ISA_DAT_07 32
  1. The PC104 standard uses -5V here. If a third party device is used that might use this rail, FB17 should be removed.

11.13 Power Connectors

The TS-7250-V3 provides two power inputs on 2 pin removable terminal blocks. One terminal block supports 5VDC, and one supports 8-28VDC. Only one power input may be connected at a time. A typical power supply for this platform should provide 10W. Refer to the specifications section for more information on power requirements.

Under the removable terminal block the PCB is labelled with the power supply polarity.

TS-7250-V3 removable power connector.jpg

11.14 USB Ports

The TS-7250-V2 has 2 USB type A host ports. The bottom USB host port can optionally be routed to the #XBEE Header for USB cell modems.

# Route USB to XBEE
gpioset 2 28=1

# Route USB to bottom of J2
gpioset 2 28=0

11.15 XBEE Header

The CN20 header is a 2mm pitch 2x10 header which supports XBEE form factor modules. These include Nimbelink and Digi cell modems, Zigbee, Digi mesh, and other third party radios.

For Cell radios that use USB this must be enabled. This turns off USB to the bottom port on the dual high type A connector. Only enable if this is compatible with your module:

# Turn on the USB
gpioset 0 11=1

This header can provide 3.3V or 4V as some cell radios require higher voltage.

# Turn 3.3V & 4V off;
gpioset 6 4=0 11=0

# For 3.3V modules:
gpioset 6 4=1

# For 4V modules:
# gpioset 6 11=1

For serial modules refer to these related links:

This sample code can be used to verify connectivity to the serial based modules:

wget http://ftp.embeddedarm.com/ftp/ts-arm-sbc/ts-7840-linux/samples/xbeetest.c
gcc xbeetest.c -o xbeetest

gpioset 6 4=0 11=0 # Turn all modem power off
gpioset 6 4=1 # Turn on only 3.3V

./xbeetest /dev/ttymxc3

This will print out the module information such as:

XBee3 Zigbee TH RELE: 100A
Build: Apr 16 2020 19:00:33
HV: 424E
Bootloader: 181 Compiler: 8030001
Stack: 6710
Signals Pin Layout
Pin Signal
1 VCC (XBEE_3.3V or NIMBEL_4.7V)
2 ttymxc3 TXD
3 ttymxc3 RXD
5 NC
10 GND
11 GND
12 ttymxc3 CTS#
13 NC
14 3.3V VREF
15 GND
16 GND

TS-7250-V3-XBEE Header.svg

12 Revisions and Changes

Note: This section is incomplete at this time.

12.1 FPGA Changelog

12.2 Microcontroller Changelog

12.3 PCB Revisions

12.4 Software Images

12.4.1 Debian Changelog

12.5 U-Boot

13 Product Notes

13.1 FCC Advisory

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

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

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

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

13.2 Limited Warranty

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

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

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

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

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

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