Buildroot

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

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

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

The base configuration for each device brings in hardware support to get the unit booted, but offers minimal software support and relies mostly on tools provided by BusyBox. An "extra packages" defconfig that can be merged in with any of the base configurations in order to provide many additional packages to create an environment that is more consistent with larger Linux distributions. The larger Buildroot configuration averages about 10 seconds of boot time, much of which is spent on networking. The base configurations can reduce this time significantly.

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

tip

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

Installing

When building Buildroot from source, the output files can be used to create bootable microSD and eMMC media for the TS-7250-V3. The output files are also compatible with the USB Image Replicator.

Building

Buildroot is intended to be completely cross-compiled from a host Linux workstation. The following creates a TS-7250-V3 bootable image and filesystem tarball:

git clone --recurse-submodules https://github.com/embeddedTS/buildroot-ts.git
cd buildroot-ts/

# Merge the larger package set with the TS-7250-V3 base configuration.
./buildroot/support/kconfig/merge_config.sh technologic/configs/extra_packages_defconfig technologic/configs/ts7250v3_defconfig

# Or build a smaller base image with bare hardware support:
# make ts7250v3_defconfig

make menuconfig
make

The final filesystem tarball is written to buildroot/output/images/rootfs.tar.xz.

Cross Compiling

In order to generate a cross-compiler from Buildroot, first configure the target build as outlined in the first steps of the build instructions. Once configured, a separate make command can be issued to generate a tarball package of the cross-compiler. This can be unpacked to any location on the host Linux workstation's filesystem and then used to cross-compile additional applications for the target. The build, setup, and use of the cross-compiler can be done with the following steps:

# Be sure the target is configured first!
# The following command will output the cross-compiler package as well as build the target image completely if not built already
make sdk

# Unpack the tarball to new directory in the users home directory
# Note that the tarball name may be slightly different depending on how the toolchain is configured in Buildroot
mkdir ~/buildroot-toolchain
tar xf buildroot/output/images/arm-buildroot-linux-gnueabihf_sdk-buildroot.tar.gz -C ~/buildroot-toolchain/

# Update the path information for the toolchain (must be done when the tarball is unpacked, or if the root folder of the toolchain is moved!)
# Note that, as above, the path for the compiler may be slightly different depending on how the toolchain is configured in Buildroot
~/buildroot-toolchain/arm-buildroot-linux-gnueabihf_sdk-buildroot/relocate-sdk.sh

# Create a simple Hello World application source
cat << EOF > hello.c
#include <stdio.h>
void main(void) { printf("Hello!\n"); }
EOF

# Build a binary from the Hello World source that can be run on the target device
~/buildroot-toolchain/arm-buildroot-linux-gnueabihf_sdk-buildroot/bin/arm-linux-gcc hello.c -o hello

# This cross compiler can be added to the user's PATH variable for easy access
export PATH=$PATH:~/buildroot-toolchain/arm-buildroot-linux-gnueabihf_sdk-buildroot/bin
arm-linux-gcc hello.c -o hello

The hello binary can then be copied to the target device and executed on it.

Note that the make sdk command can be run at any time to generate the toolchain tarball. Even after Buildroot has generated the output image.

Buildroot is extremely flexible in its generation and use of a cross-compiler. See the Buildroot manual for more information on advanced use of the Buildroot generated toolchain as well as using Buildroot's generated cross-compiler as an external compiler for Buildroot.

Configuring the Network

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

# Bring up the CPU network interface
ifconfig eth0 up

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

# Set a specific subnet
ifconfig eth0 192.168.0.50 netmask 255.255.0.0

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

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

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

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

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

# interface file auto-generated by Buildroot

auto lo
iface lo inet loopback

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

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

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

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

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

Installing New Software

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

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

Setting Up SSH

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

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

passwd root

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

Starting Software Automatically

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

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

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

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

case "$1" in
  start)
    echo 1 > /sys/class/leds/red-led/brightness
    ## If you are launching a daemon or other long running processes
    ## this should be started with
    # nohup /usr/local/bin/yourdaemon &
    ;;
  stop)
    # if you have anything that needs to run on shutdown
    echo 0 > /sys/class/leds/red-led/brightness
    ;;
  *)
    echo "Usage: customstartup start|stop" >&2
    exit 3
    ;;
esac
  
exit 0

note

The $PATH variable is not set up by default in init scripts so this will either need to be done manually or the full path to your application must be included.

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

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

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

Features

ADC

The TS-7250-V3 supports five 12-bit ADC channels through the i.MX6UL ADC. All channels support 0-30 V input, and channels 1-3 can optionally be used as 0-20 mA current loop inputs. The ADC header provides dedicated analog ground pins to reduce noise.

The ADCs are exposed through Linux IIO:

iio_attr -c 2198000.adc voltage0
iio_attr -c 2198000.adc voltage1
iio_attr -c 2198000.adc voltage5
iio_attr -c 2198000.adc voltage8
iio_attr -c 2198000.adc voltage9

ADC Header Pin	Schematic Name	IIO device	IIO name	Voltage	Current loop
1	AN_CH1	`2198000.adc`	`voltage0`	0-30 V	0-20 mA
3	AN_CH2	`2198000.adc`	`voltage1`	0-30 V	0-20 mA
5	AN_CH3	`2198000.adc`	`voltage5`	0-30 V	0-20 mA
7	AN_CH4	`2198000.adc`	`voltage8`	0-30 V	N/A
9	AN_CH5	`2198000.adc`	`voltage9`	0-30 V	N/A

note

The inputs are rated for 30 V maximum, but the ADC front-end scales 40 V down to the 2.5 V reference. A 30 V input will not read the full-scale 12-bit value.

Current loop mode is controlled with GPIO:

gpioset 20ac000.gpio 7=0 # AN_CH1 voltage
gpioset 20ac000.gpio 8=0 # AN_CH2 voltage
gpioset 20ac000.gpio 9=0 # AN_CH3 voltage

gpioset 20ac000.gpio 7=1 # AN_CH1 current
gpioset 20ac000.gpio 8=1 # AN_CH2 current
gpioset 20ac000.gpio 9=1 # AN_CH3 current

For C applications, libiio provides the fastest API and reaches approximately 6 ksps across all channels. Python bindings currently reach approximately 2 ksps with similar logic.

C Example 
/* Build with gcc adc-test.c -o adc-test -liio 
 * Gets ~6 ksps
 * At the time of writing this does not support the buffer interface */

#include <stdint.h>
#include <stdio.h>
#include <string.h>
#include <assert.h>
#include <stdio.h>
#include <errno.h>
#include <iio.h>

uint32_t scale_mv(uint32_t raw)
{
	/* We need to scale for the ADC range, of a 12-bit adc at 0-2500mV, and
	 * the resistor divider (R1+R2/R2)
	 *     (2500/4095) * ((33000 + 2200)/2200)
	 * This below is this fraction simplified
	 */
	return raw * 8000/819;
}

int main(int argc, char **argv)
{
	static struct iio_context *ctx;
	static struct iio_device *dev;
	static struct iio_channel *chn[5];
	int i, ret;
	long long sample;

	ctx = iio_create_default_context();
	assert(ctx);
	dev = iio_context_find_device(ctx, "2198000.adc");
	assert(dev);

	chn[0] = iio_device_find_channel(dev, "voltage0", false);
	chn[1] = iio_device_find_channel(dev, "voltage1", false);
	chn[2] = iio_device_find_channel(dev, "voltage5", false);
	chn[3] = iio_device_find_channel(dev, "voltage8", false);
	chn[4] = iio_device_find_channel(dev, "voltage9", false);

	for (i = 0; i < 5; i++) {
		ret = iio_channel_attr_read_longlong(chn[i], "raw", &sample);
		assert(!ret);
		printf("AN_CH%d_mv=%d\n", i, scale_mv((uint32_t)sample));
	}

	return 0;
}

Python Example
#!/usr/bin/env python3

import iio

ctx = iio.Context('local:')
dev = ctx.find_device('2198000.adc')

scan_channels = ["voltage0", "voltage1", "voltage5", "voltage8", "voltage9"]
i = int(0)
for chan_name in scan_channels:
	chn = dev.find_channel(chan_name)
	raw = int(chn.attrs['raw'].value)

	# Scale 0-4095 to 0-2500(mV)
	scaled = raw * (2.5/4095)

	# Scale voltage divider on the pin
	r1 = 330
	r2 = 22
	v = scaled / (r2 / (r1 + r2))

	i += 1
	print('AN_CH{}_V={:.3f}'.format(i, v))

Bluetooth

On many boards, support for Bluetooth is provided by the BlueZ project. BlueZ supports different profiles for HID, A2DP, and more. Refer to the BlueZ documentation for more information. Please see our BLE Examples page for information on installing BlueZ from source, getting started, and using demo applications.

BlueZ Bluetooth modules can be activated with the following commands:

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

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

At this point, the device is fully set up to be controlled by various BlueZ tools. For example, to do a scan of nearby devices:

bluetoothctl
power on
scan on

This will return a list of devices such as:

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

Other supported commands include:

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

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

CAN

The TS-7250-V3 CPU has two FlexCAN ports using Linux SocketCAN. These are available on the COM3 header.

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

At this point, applications can use standard SocketCAN APIs. Debian images include cansend and candump:

candump can0
cansend can0 7Df#03010c

In production use, set a restart timeout so the CAN bus can recover automatically from a bus-off condition:

ip link set can0 type can restart-ms 100
ip link set can1 type can restart-ms 100

CPU

This device uses the NXP i.MX6UL CPU, running at up to 696 MHz, based on an Arm Cortex-A7 core and targeting low power consumption.

Refer to NXP's i.MX6UL documentation for detailed CPU information.

GPIO

GPIO pins can be interacted with via gpiod tools such as gpioset and gpioget. For example, the En. Relay is chip and line 4 8:

gpioset 4 8=1  # Enable the relay solenoid
gpioset 4 8=0  # Disable the relay solenoid

To read the value of a GPIO line, gpioget can be used, for example to read the state of the Push Switch:

gpioget 2 18

eMMC Interface

Our default programming of the eMMC is the same as the SD card image for standard partitions.

The default software image contains 3 partitions:

Device	Contents
/dev/mmcblk1	Full eMMC block device
/dev/mmcblk1boot0	eMMC boot partition
/dev/mmcblk1boot1	eMMC boot partition
/dev/mmcblk1p1	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/mmcblk1. Our default programming of the eMMC is the same as the SD card image for standard partitions, but includes additional boot partitions that are used by U-Boot and are not affected by the eMMC partition table.

The eMMC module has a similar concern by default to SD cards in that they should not be powered down during a write/erase cycle. However, this eMMC module includes support for setting a fuse for a "Write Reliability" mode, and a "psuedo SLC (pSLC)" mode. With both of these enabled 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 GB. 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 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.

danger

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.

danger

The script is only compatible with Rev. D or newer PCBs. Running the script on any previous PCB revision WILL result in the unit being unable to boot! There is no safe way to enable these modes on previous PCB revisions.

warning

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-7553-V2 utilities github repository.

The script must be run when boot from any media other than eMMC, such as SD, 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/mmcblk1

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

Ethernet Ports

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

FEC PTP Support

PTP is supported in Linux via the linuxptp project. This allows synchronizing the system clock to within ±1 us.

Note that Linux kernel version 4.9 or greater is required for PTP support with the i.MX6UL CPU. An example of setting up an ethernet interface with PTP and adjusting the clock based on that is below.

apt-get install linuxptp -y

# For PTP on eth0
phc2sys -s /dev/ptp0 -w &
ptp4l -2 -H -i eth0 -m -p /dev/ptp0 &

# For PTP on eth1
phc2sys -s /dev/ptp1 -w &
ptp4l -2 -H -i eth1 -m -p /dev/ptp1 &

If the clocks are significantly off this may take time for the clocks to converge.

FPGA

The TS-7250-V3 FPGA provides board-specific I/O including GPIO banks, 16550-compatible UARTs, SPI, I2C, PWM, ADC support, interrupts, and the PC/104 ISA interface.

The FPGA is memory mapped at 0x50000000. The kernel drivers expose the supported interfaces through standard Linux APIs where possible, which is the recommended access method for applications.

Useful top-level regions include:

Region	Description
`0x50000000`	FPGA top-level/syscon region
`0x50000100`	16550-compatible UART region
`0x50000180`	FPGA SPI controller region
`0x50004010` and later	FPGA GPIO banks
`0x50004050`	PC/104 ISA access window

The syscon register at offset 0x08 controls several muxes, including mikroBUS GPIO mode, PC/104 GPIO mode, DIO SPI GPIO mode, and the optional DIO UARTs. Prefer tshwctl for syscon access:

# Read a syscon register
tshwctl --address 0x08 --peek32

# Enable the DIO header UART muxes
tshwctl --address 0x08 --poke32 0x6000

PC/104 Bus

The TS-7250-V3 includes an ISA bus for compatibility with PC/104 peripherals. User space can access the bus using files exposed by the fpgaisa driver:

/sys/bus/platform/devices/50004050.fpgaisa/

File	Description
`io8`	8-bit strobes on IOR/IOW
`io16`	16-bit strobes on IOR/IOW
`ioalt16`	16-bit strobes on IOR/IOW with alternate pinout
`mem8`	8-bit strobes on MEMR/MEMW
`mem16`	16-bit strobes on MEMR/MEMW
`memalt16`	16-bit strobes on MEMR/MEMW with alternate pinout

For 16-bit accesses, addresses must be aligned to an even byte and reads/writes must use multiples of two bytes.

The pc104_peekpoke utility can be used from a shell:

Usage pc104_peekpoke <io/mem> <8/16/alt16> <address> [value]
Eg: pc104_peekpoke io 8 0x140

PC/104 cycles are approximately 1 us per access on either 8-bit or 16-bit accesses.

FRAM

The TS-7250-V3 supports an optional Fujitsu MB85RS16N FRAM device. This is a 2 KiB non-volatile SPI memory with very high write endurance and long data retention.

Linux exposes the FRAM as a flat EEPROM file:

/sys/bus/spi/devices/spi4.1/eeprom

note

FRAM is not present on all TS-7250-V3 configurations.

I2C

The i.MX6UL supports I2C at 100 kHz or 400 kHz fast mode. This platform uses two CPU I2C buses for onboard devices and one FPGA I2C bus for off-board mikroBUS use.

Device	Address	Description
`/dev/i2c-0`	`0x1e`	Magnetometer
`/dev/i2c-0`	`0x54`	Supervisory microcontroller on early hardware
`/dev/i2c-0`	`0x68`	RTC
`/dev/i2c-0`	`0x6a`	IMU
`/dev/i2c-1`	`0x20`	NXP PCA9555 GPIO expander, chip `2-0020`
`/dev/i2c-1`	`0x64`	ATSHA204, not populated by default
`/dev/i2c-4`	N/A	mikroBUS header

IMU

Accelerometer (ST ISM330)

This platform features an ST ism330dhcx accelerometer / gyroscope. The accelerometer has an acceleration range of ±2/±4/±8/±16 g.

The accelerometer is accessed through IIO with channels:

accel_x
accel_y
accel_z
timestamp

For example:

# ISM330DHCX
iio_attr -c ism330dhcx_accel accel_x
iio_attr -c ism330dhcx_accel accel_y
iio_attr -c ism330dhcx_accel accel_z

The below examples will be written for the ism330dhcx_accel, but if this fails instead use the ism330dlc_accel device. These commands will provide a single sample of all of the values:

root@tsimx6ul:~# iio_attr -c ism330dhcx_accel accel_x
dev 'ism330dhcx_accel', channel 'accel_x' (input), attr 'injection_raw', ERROR: Permission denied (-13)
dev 'ism330dhcx_accel', channel 'accel_x' (input), attr 'raw', value '-183'
dev 'ism330dhcx_accel', channel 'accel_x' (input), attr 'scale', value '0.000598'
dev 'ism330dhcx_accel', channel 'accel_x' (input), attr 'scale_available', value '0.000598 0.001196 0.002392 0.004785'
root@tsimx6ul:~# iio_attr -c ism330dhcx_accel accel_y
dev 'ism330dhcx_accel', channel 'accel_y' (input), attr 'injection_raw', ERROR: Permission denied (-13)
dev 'ism330dhcx_accel', channel 'accel_y' (input), attr 'raw', value '-292'
dev 'ism330dhcx_accel', channel 'accel_y' (input), attr 'scale', value '0.000598'
dev 'ism330dhcx_accel', channel 'accel_y' (input), attr 'scale_available', value '0.000598 0.001196 0.002392 0.004785'
root@tsimx6ul:~# iio_attr -c ism330dhcx_accel accel_z
dev 'ism330dhcx_accel', channel 'accel_z' (input), attr 'injection_raw', ERROR: Permission denied (-13)
dev 'ism330dhcx_accel', channel 'accel_z' (input), attr 'raw', value '16491'
dev 'ism330dhcx_accel', channel 'accel_z' (input), attr 'scale', value '0.000598'
dev 'ism330dhcx_accel', channel 'accel_z' (input), attr 'scale_available', value '0.000598 0.001196 0.002392 0.004785'

To get the real world value, multiply the scale * the raw value. In this case:

X: -0.109434 g
Y: -0.174616 g
Z: 9.861618 g

The default scale is ±2, but ±2/±4/±8/±16 can be selected by setting the scale:

dev 'ism330dhcx_accel', channel 'accel_z' (input), attr 'scale', value '0.000598'
dev 'ism330dhcx_accel', channel 'accel_z' (input), attr 'scale_available', value '0.000598 0.001196 0.002392 0.004785'

To set ±4, you would write the second available scale:

iio_attr -c ism330dhcx_accel accel_x scale 0.001196

The scale values are not independent on this device, and setting x/y/z will set the scale for all 3.

This driver also supports pulling continuous samples using the buffer interface. These can be accessed using iio_readdev:

iio_readdev ism330dhcx_accel -T 0 -s 128 > samples.bin

The format of this file is specified with iio_attr:

root@tsimx6ul:~# iio_attr -c ism330dhcx_accel
dev 'ism330dhcx_accel', channel 'accel_x' (input, index: 0, format: le:S16/16>>0), found 4 channel-specific attributes
dev 'ism330dhcx_accel', channel 'accel_y' (input, index: 1, format: le:S16/16>>0), found 4 channel-specific attributes
dev 'ism330dhcx_accel', channel 'accel_z' (input, index: 2, format: le:S16/16>>0), found 4 channel-specific attributes
dev 'ism330dhcx_accel', channel 'timestamp' (input, index: 3, format: le:S64/64>>0), found 0 channel-specific attributes

The samples are padded to the nearest 8-bytes, so this means the binary format is:

Bits	Description
15:0	accel_x, little endian, signed
15:0	accel_y, little endian, signed
15:0	accel_z, little endian, signed
63:0	timestamp, little endian, signed
15:0	Padding

The unix utility hexdump supports formatting options which can parse these fields:

root@tsimx6ul:~# hexdump samples.bin --format '1/2 "X:%d " 1/2 "Y:%d " 1/2 "Z:%d " 1/8 "TS:%d" 1/2 "" "\n"' | head -n 4
X:-95 Y:-163 Z:8221 TS:200185381271666439
X:-107 Y:-147 Z:8248 TS:200190332264480519
X:-100 Y:-155 Z:8263 TS:200195283888013063
X:-95 Y:-159 Z:8253 TS:200200232540667655

This gives the raw values which can then be multiplied by the scale to get the real world value.

The IIO library can also be used to fill buffers with samples for processing. For example:

#!/usr/bin/env python3

import struct
import iio

ctx = iio.Context('local:')
ctx.set_timeout(0)
dev = ctx.find_device('ism330dhcx_accel')

with open(f'/sys/bus/iio/devices/{dev.id}/sampling_frequency', 'w') as f:
	f.write(f"833.000")

for chan_name in ["accel_x", "accel_y", "accel_z"]:
	chn = dev.find_channel(chan_name)
	chn.enabled = True

# We will request 64 samples at a time
buffer = iio.Buffer(dev, 64, False)
# sample size (3x 16-bit signed data)
sample_size = 6
# Refill and process the buffer
buffer.refill()
data = buffer.read()
for i in range(0, len(data), sample_size):
	if i + sample_size <= len(data):
		x, y, z = struct.unpack('<hhh', data[i:i+sample_size])
		print(f'  accel_x={x}, accel_y={y}, accel_z={z}')

for chn in dev.channels:
	chn.enabled = False

This can also be done using the C library:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <iio.h>

#define NUM_CHANNELS 3
#define SAMPLE_SIZE 6 // 3x 16-bit signed data (2 bytes per axis)

void process_samples(struct iio_buffer *buffer, size_t sample_size) {
    char *data = iio_buffer_start(buffer);
    size_t buffer_size = iio_buffer_end(buffer) - iio_buffer_start(buffer);
    int16_t x, y, z;

    for (size_t i = 0; i < buffer_size; i += sample_size) {
        memcpy(&x, &data[i], sizeof(x));
        memcpy(&y, &data[i + sizeof(x)], sizeof(y));
        memcpy(&z, &data[i + 2 * sizeof(x)], sizeof(z));
        printf("accel_x=%d, accel_y=%d, accel_z=%d\n", x, y, z);
    }
}

int main() {
    struct iio_context *ctx;
    struct iio_device *dev;
    struct iio_channel *channels[NUM_CHANNELS];
    struct iio_buffer *buffer;
    const char *channel_names[NUM_CHANNELS] = { "accel_x", "accel_y", "accel_z" };

    // Create context and find device
    ctx = iio_create_local_context();
    if (!ctx || !(dev = iio_context_find_device(ctx, "ism330dhcx_accel")) &&
        !(dev = iio_context_find_device(ctx, "ism330dlc_accel"))) {
        fprintf(stderr, "Unable to create context or find device\n");
        iio_context_destroy(ctx);
        return 1;
    }

    // Enable channels and set sampling frequency
    for (int i = 0; i < NUM_CHANNELS; i++) {
        channels[i] = iio_device_find_channel(dev, channel_names[i], false);
        if (!channels[i] || iio_channel_attr_write(channels[i], "sampling_frequency", "833.000") < 0) {
            fprintf(stderr, "Unable to find or configure channel %s\n", channel_names[i]);
            iio_context_destroy(ctx);
            return 1;
        }
        iio_channel_enable(channels[i]);
    }

    // Create buffer and process samples
    buffer = iio_device_create_buffer(dev, 64, false);
    if (!buffer || iio_buffer_refill(buffer) < 0) {
        fprintf(stderr, "Unable to create or refill buffer\n");
        iio_context_destroy(ctx);
        return 1;
    }

    process_samples(buffer, SAMPLE_SIZE);

    // Cleanup
    iio_buffer_destroy(buffer);
    iio_context_destroy(ctx);

    return 0;
}

Gyroscope (ST ISM330)

This platform features an ST ism330dhcx accelerometer / gyroscope. The gyroscope has a selectable angular range of ±125/±250/±500/±1000/±2000 dps

The gyroscope is accessed through IIO with channels:

anglvel_x
anglvel_y
anglvel_z
timestamp

Magnetometer (ST IIS2MDCTR)

This board includes an ST IIS2MDCTR 3-axis magnetometer, which has a magnetic field dynamic range of ±50 gauss (16 bits of precision at up to 150 Hz).

The magnetometer is accessed through Linux's industrial I/O (IIO) subsystem as iis2mdc with channels:

magn_x
magn_y
magn_z
timestamp

For example:

root@tsimx6ul:~# iio_attr -c iis2mdc -c magn_x
dev 'lis2mdl_magn', channel 'magn_x' (input), attr 'raw', value '630'
dev 'lis2mdl_magn', channel 'magn_x' (input), attr 'scale', value '0.001500'
root@tsimx6ul:~# iio_attr -c iis2mdc -c magn_y
dev 'lis2mdl_magn', channel 'magn_y' (input), attr 'raw', value '-165'
dev 'lis2mdl_magn', channel 'magn_y' (input), attr 'scale', value '0.001500'
root@tsimx6ul:~# iio_attr -c iis2mdc -c magn_z
dev 'lis2mdl_magn', channel 'magn_z' (input), attr 'raw', value '9'
dev 'lis2mdl_magn', channel 'magn_z' (input), attr 'scale', value '0.001500'

note

The 5.10 LTS kernel did not have the same "iis2mdc" driver, but uses a drop in under the name "lis2mdl". use this as the device name on 5.10 instead.

This shows a snapshot of the x, y, z values. To get the measured field strength along each axis, multiply the scale by the raw value to get the actual reading in milligauss. In the above example:

X: 0.945 mG (milligauss)
Y: -0.2475 mG
Z: 0.0135 mG

Interrupts

This section is incomplete in the upstream manual at this time.

LEDs

LEDs can be manipulated from userspace using the LED sysfs interface. The LEDs have 4 behaviors from default software:

Green Behavior	Red behavior	Meaning
Solid On	Off	The kernel has booted and the system is running.
Off	Solid On	The unit has powered on and is in the bootloader.
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 Timer section for more details.
Off	Off	The device is unable to boot. Typically either it is not being supplied with enough voltage, or the unit has been otherwise damaged. If a stable voltage is being provided and the supply is capable of providing at least 1A to the unit, an RMA is suggested.
Off	Blinking about 5ms on, about 10ms off.	The device is receiving too little power, or something is drawing too much current from the unit's power rails causing the unit to reboot consistently.

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/red-led/brightness

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.

We also use the LED control system to control a number of DIO pins which need to have their default state specified. See the DIO section for more information on this.

MicroSD Interface

The i.MX6UL SD card controller internal to the CPU provides support for microSD cards and is fully compliant with the SD specification. 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

Supervisory Microcontroller

note

The supervisory features are supported in Linux kernel 5.10 and later, and on PCB revision C and later.

The TS-7250-V3 includes a preprogrammed supervisory microcontroller that manages the SBC power state, RTC, reset controller, selected ADC rails, and USB console functionality.

The console routing can be inspected from sysfs:

cat /sys/bus/i2c/devices/0-0010/console_cfg

Setting	Description
`auto`	Console routes to DB9 by default, but routes to USB when a microUSB cable is connected
`always-usb`	Console is only available on USB and does not route to DB9

The setting is persistent:

echo "always-usb" > /sys/bus/i2c/devices/0-0010/console_cfg

Any time the console is routed to USB instead, ttyS8 is routed to the DB9 port for application use.

SPI

The TS-7250-V3 FPGA includes two OpenCores SPI controllers. Under Linux these are spi4 and spi5.

Controller	Chip select	Device
`spi4`	0	`/dev/spidev4.0`, DIO header SPI bus
`spi4`	1	FRAM
`spi4`	2	FPGA flash, `/dev/mtdblock0`
`spi5`	0	`/dev/spidev5.0`, mikroBUS SPI

warning

Do not manipulate the FPGA flash unless instructed by embeddedTS support. Erasing it can require an RMA to recover.

The /dev/spidev* devices can be accessed from Linux using the kernel spidev API. Bindings are available for C, Python, Rust, and JavaScript.

UARTs

The TS-7250-V3 includes CPU UARTs and FPGA 16550A-compatible UARTs.

UART device	Type	TX / + location	RX / - location	CTS	RTS	DCD	DTR	TXEN
`ttymxc0`	USB console	P2 MicroUSB	P2 MicroUSB	N/A	N/A	N/A	N/A	N/A
`ttymxc2`	Bluetooth	Onboard	Onboard	N/A	N/A	N/A	N/A	N/A
`ttymxc3`	3.3 V TTL	XBEE pin 3	XBEE pin 2	XBEE pin 12	N/A	N/A	N/A	N/A
`ttyS8`	RS-232	DB9 pin 3	DB9 pin 2	DB9 pin 8	DB9 pin 7	DB9 pin 1	DB9 pin 4	N/A
`ttyS9`	RS-232	COM2 pin 3	COM2 pin 2	COM2 pin 8	COM2 pin 7	N/A	N/A	N/A
`ttyS10`	RS-232	COM3 pin 3	COM3 pin 2	COM3 pin 8	COM3 pin 7	N/A	N/A	N/A
`ttyS11`	RS-485	COM2 pin 1	COM2 pin 6	N/A	N/A	N/A	N/A	N/A
`ttyS12`	RS-485	COM2 pin 4	COM2 pin 9	N/A	N/A	N/A	N/A	N/A
`ttyS13`	TTL	mikroBUS pin 13	mikroBUS pin 14	N/A	N/A	N/A	N/A	N/A
`ttyS14`	TTL	DIO pin 5	DIO pin 7	N/A	N/A	N/A	N/A	DIO pin 13
`ttyS15`	TTL	DIO pin 9	DIO pin 11	N/A	N/A	N/A	N/A	DIO pin 15

The DIO header UARTs are disabled by default. Enable the mux before using ttyS14 and ttyS15:

tshwctl --address 0x08 --poke32 0x6000

USB

The TS-7250-V3 offers two USB 2.0 host ports. The USB A host stack can provide 1 A total power shared between the two ports.

The lower USB host port can be routed to the XBEE header for USB cellular modems:

# Route USB to XBEE
gpioset 209c000.gpio 11=1

# Route USB to the lower Type-A host port, the default
gpioset 209c000.gpio 11=0

USB host power can be controlled to save power or reboot peripherals:

gpioset 20a4000.gpio 0=0 # Turn off USB power
gpioset 20a4000.gpio 0=1 # Turn on USB power

Watchdog

The board implements a WDT inside the supervisory microcontroller. A standard kernel WDT driver is in place that feeds the WDT via the I2C bus. 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. If this does not happen then the WDT is not stopped and it will continue it's countdown. 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.

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

External Interfaces

Interface	Connector type	Description	Reference
ADC	2 x 5 pin header	Five 0-30 V ADC channels, three optional 0-20 mA current loops	Reference
Battery	Vertical coin cell holder	RTC backup battery	Reference
COM2	2 x 5 pin header	RS-485, RS-422, and RS-232	Reference
COM3	2 x 5 pin header	CAN and RS-232	Reference
DB9	DE-9 connector	Full-handshake RS-232	Reference
DIO	2 x 8 pin header	SPI, GPIO, optional DIO UARTs	Reference
LCD	2 x 7 pin header	HD44780-compatible LCD interface	Reference
mikroBUS	2 x 8 pin header	Mikroe Click board socket	Reference
MicroUSB	MicroUSB	USB console	Reference
PC/104	104-pin PC/104 header	ISA-compatible PC/104 bus	Reference
Power	Removable terminal blocks	5 VDC and 8-48 VDC inputs	Reference
USB	Dual USB Type-A	USB 2.0 host ports	Reference
XBEE	2 x 10 pin header	Digi XBEE / NimbeLink-style socket	Reference

ADC Header

The ADC header supports five 0-30 VDC ADC channels. Channels 1-3 also support 0-20 mA current loop sampling.

iio_attr -c 2198000.adc voltage0
iio_attr -c 2198000.adc voltage1
iio_attr -c 2198000.adc voltage5
iio_attr -c 2198000.adc voltage8
iio_attr -c 2198000.adc voltage9

Pin	Signal
1	`2198000.adc/voltage0`
2	GND
3	`2198000.adc/voltage1`
4	GND
5	`2198000.adc/voltage5`
6	GND
7	`2198000.adc/voltage8`
8	GND
9	`2198000.adc/voltage9`, `WAKE_UP#`
10	GND

Battery Connector

The battery connector holds a removable CR1632 coin cell for the battery-backed RTC. Insert the cell from the top of the holder with the positive lead oriented as marked on the board.

COM2 Header

The COM2 header is a 0.1 inch pitch 2 x 5 header supporting RS-485, RS-422, and RS-232.

Pin	Signal
1	`ttyS11` RS-485+
2	`ttyS9` RS-232 RXD
3	`ttyS9` RS-232 TXD
4	`ttyS12` RS-485+
5	GND
6	`ttyS11` RS-485-
7	`ttyS9` RS-232 RTS
8	`ttyS9` RS-232 CTS
9	`ttyS12` RS-485-
10	NC

COM3 Header

The COM3 header is a 0.1 inch pitch 2 x 5 header supporting CAN and RS-232.

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

DB9 Connector

The DB9 connector provides a full-handshake RS-232 port.

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

DIO Header

The DIO header is a 0.1 inch pitch 2 x 8 header with SPI, GPIO, and optional DIO UART functions. All pins are 5 V tolerant except SPI output pins. SPI input pins are 5 V tolerant.

Pin	IO Type	Signal
1	FPGA 3.3-V LVTTL+QS3861	GPIO chip `50004010.fpga_gpio` IO 1
2		GND
3	FPGA 3.3-V LVTTL+QS3861	GPIO chip `50004010.fpga_gpio` IO 2
4	Open drain	Current sink output, chip `209c000.gpio` IO 30
5	FPGA 3.3-V LVTTL+QS3861	GPIO chip `50004010.fpga_gpio` IO 3 / `ttyS14` TX
6	FPGA 3.3-V LVTTL	`spidev4.0` CS / GPIO chip `50004010.fpga_gpio` IO 11
7	FPGA 3.3-V LVTTL+QS3861	GPIO chip `50004010.fpga_gpio` IO 4 / `ttyS14` RX
8	FPGA 3.3-V LVTTL+QS3861	GPIO chip `50004010.fpga_gpio` IO 5
9	FPGA 3.3-V LVTTL+QS3861	GPIO chip `50004010.fpga_gpio` IO 6 / `ttyS15` TX
10	FPGA 3.3-V LVTTL+QS3861	`spidev4.0` MISO / GPIO chip `50004010.fpga_gpio` IO 10
11	FPGA 3.3-V LVTTL+QS3861	GPIO chip `50004010.fpga_gpio` IO 7 / `ttyS15` RX
12	FPGA 3.3-V LVTTL	`spidev4.0` MOSI / GPIO chip `50004010.fpga_gpio` IO 15
13	FPGA 3.3-V LVTTL+QS3861	GPIO chip `50004010.fpga_gpio` IO 8 / `ttyS14` TXEN
14	FPGA 3.3-V LVTTL	`spidev4.0` CLK / GPIO chip `50004010.fpga_gpio` IO 14
15	FPGA 3.3-V LVTTL+QS3861	GPIO chip `50004010.fpga_gpio` IO 9 / `ttyS15` TXEN
16		3.3 V

The DIO UARTs are enabled through the FPGA syscon mux:

tshwctl --address 0x08 --poke32 0x6000

Ethernet Connectors

The TS-7250-V3 provides two 10/100 Ethernet ports. Linux exposes these as eth0 and eth1.

LCD Header

The LCD header is a 0.1 inch pitch 2 x 7 header designed around HD44780-compatible LCD modules such as the embeddedTS LCD-LED. The Debian images include lcdmesg.

lcdmesg "line 1" "line 2"
echo -e "line 1\nline 2\n" | lcdmesg

Pin	IO Type	Signal
1		5 V
2		GND
3	CPU 3.3 V	LCD_RS, GPIO chip `20a4000.gpio` IO 21
4	CPU 3.3 V	LCD_BIAS, PWM duty cycle controlled by FPGA syscon register `0x1c`
5	CPU 3.3 V	LCD_EN, GPIO chip `20a4000.gpio` IO 20
6	CPU 3.3 V	LCD_WR, GPIO chip `20a4000.gpio` IO 19
7	CPU 3.3 V+QS3861	LCD_D1, GPIO chip `20a4000.gpio` IO 9
8	CPU 3.3 V+QS3861	LCD_D0, GPIO chip `20a4000.gpio` IO 10
9	CPU 3.3 V+QS3861	LCD_D3, GPIO chip `20a4000.gpio` IO 11
10	CPU 3.3 V+QS3861	LCD_D2, GPIO chip `20a4000.gpio` IO 12
11	CPU 3.3 V+QS3861	LCD_D5, GPIO chip `20a4000.gpio` IO 15
12	CPU 3.3 V+QS3861	LCD_D4, GPIO chip `20a4000.gpio` IO 16
13	CPU 3.3 V+QS3861	LCD_D7, GPIO chip `20a4000.gpio` IO 17
14	CPU 3.3 V+QS3861	LCD_D6, GPIO chip `20a4000.gpio` IO 18

mikroBUS Header

The mikroBUS header is a 0.1 inch pitch 2 x 8 socket supporting the Mikroe Click board ecosystem. It provides 3.3 V, 5 V, SPI, GPIO, ADC, PWM, UART, and I2C. All I/O on this header is FPGA 3.3-V LVTTL.

By default, pins use their non-GPIO functions. FPGA syscon register 0x08 can change the muxing:

# Make all mikroBUS header pins GPIO
memtool mw -l 0x50004008 0xF0

# Set only SPI to GPIO
memtool mw -l 0x50004008 0x10

Pin	Name	Description
1	AN	FPGA ADC / GPIO chip `50004054.fpga_gpio` IO 1
2	RST	GPIO chip `50004054.fpga_gpio` IO 0
3	CS	`spidev5.0` CS / GPIO chip `50004054.fpga_gpio` IO 5
4	SCK	`spidev5.0` CLK / GPIO chip `50004054.fpga_gpio` IO 4
5	MISO	`spidev5.0` MISO / GPIO chip `50004054.fpga_gpio` IO 3
6	MOSI	`spidev5.0` MOSI / GPIO chip `50004054.fpga_gpio` IO 2
7	3.3V	3.3 V
8	GND	Ground
9	PWM	FPGA PWM / GPIO chip `50004054.fpga_gpio` IO 6
10	INT	GPIO chip `50004054.fpga_gpio` IO 7
11	RX	`ttyS13` RX
12	TX	`ttyS13` TX
13	SCL	`/dev/i2c-4` SCL
14	SDA	`/dev/i2c-4` SDA
15	5V	5 V
16	GND	Ground

MicroSD Connector

The microSD connector is available as U-Boot device mmc1 and as Linux media when a card is inserted. U-Boot searches it after USB and before the on-board eMMC.

MicroUSB Connector

The microUSB connector provides the supervisory microcontroller USB serial console. Linux hosts typically enumerate it as /dev/ttyACM0 or under /dev/serial/by-id/.

PC104 Header

The PC/104 header exposes the FPGA ISA-compatible bus. Use the Linux fpgaisa files or pc104_peekpoke utility rather than directly manipulating FPGA registers.

Access file	Description
`io8`	8-bit I/O cycles
`io16`	16-bit I/O cycles
`ioalt16`	16-bit I/O cycles using the alternate TS pinout
`mem8`	8-bit memory cycles
`mem16`	16-bit memory cycles
`memalt16`	16-bit memory cycles using the alternate TS pinout

warning

Do not use third-party PC/104 power supplies. The -12 V and -5 V rails are incompatible with this PC/104 implementation.

Power Connectors

The TS-7250-V3 provides two power inputs on removable 2-pin terminal blocks. Only one power input may be connected at a time.

Connector	Input range
CN2	5 VDC
CN12	8-48 VDC

The PCB is marked with polarity under the removable terminal blocks. A typical power supply should provide at least 10 W.

note

Some PCB silkscreens show 8-28V on the high-voltage input, but every PCB revision from Rev. A forward supports 8-48 VDC.

USB Ports

The TS-7250-V3 has two USB Type-A host ports. The lower host port can optionally be routed to the XBEE header for USB cellular modems.

# Route USB to XBEE
gpioset 209c000.gpio 11=1

# Route USB to the lower Type-A host port
gpioset 209c000.gpio 11=0

USB power can also be controlled:

gpioset 20a4000.gpio 0=0 # Turn off USB power
gpioset 20a4000.gpio 0=1 # Turn on USB power

XBEE Header

The CN20 header is a 2 mm pitch 2 x 10 socket supporting XBEE form-factor modules including Digi radios and NimbeLink-style cellular modems.

note

Review the target module datasheet before use. Some XBEE-form-factor modules vary from the mechanical and electrical conventions used by other vendors.

For USB cellular radios, route USB to the socket:

gpioset 209c000.gpio 11=1

Only enable the power rail that matches the module:

# For 3.3 V modules
gpioset 50004040.fpga_gpio 4=1

# For 4 V modules
gpioset 50004040.fpga_gpio 11=1

Pin	IO Type	Signal
1		VCC, XBEE_3.3V or NIMBEL_4.7V
2	CPU 3.3 V	`ttymxc3` RXD
3	CPU 3.3 V	`ttymxc3` TXD
4		GND
5	Open drain	GPIO chip `209c000.gpio` IO 10
6		NIMBEL_4.7V
7		USB_XBEE_P
8		USB_XBEE_N
9		GND
10		GND
11		GND
12	CPU 3.3 V	`ttymxc3` CTS#
13	Open drain	GPIO chip `20a4000.gpio` IO 2
14		3.3 V VREF
15		GND
16		GND
17		NC
18		NC
19		NC
20	Open drain	GPIO chip `209c000.gpio` IO 31

Specifications

IO Specifications

IO Type	Voltage max	Absolute max	Source current	Sink current	VIL	VIH
CPU 3.3V	3.3 V	3.6 V			0.99 V	2.31 V
CPU 3.3V+QS3861	5 V	7 V
FPGA 3.3-V LVTTL	3.3 V	3.6 V	6 mA	6 mA
FPGA 3.3-V LVTTL+QS3861	5 V	7 V	6 mA	6 mA
PCA9555	5.3 V	6 V	25 mA max per IO, 100 mA per octal bank, 160 mA total	8-24 mA	0.3 V	2.31 V

Power Consumption

The i.MX6UL CPU can change frequency as needed to reduce power or provide more processing headroom. Ethernet power savings can be improved by briefly bringing interfaces up and down during startup:

ifconfig eth0 up
ifconfig eth1 up
ifconfig eth0 down
ifconfig eth1 down
ifconfig wlan0 up # only needed if Wi-Fi is present

The following tests used the 5 V input, no external connections except power, eMMC boot, and an idle prompt unless otherwise noted.

Test	Avg. (W)	Peak (W)
Idle	0.77	1.29
CPU fully loaded with `stress-ng --matrix 0 -t 60m`	1.03	1.45
CPU idle, single Ethernet port up and active with `iperf`	1.17	1.75
CPU fully loaded and single Ethernet port up and active	1.40	2.03
Supervisory microcontroller sleep mode, ARM CPU off	0.055	0.063

Power Input Specifications

The TS-7250-V3 supports the 5 VDC input on CN2 and the 8-48 VDC input on CN12. The 8-48 VDC input can also come from the PC/104 connector's +12V signal.

Input	Min range	Max range
5 VDC	4.7 VDC	5.2 VDC
8-48 VDC	8 VDC	48 VDC

note

The CN12 power connector silkscreen may show 8-28V; every PCB revision from Rev. A forward supports the full 8-48 VDC range.

Backup / Restore

While all of our products ship with images pre-loaded in to any supplied media, there are many situations where new images may need to be written. For example, to restore a device to its factory settings or apply a customized image/filesystem for application deployment. Additionally, specific units may be used for development and that unit's disk images need to be replicated to other units to be deployed in the field.

We offer a number of different ways to accomplish both capturing images to be written to other units, and the actual writing process itself. See the section on our USB Image Replicator tool to capture and/or write images, as well as details on manual processes to capture and write images on each of this device's media.

Installing​

Building​

Cross Compiling​

Configuring the Network​

Installing New Software​

Setting Up SSH​

Starting Software Automatically​

Features​

ADC​

Bluetooth​

CAN​

CPU​

GPIO​

eMMC Interface​

Ethernet Ports​

FEC PTP Support​

FPGA​

PC/104 Bus​

FRAM​

I2C​

IMU​

Accelerometer (ST ISM330)​

Gyroscope (ST ISM330)​

Magnetometer (ST IIS2MDCTR)​

Interrupts​

LEDs​

MicroSD Interface​

Supervisory Microcontroller​

SPI​

UARTs​

USB​

Watchdog​

WiFi​

External Interfaces​

ADC Header​

Battery Connector​

COM2 Header​

COM3 Header​

DB9 Connector​

DIO Header​

Ethernet Connectors​

LCD Header​

mikroBUS Header​

MicroSD Connector​

MicroUSB Connector​

PC104 Header​

Power Connectors​

USB Ports​

XBEE Header​

Specifications​

IO Specifications​

Power Consumption​

Power Input Specifications​

Backup / Restore​

Installing

Building

Cross Compiling

Configuring the Network

Installing New Software

Setting Up SSH

Starting Software Automatically

Features

ADC

Bluetooth

CAN

CPU

GPIO

eMMC Interface

Ethernet Ports

FEC PTP Support

FPGA

PC/104 Bus

FRAM

I2C

IMU

Accelerometer (ST ISM330)

Gyroscope (ST ISM330)

Magnetometer (ST IIS2MDCTR)

Interrupts

LEDs

MicroSD Interface

Supervisory Microcontroller

SPI

UARTs

USB

Watchdog

WiFi

External Interfaces

ADC Header

Battery Connector

COM2 Header

COM3 Header

DB9 Connector

DIO Header

Ethernet Connectors

LCD Header

mikroBUS Header

MicroSD Connector

MicroUSB Connector

PC104 Header

Power Connectors

USB Ports

XBEE Header

Specifications

IO Specifications

Power Consumption

Power Input Specifications

Backup / Restore