TS-7250-V3 Hardware Manual Test 2

From embeddedTS Manuals
WARNING: This is not the current latest manual for the TS-7250-V3, this is a page for testing new manual layouts. Please return to the TS-7250-V3 manual for the latest up to date manual!
TS-7250-V3
ts-7250-v3.gif
Product Page
Documentation
Schematic
FTP Path
Processor
NXP i.MX6UL
696 MHz Arm® Cortex®-A7
i.MX6UL Product Page
CPU Documentation


Overview

The TS-7250-V3 is a PC/104 form factor SBC with a PC/104 bus, mikroBUS socket, Digi XBee header, soldered down eMMC flash, dual Ethernet, microSD socket, and a Wi-Fi/Bluetooth LE module. This platform also provides a migration path from the TS-7250-V2 and TS-7250 series systems.


Feature Comparison

This platform has multiple hardware variants, please see the TS-7250-V3 product configurations for a comparison of the feature sets by model.


Physical description / connectors / something

IMAGE OF PLATFORM HERE WITH CONNECTORS ANNOTATED IN SOME WAY



Table of different components/features/connectors linked to sections below?

I like the idea of maybe different sections within the table Something like

System I/O

Feature Description Location
ADC ADC input A/D Header / CN8

Node Description Location? Jumpers and LEDs jp block | What its for | CNwhatever LED1,2,3 | What they do | CNwhtever Power in | Power input | ... Batt | battery for RTC | ... ? Storage emmc | soldered down | eMMC? sd | SD socket | CNwhatever System IO eth | eth | Twhatever cpu? | cpu | What? USB | usb | CNwhatever CAN | Can interface | COM3 / CN11 ? etc.





Features

ADC

This platform has 5 channels of 12-bit ADC via the i.MX6UL CPU. All channels can sample 0-30 VDC, with channels 1-3 selectively able to sample 0-20 mA current loop input. To minimize noise, the ADC pins use a dedicated analog ground available on the even pins of the header. See the ADC Header section for more details.

The current loop measurement can be dynamically enabled by setting the relevant GPIO pin to a logical 1.

ADC Header Pin Schematic Name ADC Base Register Address ADC Channel Voltage Range Current Range Current Loop Enable GPIO Bank Address Current Loop Enable GPIO Pin
1 AN_CH1 0x02198000 0 0-30 VDC 0-20 mA 0x020AC000 7
3 AN_CH2 0x02198000 1 0-30 VDC 0-20 mA 0x020AC000 8
5 AN_CH3 0x02198000 5 0-30 VDC 0-20 mA 0x020AC000 9
7 AN_CH4 0x02198000 8 0-30 VDC N/A N/A N/A
8 AN_CH5 0x02198000 9 0-30 VDC N/A N/A

Bluetooth

The TS-7250-V3 supports Bluetooth 5.0 LE via the WILC3000 Wi-Fi / Bluetooth module.

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

See the software manual for the software image in use (boy that needs to be worded better) for more information on bringing up and testing the interface.

Once enabled and firmware loaded, the Bluetooth interface is available on the UART device /dev/ttymxc2 at 115200 baud with no flow control.

CAN

The i.MX6UL CPU has two FlexCAN ports which are available on the COM3 Header / CN11.

Both ports conform to CAN 2.0B and ISO 11898 specifications, allowing for communication at speeds up to 1 Mbaud with high noise immunity.

CAN interfaces on the TS-7250-V3 do not provide built-in bus termination resistors. This allows the interfaces to be placed anywhere along the CAN bus. Termination resistors should be added at the ends of the CAN bus where required.


In software, the hardware CAN1 interface will resolve as the first port. For example, in Linux this is the network interface can0. The hardware CAN2 interface resolves as the second interface.

See the corresponding software manual for information on interfacing with the CAN hardware (this needs to be reworded and linked better).

CPU

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

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


GPIO

The i.MX6UL CPU and FPGA GPIO are exposed using the gpiod interface.


See the software manual for the software image in use (boy that needs to be worded better) for more information on interfacing with GPIO pins.


CPU GPIO

Schematic Net Name GPIO Bank Base Register GPIO Pin Location
AN_CH1 0x0209C000 0 ADC Pin 1
AN_CH2 0x0209C000 1 ADC Pin 3
EN_SD_CARD_3.3V [1] 0x0209C000 4 Onboard
AN_CH3 0x0209C000 5 ADC Pin 5
AN_CH4 0x0209C000 8 ADC Pin 7
AN_CH5 0x0209C000 9 ADC Pin 9
SEL_XBEE_USB [2] 0x0209C000 11 Onboard USB MUX
FPGA_RESET [3] 0x0209C000 13 Onboard
EN_RED_LED# [4] 0x0209C000 18 Onboard LED5
EN_GRN_LED# [4] 0x0209C000 19 Onboard LED2
EN_XBEE_USB [1] 0x0209C000 21 Onboard
UART4_TXD 0x0209C000 28 Modem UART
UART4_RXD 0x0209C000 29 Modem UART
EN_DIO_FET 0x0209C000 30 DIO Header pin 4
NIM_PWR_ON 0x0209C000 31 Onboard
EN_USB_5V [5] 0x020A4000 0 Onboard
ISA_RESET 0x020A4000 7 PC104 B2
ISA_IOCHK 0x020A4000 8 PC104 A1
LCD_PIN7 0x020A4000 9 LCD Header pin 7
LCD_PIN8 0x020A4000 10 LCD Header pin 8
LCD_PIN9 0x020A4000 11 LCD Header pin 9
LCD_PIN10 0x020A4000 12 LCD Header pin 10
LCD_PIN11 0x020A4000 15 LCD Header pin 11
LCD_PIN12 0x020A4000 16 LCD Header pin 12
LCD_PIN13 0x020A4000 17 LCD Header pin 13
LCD_PIN14 0x020A4000 18 LCD Header pin 14
LCD_WR# 0x020A4000 19 LCD Header pin 6
LCD_EN 0x020A4000 20 LCD Header pin 5
LCD_RS 0x020A4000 21 LCD Header pin 3
SYS_RESET# [6] 0x020A4000 22 Onboard
FPGA_FLASH_SELECT [1] 0x020A8000 0 Onboard
DETECT_94-120 [1] 0x020A8000 1 Onboard
EN_EMMC_3.3V [1] 0x020AC000 2 Onboard eMMC
WIFI_RESET# 0x020AC000 5 Onboard WIFI
EN_WIFI_PWR 0x020AC000 6 Onboard WIFI
EN_CL_1 0x020AC000 7 ADC Current loop enable
EN_CL_2 0x020AC000 8 ADC Current loop enable
EN_CL_3 0x020AC000 9 ADC Current loop enable


FPGA GPIO

Schematic Net Name GPIO Bank Base Register GPIO Pin Location
DIO_PIN1 0x50004010 1 DIO Header pin 1
DIO_PIN3 0x50004010 2 DIO Header pin 3
DIO_PIN5 0x50004010 3 DIO Header pin 5
DIO_PIN7 0x50004010 4 DIO Header pin 7
DIO_PIN8 0x50004010 5 DIO Header pin 8
DIO_PIN9 0x50004010 6 DIO Header pin 9
DIO_PIN11 0x50004010 7 DIO Header pin 11
DIO_PIN13 0x50004010 8 DIO Header pin 13
DIO_PIN15 0x50004010 9 DIO Header pin 15
DIO_SPI_MISO [7] 0x50004010 10 SPI MISO
DIO_SPI_CS# [8] 0x50004010 11 DIO Header pin 6
DIO_SPI_CLK [8] 0x50004010 14 DIO Header pin 14
DIO_SPI_MOSI [8] 0x50004010 15 DIO Header pin 12
ISA_AEN [9] 0x50004040 0 PC104 Header pin A11
ISA_BALE 0x50004040 1 PC104 Header pin B28
ISA_TC 0x50004040 2 PC104 Header pin B27
ISA_ENDX 0x50004040 3 PC104 Header pin B08
EN_NIMBEL_3V3 0x50004040 4 Skywire VIN voltage
ISA_IORDY 0x50004040 5 PC104 Header pin A10
ISA_REFRESH 0x50004040 6 PC104 Header pin B19
ISA_DRQ1 0x50004040 7 PC104 Header pin B18
ISA_DACK1 0x50004040 8 PC104 Header pin B17
ISA_DRQ2 0x50004040 9 PC104 Header pin B06
ISA_DACK2 0x50004040 10 PC104 Header pin B26
EN_NIMBEL_4V 0x50004040 11 Skywire VIN voltage
ISA_DRQ3 0x50004040 12 PC104 Header pin B16
ISA_DACK3 0x50004040 13 PC104 Header pin B15
MIKRO_RESET# 0x50004054 0 mikroBUS Header pin 2
MIKRO_AN 0x50004054 1 mikroBUS Header pin 1
MIKRO_INT 0x50004054 2 mikroBUS Header pin 15
MIKRO_180 [10] 0x50004054 3 Onboard
MIKRO_PWM [11] 0x50004054 4 mikroBUS Header pin 16
MIKRO_SPI_CS# [12] 0x50004054 5 mikroBUS Header pin 3
MIKRO_SPI_CLK [12] 0x50004054 6 mikroBUS Header pin 4
MIKRO_SPI_MISO [12] 0x50004054 7 mikroBUS Header pin 5
MIKRO_SPI_MOSI [12] 0x50004054 8 mikroBUS Header pin 6
MIKRO_TXD [13] 0x50004054 9 mikroBUS Header pin 13
MIKRO_RXD [13] 0x50004054 10 mikroBUS Header pin 14
MIKRO_I2C_DAT [14] 0x50004054 11 mikroBUS Header pin 11
MIKRO_I2C_CLK [14] 0x50004054 12 mikroBUS Header pin 12
ISA_DAT00 [9] 0x5000405C 0 PC104 Header pin A9
ISA_DAT01 [9] 0x5000405C 1 PC104 Header pin A8
ISA_DAT02 [9] 0x5000405C 2 PC104 Header pin A7
ISA_DAT03 [9] 0x5000405C 3 PC104 Header pin A6
ISA_DAT04 [9] 0x5000405C 4 PC104 Header pin A5
ISA_DAT05 [9] 0x5000405C 5 PC104 Header pin A4
ISA_DAT06 [9] 0x5000405C 6 PC104 Header pin A3
ISA_DAT07 [9] 0x5000405C 7 PC104 Header pin A2
ISA_DAT08 [9] 0x5000405C 8 PC104 Header pin C11
ISA_DAT09 [9] 0x5000405C 9 PC104 Header pin C12
ISA_DAT10 [9] 0x5000405C 10 PC104 Header pin C13
ISA_DAT11 [9] 0x5000405C 11 PC104 Header pin C14
ISA_DAT12 [9] 0x5000405C 12 PC104 Header pin C15
ISA_DAT13 [9] 0x5000405C 13 PC104 Header pin C16
ISA_DAT14 [9] 0x5000405C 14 PC104 Header pin C17
ISA_DAT15 [9] 0x5000405C 15 PC104 Header pin C18
ISA_ADD_00 [9] 0x50004064 0 PC104 Header pin A31
ISA_ADD_01 [9] 0x50004064 1 PC104 Header pin A30
ISA_ADD_02 [9] 0x50004064 2 PC104 Header pin A29
ISA_ADD_03 [9] 0x50004064 3 PC104 Header pin A28
ISA_ADD_04 [9] 0x50004064 4 PC104 Header pin A27
ISA_ADD_05 [9] 0x50004064 5 PC104 Header pin A26
ISA_ADD_06 [9] 0x50004064 6 PC104 Header pin A25
ISA_ADD_07 [9] 0x50004064 7 PC104 Header pin A24
ISA_ADD_08 [9] 0x50004064 8 PC104 Header pin A23
ISA_ADD_09 [9] 0x50004064 9 PC104 Header pin A22
ISA_ADD_10 [9] 0x50004064 10 PC104 Header pin A21
ISA_ADD_11 [9] 0x50004064 11 PC104 Header pin A20
ISA_ADD_12 [9] 0x50004064 12 PC104 Header pin A19
ISA_ADD_13 [9] 0x50004064 13 PC104 Header pin A18
ISA_ADD_14 [9] 0x50004064 14 PC104 Header pin A17
ISA_ADD_15 [9] 0x50004064 15 PC104 Header pin A16
ISA_ADD_16 [9] 0x5000406C 0 PC104 Header pin A15
ISA_ADD_17 [9] 0x5000406C 1 PC104 Header pin A14
ISA_ADD_18 [9] 0x5000406C 2 PC104 Header pin A13
ISA_ADD_19 [9] 0x5000406C 3 PC104 Header pin A12
ISA_IOR [9] 0x5000406C 4 PC104 Header pin B14
ISA_IOW [9] 0x5000406C 5 PC104 Header pin B13
ISA_MEMR [9] 0x5000406C 6 PC104 Header pin B12
ISA_MEMW [9] 0x5000406C 7 PC104 Header pin B11


I2C GPIO Expander

This GPIO controller is based on a PCA9555 I2C GPIO expander which provides up to 16 GPIO spread across two ports of 8 pins.

Schematic Net Name I2C Bus I2C Device Address GPIO Port GPIO Pin Location
ISA_CN_D03 2 0x20 0 0 PC104 Header pin D03
ISA_CN_D04 2 0x20 0 1 PC104 Header pin D04
ISA_CN_D05 2 0x20 0 2 PC104 Header pin D05
ISA_CN_D06 2 0x20 0 3 PC104 Header pin D06
ISA_CN_D07 2 0x20 0 4 PC104 Header pin D07
ISA_CN_D08 2 0x20 0 5 PC104 Header pin D08
ISA_CN_D09 2 0x20 0 6 PC104 Header pin D09
ISA_CN_D10 2 0x20 0 7 PC104 Header pin D10
ISA_CN_D11 2 0x20 1 0 PC104 Header pin D11
ISA_CN_D12 2 0x20 1 1 PC104 Header pin D12
ISA_CN_D13 2 0x20 1 2 PC104 Header pin D13
ISA_CN_D14 2 0x20 1 3 PC104 Header pin D14
ISA_CN_D15 2 0x20 1 4 PC104 Header pin D15


  1. ↑ 1.0 1.1 1.2 1.3 1.4 This is controlled automatically on startup to give the SD card a clean reset, but otherwise this should not be toggled manually.
  2. ↑ default is input with pulldown (0). If driven high, this MUXes the bottom port of the dual high USB port to the XBee header. If low or input, no USB is present on this header. This USB is needed for cell modules, but interferes with older serial modules where these USB pins are reserved. See your XBee/Skywire device's datasheet to verify if USB is needed.
  3. ↑ This is handled automatically on startup
  4. ↑ 4.0 4.1 See /sys/class/leds/ for interacting with these LEDs rather than toggling the GPIO directly.
  5. ↑ High by default. This allows power cycling USB peripherals in the field.
  6. ↑ Ethernet PHY and USB hub reset. This is automatically controlled during startup and should not be toggled.
  7. ↑ This pin is input only
  8. ↑ 8.0 8.1 8.2 This pin cannot be controlled as a GPIO until Syscon 0x08 bit 10 is set
  9. ↑ 9.00 9.01 9.02 9.03 9.04 9.05 9.06 9.07 9.08 9.09 9.10 9.11 9.12 9.13 9.14 9.15 9.16 9.17 9.18 9.19 9.20 9.21 9.22 9.23 9.24 9.25 9.26 9.27 9.28 9.29 9.30 9.31 9.32 9.33 9.34 9.35 9.36 9.37 9.38 9.39 9.40 This pin cannot be controlled as a GPIO until Syscon 0x08 bit 8 is set
  10. ↑ This is used to detect if the Mikrobus socket is reversed.
  11. ↑ This pin cannot be controlled as a GPIO until Syscon 0x08 bit 6 is set
  12. ↑ 12.0 12.1 12.2 12.3 This pin cannot be controlled as a GPIO until Syscon 0x08 bit 4 is set
  13. ↑ 13.0 13.1 This pin cannot be controlled as a GPIO until Syscon 0x08 bit 7 is set
  14. ↑ 14.0 14.1 This pin cannot be controlled as a GPIO until Syscon 0x08 bit 5 is set

eMMC

This platform includes a soldered down eMMC flash device for on-board non-volatile storage. Our standard platform configurations use a 4 GB eMMC device, but up to 64 GB are available for customized builds. The eMMC device includes additional boot partitions that are used by U-Boot and are not affected by the disk's partition table.

See the software manual for the software image in use (boy that needs to be worded better) for more information.

ADD DETAILS ON SPEEDS

The default disk layout is as follows:

Device Contents
/dev/mmcblk0 eMMC block device
/dev/mmcblk0boot0 U-Boot
/dev/mmcblk0boot1 Unused
/dev/mmcblk0p1 Full Debian Linux partition

SHOULD THIS MANUAL TALK ABOUT ENH MODES? CREATE ANOTHER MANUAL FOR IT?


Ethernet Ports

The i.MX6UL CPU contains two 10/100 Mbit Ethernet controllers. These are located at the two Ethernet connector jacks on the platform.

The i.MX6UL CPU Ethernet ports support IEEE 1588 Precision Time Protocol (PTP), both Version 1 and 2 (PTPv1 & PTPv2). This allows synchronizing the system clock to within ±1 us across multiple devices on the same network.

See the software manual for the software image in use (boy that needs to be worded better) for more information on utilizing the interfaces as well as setting up PTP.

Ferroelectric RAM (FRAM)

Note: FRAM is not present on the TS-7250-V3-SMN1I or TS-7250-V3-SMN2I configurations.


This device supports an optional 2 KiB of non-volatile Ferroelectric RAM (FRAM) connected to the CPU via SPI. FRAM is non-volatile, incredibly fast to write, and is specified with 1 trillion read/write cycles per each byte with a 200 year data retention. Reads of data from FRAM is a destructive process -- the FRAM's internal controller handles data write-back after a read. Care should be taken to prevent sudden power-off events during both reads and writes of FRAM.

The FRAM is connected to the TS-7250-V3 on SPI bus 4, chip-select 1.

See the software manual for the software image in use (boy that needs to be worded better) for information on interacting with the device.

I2C

The i.MX6UL supports I2C at 100 kHz, or using fast mode for 400 kHz operation. The TS-7250-V3 uses two CPU I2C busses for onboard device, and an FPGA I2C controller for the mikroBUS I2C interface.

See the software manual for the software image in use (boy that needs to be worded better) for more information.

SHOULD WE LIST DEVICE NODES OR BUS NUMBERS/FIRST BUS/SECOND BUS/ETC?

I2C Bus Address Description
i2c0 0x1e Magnetometer
0x54 Supervisory Microcontroller
0x68 RTC
0x6a IMU
i2c1 0x20 NXP pca9555 GPIO expander (Chip 2-0020)
0x64 ATSHA204 LINK TO MORE INFO [1]
  1. ↑ Not populated by default

TODO: Add mikroBUS I2C notes

Inertial Measurement Unit (IMU)

Linux provides access to the various IMU components through the IIO subsystem (via iio-tools and libiio).

Accelerometer (ST ISM330)

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

Early units were built using the "ism330dlc", and newer units are built using the "ism330dhcx". These are functionally the same and provide the same channels and performance, but IIO requires you to specify the part number. Our example python/c code will show how to work with either.

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
# ISM330DLC
iio_attr -c ism330dlc_accel accel_x
iio_attr -c ism330dlc_accel accel_y
iio_attr -c ism330dlc_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') or ctx.find_device('ism330dlc_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 accelerometer / gyroscope. The gyroscope has a selectable angular range of ±125/±250/±500/±1000/±2000 dps

Early units were built using the "ism330dlc", and newer units are built using the "ism330dhcx". These are functionally the same and provide the same channels and performance, but IIO requires you to specify the part number. Our example python/c code will show how to work with either.

The gyroscope is accessed through IIO with channels:

  • anglvel_x
  • anglvel_y
  • anglvel_z
  • timestamp

For example: 

# ISM330DHCX
iio_attr -c ism330dhcx_gyro anglvel_x
iio_attr -c ism330dhcx_gyro anglvel_y
iio_attr -c ism330dhcx_gyro anglvel_z
# ISM330DLC
iio_attr -c ism330dlc_gyro anglvel_x
iio_attr -c ism330dlc_gyro anglvel_y
iio_attr -c ism330dlc_gyro anglvel_z

root@tsimx6ul:~# iio_attr -c ism330dhcx_gyro anglvel_x
dev 'ism330dhcx_gyro', channel 'anglvel_x' (input), attr 'raw', value '2359'
dev 'ism330dhcx_gyro', channel 'anglvel_x' (input), attr 'scale', value '0.000153'
dev 'ism330dhcx_gyro', channel 'anglvel_x' (input), attr 'scale_available', value '0.000153 0.000305 0.000611 0.001222'
root@tsimx6ul:~# iio_attr -c ism330dhcx_gyro anglvel_y
dev 'ism330dhcx_gyro', channel 'anglvel_y' (input), attr 'raw', value '-1667'
dev 'ism330dhcx_gyro', channel 'anglvel_y' (input), attr 'scale', value '0.000153'
dev 'ism330dhcx_gyro', channel 'anglvel_y' (input), attr 'scale_available', value '0.000153 0.000305 0.000611 0.001222'
root@tsimx6ul:~# iio_attr -c ism330dhcx_gyro anglvel_z
dev 'ism330dhcx_gyro', channel 'anglvel_z' (input), attr 'raw', value '2761'
dev 'ism330dhcx_gyro', channel 'anglvel_z' (input), attr 'scale', value '0.000153'
dev 'ism330dhcx_gyro', channel 'anglvel_z' (input), attr 'scale_available', value '0.000153 0.000305 0.000611 0.001222'

This shows a snapshot of the x, y, z values. To get the real world value, multiply the scale * the raw value. In this case:

  • X: 0.360927 dps
  • Y: -0.255051 dps
  • Z: 0.422433 dps

The default scale is ±250, but ±250/±500/±1000/±2000 can be selected by setting the scale: 

dev 'ism330dhcx_gyro', channel 'anglvel_z' (input), attr 'scale', value '0.000153'
dev 'ism330dhcx_gyro', channel 'anglvel_z' (input), attr 'scale_available', value '0.000153 0.000305 0.000611 0.001222'

To set ±1000, you would write the third available scale: 

iio_attr -c ism330dhcx_gyro anglvel_z scale 0.000611

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_gyro -T 0 -s 128 > samples.bin

The format of this file is specified with iio_attr: 

root@tsimx6ul:~# iio_attr -c ism330dhcx_gyro
dev 'ism330dlc_gyro', channel 'anglvel_x' (input, index: 0, format: le:S16/16>>0), found 3 channel-specific attributes
dev 'ism330dlc_gyro', channel 'anglvel_y' (input, index: 1, format: le:S16/16>>0), found 3 channel-specific attributes
dev 'ism330dlc_gyro', channel 'anglvel_z' (input, index: 2, format: le:S16/16>>0), found 3 channel-specific attributes
dev 'ism330dlc_gyro', 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 anglvel_x, little endian, signed
15:0 anglvel_y, little endian, signed
15:0 anglvel_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 into their raw values: 

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 40
X:-58 Y:-199 Z:24 TS:419695978925948679
X:-67 Y:-196 Z:29 TS:419701023781322503
X:-64 Y:-197 Z:28 TS:419705968690298631
X:-58 Y:-203 Z:29 TS:419711008204553991

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_gyro') or ctx.find_device('ism330dlc_gyro')

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

for chan_name in ["anglvel_x", "anglvel_y", "anglvel_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'  anglvel_x={x}, anglvel_y={y}, anglvel_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("anglvel_x=%d, anglvel_y=%d, anglvel_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] = { "anglvel_x", "anglvel_y", "anglvel_z" };

    // Create context and find device
    ctx = iio_create_local_context();
    if (!ctx || !(dev = iio_context_find_device(ctx, "ism330dhcx_gyro")) &&
        !(dev = iio_context_find_device(ctx, "ism330dlc_gyro"))) {
        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;
}

Magnetometer (ST IIS2MDCTR)

This platform 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 lis2mdl with channels:

  • magn_x
  • magn_y
  • magn_z
  • timestamp

For example: 

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

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

Note: This section is incomplete at this time.

LEDs

This platform has two on-board LEDs near the 5 V power input and PC/104 header; a green LED and a red LED. U-Boot uses these to indicate stages of boot and different kernels may use these LEDs for different purposes while also allowing user control of them.

See the relevant software manual for more information on controlling the LEDs.

MicroSD Interface

The i.MX6UL SDHCI driver supports microSD cards up to and including microSDXC standards, supporting up to 2 TB of storage.

TALK ABOUT SPEEDS

Appears at /dev/mmcblk1


We have performed compatibility testing on the Sandisk MicroSD cards we provide. We do not suggest switching brands/models without your own qualification testing. While SD cards specifications are standardized, in practice cards behave very differently. We do not recommend ATP or Transcend MicroSD cards due to known compatibility issues. IS THIS STILL AN ISSUE?!

MicroSD cards should not have power removed during a write or they will have disk corruption. Keep the filesystem mounted read only if this is a possibility. It is not always possible for fsck to recover from the types of failures that will be seen with SD power loss. Consider using the eMMC for storage instead which is far more resilient to power loss.


Supervisory Microcontroller

Note: The supervisory features are only supported in kernel 5.10 and later, and on PCB revision C (early 2023) and later.

The TS-7250-V3 includes a preprogrammed microcontroller intended to manage the SBC's power state, RTC, and a few additional ADCs to monitor system rails. This microcontroller also provides the USB console functionality. The way console is routed can be changed from /sys/: 

root@tsimx6ul:~# cat /sys/bus/i2c/devices/0-0010/console_cfg 
[auto] always-usb
Setting Description
auto Console routes to DB9 by default, but if a USB cable is connected to the microcontroller it routes here instead.
always-usb Console does not route to db9, and is only available on USB.

This can be written to /sys/, and will persist between reboots: 

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

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


Supervisory Microcontroller Low Power Mode

To achieve the lowest power sleep state, the kernel is configured with the reset controller driver, ts_supervisor_rstc. This driver implements shutdown for the SBC to enter the low power state. For example, shutdown -h now will cause a proper shutdown of the CPU with the last step of this issuing a command to the Supervisory Microcontroller to remove power from the whole platform. The Supervisory Microcontroller will remain in a lower power state until one of the following events occurs. At which time it will wake up and enable power to the rest of the platform to let it begin a normal boot process.

In this low power state, the entire platform draws approximately 25 mW. The wakeup source can be detected from the reset reasons.


Supervisory Microcontroller Reset Reasons

The supervisory microcontroller can detect multiple reasons why the system rebooted or woke back up. These are provided by the sysfs device: 

root@tsimx6ul:~# cat /sys/bus/platform/devices/tssupervisor-reset/reboot_reason
POR
reboot_reason text Description
POR Initial power-on reset after both micro USB serial console and VIN[1] were removed
Brownout 5 VDC rail[2] dropped below 4.7 V but Supervisory Microcontroller power input remained valid
CPU WDT Watchdog timer (WDT) expired and caused a hardware reboot
Software Reboot The operating system initiated a reboot
RTC Alarm Reboot Real-time clock (RTC) alarm expired and was configured to cause a hardware reboot
Wake from PWR Cycle The operating system initiated a power-off, after which VIN[1] was cycled off and back on
Wake from WAKE_EN The operating system initiated a power-off, after which the voltage input on ADC Header pin 9 rose from below 1 V to above 3 V
Wake from USB VBUS The operating system initiated a power-off, after which a micro USB serial console cable was connected to USB host
Wake from RTC Alarm The operating system initiated a power-off, after which the real-time clock (RTC) alarm expired
  1. ↑ 1.0 1.1 VIN can either be 5 VDC or 8-48 VDC input
  2. ↑ 5 VDC rail either from 5 VDC direct input or generated internally from 8-48 VDC input


Supervisory Microcontroller RTC

The supervisory microcontroller also provides a real time clock to backup system time when power is lost. This RTC features:

  • Unsigned 32-bit counter
  • Alarm to wake the board up from power off
  • Alarm can be configured as a slow watchdog
  • Battery detection
  • Offset support to tune rtc in ppb
  • Can retain time for ~8 years with the CR1632 battery

The typical RTC features are provided by the rtc-tssupervisor driver present in our kernels. This includes setting/getting the latest epoch time. On most distributions this requires no user interaction and systemd will sync the hardware clock when it syncs to a network time protocol (NTP) server.

To manually interact with the RTC the hwclock command is typically used: 

# Set the RTC from the system time
hwclock --systohc

# Set the system time from the RTC
hwclock --hctosys

# Just print the RTC time, do not set either clock
hwclock --show

Our RTC also has several sysfs entries to support the nonstandard features: 

### VBATT:
## Returns 0 or 1 to indicate if VBATT is > 1.8-2.0V
## Does not indicate a sufficient voltage to keep time, but can be used to detect
## no battery or a malfunctioning battery
## This is only checked on power on
cat /sys/class/rtc/rtc0/device/batt_present 

### RTC Alarm Wake up:
## The RTC can be used to wake the system after shutting down.
# The hwclock call can be skipped if system time is already set:
hwclock --systohc

# Takes the current time and adds 60 seconds
echo $(($(date +%s)+60)) > /sys/class/rtc/rtc0/device/alarm
echo 1 > /sys/class/rtc/rtc0/device/alarm_en
shutdown -h now
# The system will go into the low power state, and power back up when the alarm expires.

### RTC Alarm Watchdog:
## If its not being used for waking the system, the RTC alarm can be used to
## Reset the system if the time is not updated. This can be used as a very slow watchdog, setting
## a reset time of minutes/hours/days ahead instead of a typical 128 seconds a typical
## watchdog allows as the largest timer, but it is slower to feed so it should not be fed quickly.
## Keep in mind this reset is immediate and can corrupt any filesystems mounted read/write when the watchdog
## trips.
# The hwclock call can be skipped if system time is already set:
hwclock --systohc

# Takes the current time and adds 10 seconds
echo $(($(date +%s)+10)) > /sys/class/rtc/rtc0/device/alarm
echo 1 > /sys/class/rtc/rtc0/device/alarm_cause_reboot
echo 1 > /sys/class/rtc/rtc0/device/alarm_en

A typical RTC crystal is approximately ±20 ppm accurate which results in drift while the system is offline of approximately ±631 seconds per year. Our circuit, operating temperature, crystal age (~±3 ppm per year), all influence the accuracy of the crystal. An NTP client like chrony can be used to determine the PPM offset at a board at a given temperature, and the RTC can automatically apply this offset correction. This relies on having access to an accurate NTP server to calibrate the RTC.

Eg, on Debian: 

apt-get update && apt-get install chrony -y

In case there was a previous offset applied which may affect the calibration: 

echo 0 > /sys/class/rtc/rtc0/offset

Open /etc/chrony/chrony.conf, and add the line: 

rtcfile /var/lib/chrony/rtcfile

Make sure there is no 'rtcsync' in the file since it cannot sync the hardware clock during this test, and that cannot be set with rtcfile.

Then restart chrony, and force a sync: 

service chrony restart
chronyc makestep

At this step we must wait for the system clock to get in sync with the upstream NTP server. From our testing with a good network connection this can take 15-30 minutes until the RTC offset settles. From here we can query chrony for the RTC offset. 

root@tsimx6:~# chronyc rtcdata
RTC ref time (UTC) : Fri Nov 18 13:38:36 2022
Number of samples  : 64
Number of runs     : 40
Sample span period : 254m
RTC is fast by     :    -0.198639 seconds
RTC gains time at  :   -21.674 ppm

In this example, the RTC is offset is -21.674 ppm. Linux expects this value to be in parts per billion, and it should be indicated what value will correct the crystal. Multiply the ppm by 1000 * -1 to get a value we can write to the offsets file. For example: 

# Parse rtcdata and get the PPM value
# Eg, with the above example this is:
# PPM=-21.674
PPM=$(chronyc rtcdata | grep ppm | awk '{print $6}')
# Convert to parts per billion and invert the value to apply a correction.
# Eg, with the above example this is:
# PPB_CORRECTION=21674
PPB_CORRECTION=$(echo "scale=0; ${PPM}*-1000/1" | bc)

echo $PPB_CORRECTION > /sys/class/rtc/rtc0/offset

Once this is calibrated at a given temperature the ppm offset range can be calculated with: 

0.035 * (CalibrationTemp - OperatingTemp)^2

For example, if the RTC is calibrated to the offset at 22C: 

0.035*(22-85)^2=138.915

, or roughly ±139 ppm at 85 C.

To calculate the seconds drift per year with this PPM offset: 

(60*60*24*365)*(138.915*10^-6)=4380.8


Supervisory Microcontroller ADC

The supervisory microcontroller provides ADC channels to monitor onboard rails such as VIN, 5 V, 3.3 V, and more. Channels that are less than 3.3 V are provided directly by the IIO device "tssupervisor_adc". The analog frontend driver is used to rescale some channels to the range supported by this ADC.

iio device iio channel Schematic name
an_3p3v voltage0 3.3V
tssupervisor-adc voltage1 VDD_ARM_CAP
tssupervisor-adc voltage2 VDD_SOC_CAP
an_5v voltage0 5V_A
an_8v_48v voltage0 8V_48V

These can be accessed from any language with iio bindings, from /sys/bus/iio/, or using iio_attr. For example, to reading the input voltage with iio_attr: 

root@tsimx6ul:~# iio_attr -c an_8v_48v voltage0
dev 'an_8v_48v', channel 'voltage0' (input), attr 'raw', value '619'
dev 'an_8v_48v', channel 'voltage0' (input), attr 'scale', value '18.650634765'

The raw and scale values can be used to get the real value in millivolts: 

619*18.650634765 = 11544.742919535

or 11.54 V.


Supervisory Microcontroller Temp Sensor

The supervisory microcontroller provides a temperature sensor to read its die temperature as millicelcius.

iio device iio channel
tssupervisor-temp temp

These can be accessed from any language with iio bindings, from /sys/bus/iio/, or using iio_attr. For example, to reading the temperature with iio_attr: 

root@tsimx6ul:~# iio_attr -c tssupervisor-temp temp
dev 'tssupervisor-temp', channel 'temp' (input), attr 'input', value '32915'

This value would be 32.915C.


SPI

DISCUSS WILC SPI? I2C TALKS ABOUT ON-BOARD BUSSES THAT ARE OTHERWISE UNUSABLE? The TS-7250-V3 provides two SPI busses.

SPI devices are recommended to be connected to a kernel driver, though it is possible to arbitrarily interface to SPI devices using the spidev kernel interface. See the software manual for the software image in use (boy that needs to be worded better) for more information.


The TS-7250-V3 FPGA includes the 2 opencore SPI controllers. Under Linux these are spi4 and spi5.

SHOULD THIS MENTION DEVICE NODE NAMES/NUMBER/FIRST BUS/SECOND BUS/ETC?

Controller Chip select Device
spi4 0 /dev/spidev4.0 DIO Header SPI bus
1 Ferroelectric RAM (FRAM)
2 FPGA Flash (/dev/mtdblock0) [1]
spi5 0 /dev/spidev5.0 mikroBUS SPI
  1. ↑ Unless instructed by our support, it is not recommended to manipulate this flash. Erasing this data will require an RMA to recover.


UARTs

The TS-7250-V3 includes UARTs on the CPU, as well as 16550A compatible registers on the FPGA interface.

See the software manual for the software image in use (boy that needs to be worded better) for more information.

THESE SHOULD INCLUDE MORE INFORMATION ON WHICH PHYSICAL INTERFACE THEY ARE. OTHER SECTIONS, LIKE GPIO, JUST KIND OF CALL OUT THE NET NAME AND LINK HERE BUT THERE IS NO LINK BETWEEN SOFTWARE ORDERING AND HARDWARE NAME.

UART Dev. Type TX / + Loc. RX / - Loc. 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.3V 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 [1] TTL DIO pin 5 DIO pin 7 N/A N/A N/A N/A DIO pin 13
ttyS15 [1] TTL DIO pin 9 DIO pin 11 N/A N/A N/A N/A DIO pin 15
  1. ↑ 1.0 1.1 Not enabled until setting #FPGA Syscon 0x08 bit 9 to 1

The DIO header uarts, ttyS14 and ttyS15 are not enabled until a mux register is set. 

# Change DIO header to use UARTs instead of GPIO
tshwctl --address 0x08 --poke32 0x6000


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 without any required settings or API calls. See the UARTs section for the location of the RS-485 port.


RS-422

While both ttyS11 and ttyS12 support RS-485 half duplex these uarts can also be used as a single full duplex RS-422. Either of these UARTs are electrically compatible with RS-485/RS-422 and support TX or RX. To implement RS-422 in software open either UART and use it for transmit, and open the other UART and only use it for receive.


USB

The TS-7250-V3 offers two USB 2.0 host ports. Power to the host ports can be controlled via GPIO EXPLAIN WHICH.

See the software manual for the software image in use (boy that needs to be worded better) for more information. NOTE THAT THERE MAY BE KERNEL DIFFERENCES! ORIGINAL MANUAL TALKS ABOUT STILL USING THE BRIGHTNESS FILE, WHEREAS IN 5.10/6.6 ITS A GPIO PROPERLY.

The USB A host port stack can provide 1 A total power output shared between the two ports.


Watchdog

The TS-7250-V3 implements a WDT inside the CPU. Our stock distribution uses the 'watchdog' utility to check system health, set feed length, and perform feeds. Setting a timeout of 0 and issuing a feed will disable the WDT in hardware.

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

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

See the Linux WDT API documentation for more information.


WiFi

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

Summary features:

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


External Interfaces

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: 

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

See the ADC section for more details on sampling these pins.

Signals Pin Layout
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-Backed Real-Time Clock (RTC) uses a removable CR1632 coin cell in a vertical mount holder. The cell is inserted from the top of the connector, with the positive lead oriented as in the photo below. Once inserted, metal tabs retain the cell. The cell can be removed by pushing the tabs to the side and pushing the cell up from the bottom of the connector.


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+
5 GND
6 ttyS11 RS485-
7 ttyS9 RS-232 RTS
8 ttyS9 RS-232 CTS
9 ttyS12 RS485-
10 NC


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
5 GND
6 CAN2_L
7 ttyS10 RS-232 RTS
8 ttyS10 RS-232 CTS
9 CAN1_L
10 NC


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
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" pitch 2x8 header including SPI and GPIO. All pins on this header are 5V tolerant except SPI output pins. The SPI input pins are 5V tolerant and can be connected to a 5V SPI device. All of these DIO include pullups.

Signals Pin Layout
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[1] 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 spidev 4.0 Chip Select / 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 spidev 4.0 MISO / GPIO Chip 50004010.fpga_gpio IO 10 [2]
11 FPGA 3.3-V LVTTL+QS3861 GPIO Chip 50004010.fpga_gpio IO 7 / ttyS15 RX
12 FPGA 3.3-V LVTTL spidev 4.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 spidev 4.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.3V

  1. ↑ High drives ground, low is tristate.
  2. ↑ This pin is input only even when in the GPIO mode

To use the SPI pins on this header as GPIO instead, disable SPI by changing the FPGA Syscon 0x08 bit 10: 

​tshwctl -a 0x8 --poke32 0x400

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
1
UP
DOWN
2ND
ENTER


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.


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

Pin 4, the LCD_BIAS pin, is used to set the contrast on the LCD. 

tshwctl --address 0x1c --poke16 0x0 # Writes minimum
tshwctl --address 0x1c --poke16 0xf # Writes maximum
Signals Pin Layout
Pin IO Type Signal
1 5V
2 GND
3 CPU 3.3V LCD_RS GPIO Chip 20a4000.gpio IO 21
4 CPU 3.3V LCD_BIAS [1]
5 CPU 3.3V LCD_EN GPIO Chip 50004010.fpga_gpio IO 20
6 CPU 3.3V LCD_WR GPIO Chip 50004010.fpga_gpio IO 19
7 CPU 3.3V+QS3861 LCD D1 GPIO Chip 20a4000.gpio IO 9
8 CPU 3.3V+QS3861 LCD D0 GPIO Chip 50004010.fpga_gpio IO 10
9 CPU 3.3V+QS3861 LCD D3 GPIO Chip 50004010.fpga_gpio IO 11
10 CPU 3.3V+QS3861 LCD D2 GPIO Chip 50004010.fpga_gpio IO 12
11 CPU 3.3V+QS3861 LCD D5 GPIO Chip 50004010.fpga_gpio IO 15
12 CPU 3.3V+QS3861 LCD D4 GPIO Chip 50004010.fpga_gpio IO 16
13 CPU 3.3V+QS3861 LCD_D7 GPIO Chip 50004010.fpga_gpio IO 17
14 CPU 3.3V+QS3861 LCD_D6 GPIO Chip 50004010.fpga_gpio IO 18

  1. ↑ PWM duty cycle controlled by FPGA Syscon reg 0x1c. This may need to be tuned depending on the environment or altitude where the display is used.


mikroBUS Header

The Mikrobus header is a 0.1" pitch 2x8 header which supports the Mikroe Click board ecosystem. This header features 3.3 V, 5 V, SPI, GPIO, ADC, PWM, a UART, and PWM. All I/O on this header are FPGA 3.3-V LVTTL.

The Click boards™ standard (where Click boards™ are a modular prototyping add-on board) is openly documented, allowing for custom boards to be designed.

By default all of these headers default to their non-gpio functions. These can be changed in the FPGA syscon register 0x08. For example: 

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

# Set only SPI to GPIO:
memtool mw -l 0x50004008 0x10
Signals Pin Layout
Pin Name Description
1 AN #FPGA_ADC / GPIO Chip 50004054.fpga_gpio IO 1 [1]
2 RST GPIO Chip 50004054.fpga_gpio IO 0 [2]
3 CS spidev 5.0 CS# / GPIO Chip 50004054.fpga_gpio IO 5
4 SCK spidev 5.0 CLK / GPIO Chip 50004054.fpga_gpio IO 6
5 MISO spidev 5.0 MISO / GPIO Chip 50004054.fpga_gpio IO 7
6 MOSI spidev 5.0 MOSI / GPIO Chip 50004054.fpga_gpio IO 8
7 +3.3V 3.3V
8 GND GND
9 GND GND
10 +5V 5V
11 SDA /dev/i2c-4 DAT / GPIO Chip 50004054.fpga_gpio IO 11
12 SCL /dev/i2c-4 CLK / GPIO Chip 50004054.fpga_gpio IO 12
13 TX ttyS13 TXD / GPIO Chip 50004054.fpga_gpio IO 9
14 RX ttyS13 RXD / GPIO Chip 50004054.fpga_gpio IO 10
15 INT FPGA IRQ 18 / GPIO Chip 50004054.fpga_gpio IO 2
16 PWM MIKRO_PWM / GPIO Chip 50004054.fpga_gpio IO 4

  1. ↑ This signal does not require a mux to use as a GPIO or ADC. To use the ADC signal the GPIO should be an input which is the reset default.
  2. ↑ This signal is pulled high, but your specific click card may require a specific reset duration.


MicroSD Connector

The MicroSD socket is located near the DB9 on top of the board. See the #MicroSD Interface section for more details on the CPU controller.


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.


PC104 Header

The PC/104 connector consists of four rows of pins labelled A-D. This header implements the #PC104 Bus, and optionally most pins can be GPIO.

Refer to the IO specifications for details on the IO voltages of these pins. Not all pins on the PC/104 bus are designed to be 5V tolerant, but will be in places where it is needed for compatibility with the bus.

Pins IO Specification
D3-D15 [1] PCA9555
A1 CPU 3.3V
A10, A11, A12-A31, B6, B8, B11-B20, B25-B28, B30, D1-D2 FPGA 3.3-V LVTTL
A2-A9, B4, B21-B23, C11-C18 FPGA 3.3-V LVTTL+QS3861
B2 Open drain with pull to 5V
  1. ↑ These are only present on the models with the optional I2C port expander

Pin Description Pin Description Pin Description Pin Description
B32 GND A32 GND
B31 GND A31 ISA_ADD_00/Chip 50004064.fpga_gpio IO 0
B30 ISA_14_3_MHZ [1] A30 ISA_ADD_01/Chip 50004064.fpga_gpio IO 1
B29 +5V [2] A29 ISA_ADD_02/Chip 50004064.fpga_gpio IO 2
B28 Chip 50004040.fpga_gpio IO 1/TS mode DAT15 A28 ISA_ADD_03/Chip 50004064.fpga_gpio IO 3 C19 GND D19 GND
B27 Chip 50004040.fpga_gpio IO 2/TS mode DAT14 A27 ISA_ADD_04/Chip 50004064.fpga_gpio IO 4 C18 ISA_DAT_15/Chip 5000405c.fpga_gpio IO 15 D18 GND
B26 Chip 50004040.fpga_gpio IO 10/TS mode DAT13 A26 ISA_ADD_05/Chip 50004064.fpga_gpio IO 5 C17 ISA_DAT_14/Chip 5000405c.fpga_gpio IO 14 D17 Unused
B25 FPGA IRQ 13/TS mode DAT11 A25 ISA_ADD_06/Chip 50004064.fpga_gpio IO 6 C16 ISA_DAT_13/Chip 5000405c.fpga_gpio IO 13 D16 +5V [2]
B24 GND A24 ISA_ADD_07/Chip 50004064.fpga_gpio IO 7 C15 ISA_DAT_12/Chip 5000405c.fpga_gpio IO 12 D15 Chip 50004054.fpga_gpio IO 12
B23 FPGA IRQ 14 A23 ISA_ADD_08/Chip 50004064.fpga_gpio IO 8 C14 ISA_DAT_11/Chip 5000405c.fpga_gpio IO 11 D14 Chip 50004054.fpga_gpio IO 11
B22 FPGA IRQ 15 A22 ISA_ADD_09/Chip 50004064.fpga_gpio IO 9 C13 ISA_DAT_10/Chip 5000405c.fpga_gpio IO 10 D13 Chip 50004054.fpga_gpio IO 10
B21 FPGA IRQ 16 A21 ISA_ADD_10/Chip 50004064.fpga_gpio IO 10 C12 ISA_DAT_09/Chip 5000405c.fpga_gpio IO 9 D12 Chip 50004054.fpga_gpio IO 9
B20 TS mode DAT12 A20 ISA_ADD_11/Chip 50004064.fpga_gpio IO 11 C11 ISA_DAT_08/Chip 5000405c.fpga_gpio IO 8 D11 Chip 50004054.fpga_gpio IO 8
B19 Chip 50004040.fpga_gpio IO 6 A19 ISA_ADD_12/Chip 50004064.fpga_gpio IO 12 C10 Unused D10 Chip 50004054.fpga_gpio IO 7
B18 Chip 50004040.fpga_gpio IO 7/TS mode DAT10 A18 ISA_ADD_13/Chip 50004064.fpga_gpio IO 13 C09 Unused D09 Chip 50004054.fpga_gpio IO 6
B17 Chip 50004040.fpga_gpio IO 8/TS mode DAT9 A17 ISA_ADD_14/Chip 50004064.fpga_gpio IO 14 C08 Unused D08 Chip 50004054.fpga_gpio IO 5
B16 Chip 50004040.fpga_gpio IO 12 A16 ISA_ADD_15/Chip 50004064.fpga_gpio IO 15 C07 Unused D07 Chip 50004054.fpga_gpio IO 4
B15 Chip 50004040.fpga_gpio IO 13 A15 ISA_ADD_16/Chip 5000406c.fpga_gpio IO 0 C06 Unused D06 Chip 50004054.fpga_gpio IO 3
B14 ISA_IOR/Chip 5000406c.fpga_gpio IO 4 A14 ISA_ADD_17/Chip 5000406c.fpga_gpio IO 1 C05 Unused D05 Chip 50004054.fpga_gpio IO 2
B13 ISA_IOW/Chip 5000406c.fpga_gpio IO 5 A13 ISA_ADD_18/Chip 5000406c.fpga_gpio IO 2 C04 Unused D04 Chip 50004054.fpga_gpio IO 1
B12 ISA_MEMR/Chip 5000406c.fpga_gpio IO 6 A12 ISA_ADD_19/Chip 5000406c.fpga_gpio IO 3 C03 Unused D03 Chip 50004054.fpga_gpio IO 0
B11 ISA_MEMW/Chip 5000406c.fpga_gpio IO 7 A11 ISA_AEN/Chip 50004040.fpga_gpio IO 0 C02 Unused D02 Chip 5000406c.fpga_gpio IO 9
B10 GND A10 Chip 50004040.fpga_gpio IO 5 C01 Unused D01 Chip 5000406c.fpga_gpio IO 8
B09 8V_48V [3] A09 ISA_DAT_00/Chip 5000405c.fpga_gpio IO 0 C00 GND D00 GND
B08 Chip 50004040.fpga_gpio IO 3 A08 ISA_DAT_01/Chip 5000405c.fpga_gpio IO 1
B07 Unused A07 ISA_DAT_03/Chip 5000405c.fpga_gpio IO 3
B06 Chip 50004040.fpga_gpio IO 9 A06 ISA_DAT_04/Chip 5000405c.fpga_gpio IO 4
B05 N/A A05 ISA_DAT_05/Chip 5000405c.fpga_gpio IO 5
B04 FPGA IRQ 17/TS mode DAT8 A04 ISA_DAT_02/Chip 5000405c.fpga_gpio IO 2
B03 +5V [2] A03 ISA_DAT_06/Chip 5000405c.fpga_gpio IO 6
B02 Chip 20a4000.gpio IO 7 [4] A02 ISA_DAT_07/Chip 5000405c.fpga_gpio IO 7
B01 GND A01 Chip 20a4000.gpio IO 8
  1. ↑ Outputs a continuous 14.318180 MHz clock
  2. ↑ 2.0 2.1 2.2 Powering the system from PC104 5V prevents the Board's low power sleep mode from functioning.
  3. ↑ This pin can be used to supply power to the board through the switching regulator.
  4. ↑ This is automatically pulsed on startup by the ts-pc104 driver as ISA_RESET


Power Connectors

Note: While the photos below, and shipped PCBs, may show a silkscreen of "8-28V" on the high-voltage input block, all PCB revisions from Rev. A forward support 8-48 VDC input as noted below.


The TS-7250-V3 provides two power inputs on 2 pin removable terminal blocks. One terminal block supports 5 VDC, and one supports 8-48 VDC. Only one power input may be connected at a time. A typical power supply for this platform should provide 10 W. 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.


USB Ports

The TS-7250-V3 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 209c000.gpio 11=1

# Route USB to bottom of J2 (default)
gpioset 209c000.gpio 11=0

Power can also be controlled to save power or reboot peripherals in the field. 

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


XBEE Header

Note: The socket is designed to support various radios from multiple vendors. Even within the same product line, e.g. Airgain's Skywire cell modems, some modules may deviate slightly from the standards set out by the manufacturers. Due to this, we recommend reviewing the datasheet carefully for any potential modules intended to be used in combination with this platform. Our support team (email or support portal) is happy to help advise with any questions on device compatibility.

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 209c000.gpio 11=1

This header can provide 3.3V or 4V as some cell radios require higher voltage. Only enable one power supply to match your radio: 

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

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

# Reset to the modem is controlled with:
gpioset 

# If your modem supports USB, this must be enabled,
# disabling the lower external USB port and enabling
# the modem's.
gpioset 209c000.gpio 11=1

# Some modems require NIM_PWR_ON to be "pressed" before they
# turn on. WARNING: If the modem is already on, this same
# sequence may turn it off.
#gpioset 209c000.gpio 31=1
#sleep 1
#gpioset 209c000.gpio 31=0

For example, this initialization is known to work for these modules:

  • NL_SW_LTE_S7588-T-C
  • NL_SW_LTE_SVZM20-B
gpioset 209c000.gpio 11=1 # Route USB to nimbelink
gpioset 6 11=1 # Turn on 4V
gpioset 209c000.gpio 31=1 # assert NIM_PWR_ON
sleep 1
gpioset 209c000.gpio 31=0 # deassert NIM_PWR_ON

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.embeddedTS.com/ftp/ts-arm-sbc/ts-7840-linux/samples/xbeetest.c
gcc xbeetest.c -o xbeetest

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
OK
Signals Pin Layout
Pin IO Type Signal
1 VCC (XBEE_3.3V or NIMBEL_4.7V)
2 CPU 3.3 ttymxc3 TXD
3 CPU 3.3 ttymxc3 RXD
4 GND
5 Open Drain [1] 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 ttymxc3 CTS#
13 Open drain [1] GPIO Chip 20a4000.gpio IO 2
14 3.3V VREF
15 GND
16 GND
17 NC
18 NC
19 NC
20 Open Drain [1] GPIO Chip 209c000.gpio IO 31 [2]

  1. ↑ 1.0 1.1 1.2 Driving high drives this pin to ground. Low tristates
  2. ↑ This pin is inverted, Setting to 1 drives pin 2 low.


Specifications

IO specifications

IO Type Voltage max Absolute max Source Current Sink Current VIL VIH
CPU 3.3V 3.3V 3.6V 0.99 2.31
CPU 3.3V+QS3861 5V 7V
FPGA 3.3-V LVTTL 3.3V 3.6V 6mA 6mA
FPGA 3.3-V LVTTL+QS3861 5V 7V 6mA 6mA
PCA9555 5.3V 6V 25mA [1] 8-24mA 0.3V 2.31V
  1. ↑ "Each I/O must be externally limited to a maximum of 25 mA and each octal (IO0_0 to IO0_7 and IO1_0 to IO1_7) must be limited to a maximum current of 100 mA for a device total of 200 mA. The total current sourced by all I/Os must be limited to 160 mA


Power Consumption

The TS-7250-V3's i.MX6UL CPU is very flexible with power. It can change the running frequency as needed to consume less power or to allow for more processing power.

The Ethernet can be put into a lower power state by bringing them up, and back down on startup. This is not done by default, and helps power savings regardless of if Ethernet is connected. 

ifconfig eth0 up
ifconfig eth1 up
ifconfig eth0 down
ifconfig eth1 down
ifconfig wlan0 up # only needed if WIFI is present

These tests were run with 5V input. Unless otherwise specified these tests are run with no external connections except power, booted over eMMC at an idle prompt. The above ifconfig commands are included in our tests.

TS-7250-V3
Test Avg. (W) Peak (W)
Idle 0.77 1.29
CPU fully loaded [1] 1.03 1.45
CPU idle, single Ethernet port up and active [2] 1.17 1.75
CPU fully loaded [1], single Ethernet port up and active [2] 1.40 2.03
Supervisory Microcontroller sleep mode (ARM CPU off) 0.055 0.063
  1. ↑ 1.0 1.1 This is accomplished by running stress-ng --matrix 0 -t 60m which generally consumes 100% CPU time
  2. ↑ 2.0 2.1 Using iperf to create bidirectional activity which adds minor CPU load


Power Input Specifications

The TS-7250-V3 supports 2 input ranges. 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 [1] 5.2 VDC
8-48 VDC [2] 8 VDC 48 VDC
  1. ↑ This requires requires at least 4.7 V to start up, and the onboard supervisory microcontroller will trigger a brownout reset if this dips below 4 V. While the TS-7250-V3 will continue to operate at this low of a voltage, any connected devices using the 5 V rail directly such as USB may not function as intended this low.
  2. ↑ Note the the CN2 Power Connector may have 8-28V on the PCB silkscreen; every PCB revision from Rev. A and forward support the full 8-48 VDC range. Please contact us if you have any concerns on this.


Revisions and Changes

FPGA Changelog

See the current FPGA revision from the u-boot output: 

Model: Technologic Systems i.MX6UL TS-7250-V3
Board: TS-7250-V3 REV A
FPGA:  Rev 24 (47555b21)
DRAM:  1 GiB

Or from Linux: 

root@tsimx6:~# tshwctl -i
MODEL=7250
FPGA_REV=24
FPGA_HASH="47555b21"
OPTS=0x0
RAM_MB=1024
PCBREV=A
Revision Changes
24 Initial release
45
  • Updated System clock to expect 79.2MHz instead of 99MHz. This requires the latest u-boot for the clocks to match.
  • SPI Opencore updates
    • Fixed timing issues with SPI busses
      • Allows correct operation at top speed of 19.8MHz
    • Modified SPI core to add CPOL + CPHA
      • Latest kernel driver supports these changes needed to support all 4 SPI modes
  • ISA
    • Includes ISA timing changes. See #PC104_Bus for current timing description.
      • Previously write data was just set before one edge of an isa strobe (ior/iow/memw/memr). This change makes sure data is set for both edges. While not required by the ISA specification, this may improve compatibility with third party devices.
      • ISA pins can now be used as GPIO. No change in behavior by default, but see Syscon 0x08 bit 8 to enable gpio
  • Mikrobus implemented
  • GPIO
49
50
  • Added support for 7MHz on BCLK (ISA B20) See Syscon 0x08.
51
  • Added support for detecting REV C PCBS
52
  • Fixed 16550 control signal polarity. CTS/RTS/RI/DSR/DCD/DTR were previously inverted.
  • This is the last FPGA Revision with REV A support
53
  • Added support for REV C PCBs which bring console over the DB9 port
  • This FPGA and later revisions no longer support REV A PCBs. This should only be written to REV C and later.
56
  • Added support for using RTS instead of TXEN to control transmit enable on RS-485
  • Split the DIO UARTs enable to uart6 enable and uart 7 enable to control them independently
  • Added missing pullup to MIKRO_RESET#

See #Onboard_Firmware_Updates for more details on updating the system.

Note that since the release of REV C PCBs, REV A hardware should not use past REV 52. The update script shown above will update a REV C and later to the newest revision, and REV A to rev 52.

After updating the board must get a full power cycle to load the new bitstream. If the FPGA update fails then this must come back on an RMA to be recovered.

Microcontroller Changelog

On the engineering sampling units (REV A PCB) the microcontroller is a Silicon labs part, but this has been replaced with a Renesas RA4M2 on REV C and later. The REV C and later boards can be updated in the field:

Revision Description
23
  • Initial REV C release
35
  • Added RTC counter controller
  • Added ADC controller
  • Added Reset controller / low power mode
41
  • Support console on DB9, needs latest FPGA update
  • Implement low power mode fixes
  • Reset cause fixes
42
  • Support serial numbers (eth1 mac is now the usb serial number)
43
  • Fix CDC-ACM to fix support with some USB UART clients on Windows 10 after a Windows Update.
    • Putty, Realterm, and possibly others would refuse to open the port.
    • Teraterm was not affected
    • Windows 11 is not affected so far
    • Linux connectivity is not affected
44
  • Expanded 5V range for brownout detection allowing 5V to work in a wider range
47
  • Fixed ADC VREF. This was intended to generate a 2.5V VREF, but at some point regressed and was instead incorrectly generating a 0.8V on previous revisions.

See the tssupervisorupdate project for instructions on updating to the latest release.

PCB Revisions

Revision Description
A
  • Initial release
C
  • Changed Supervisory Microcontroller to a Renesas RA4M2 instead of Silicon Labs C8051F381.
  • Fixed ISA_RESET# polarity so it is deasserted on startup until power off
  • Added minor changes to support console on DB9


U-Boot Changelog

Unless you are experiencing issues it is not recommended to change u-boot. If the board is written with an invalid u-boot this will require an RMA to recover.

U-boot Links Changes
SPL-20210513 u-boot-dtb-20210513.img Initial release
SPL-20211015 u-boot-dtb-20211015.img
  • Updated to support 79.2MHz clock required by REV 45
  • Do not update if your FPGA REV is < 45
SPL-20230203 u-boot-dtb-20230203.img
  • Updated to support REV C boards.
  • Rev. A boards now load the device tree:
    • /boot/imx6ul-ts7250v3-reva.dtb
  • This will be used to support these engineering sampling boards going forward. REV C and later will use:
  • /boot/imx6ul-ts7250v3.dtb
SPL-20240820 u-boot-dtb-20240820.img
  • Detects the accelerometer+gyro present and updates the device tree before jumping to linux
    • Supports the existing ism330dlc, and the new ism330dhcx

Onboard Firmware Updates

The FPGA, supervisory microcontroller, and u-boot can all be updated in the field.

The supervisory microcontroller supports atomic updates so it is safe to update at any time, but the FPGA or u-boot must rewrite their running location. If an FPGA or u-boot update are interrupted at the wrong time this may require an RMA to recover.

Its recommended to run from the latest Debian headless image to run the updates, but the updates should run anywhere that has tssupervisorupdate. To run our update script: 

wget https://files.embeddedts.com/ts-arm-sbc/ts-7250-v3-linux/update/update
chmod a+x ./update
./update
reboot

The updates will take effect on the next boot.

Product Notes

FCC Advisory

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

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

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

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

Limited Warranty

See our Terms and Conditions for more details.


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

Trademarks

Arm and Cortex are registered trademarks of Arm Limited (or its subsidiaries) in the US and/or elsewhere.

Retrieved from "http://docs.embeddedts.com/index.php?title=TS-7250-V3_Hardware_Manual_Test_2&oldid=17050"