Difference between revisions of "TS-7250-V3"

From Technologic Systems Manuals
(Created page with "{{Note|This manual is incomplete at this time and is subject to change without warning while the TS-7250-V3 is in Engineering Sampling phase.}} {{Infobox |title = TS-...")
 
 
(64 intermediate revisions by the same user not shown)
Line 28: Line 28:
 
= Getting Started =
 
= Getting Started =
 
{{:TS-7250-V3_getting_started}}
 
{{:TS-7250-V3_getting_started}}
 +
 +
== Connect USB Console ==
 +
The board includes a USB Micro header connected to the onboard preprogrammed microcontroller.  This acts as a USB serial device using the CP210x Virtual COM port.  Most operating systems have built-in support for this device, however drivers are available [https://www.silabs.com/products/development-tools/software/usb-to-uart-bridge-vcp-drivers here].
 +
 +
{{:Console From Linux Workstation}}
 +
 +
{{:Console from Windows Workstation}}
 +
 +
== Powering up ==
 +
The TS-7250-V3 receives power through either the 5VDC 2pin terminal block connector near the DB9, or the 2 pin 8-28VDC terminal block near the mikrobus connector. 
 +
 +
If a power supply is ordered with the TS-7250-V2 it will include the correct terminal block connected to the power supply.  Otherwise the terminal block will ship with the unit.
 +
 +
{{Note|The polarity is marked underneath the removable terminal blocks.}}
 +
 +
Once power is applied the device will output information via the built in USB console.
 +
 +
The first output is from U-Boot:
 +
 +
<console>
 +
Trying to boot from MMC1
 +
 +
 +
U-Boot 2020.01-00009-g99e2080fad (Mar 12 2020 - 08:43:22 -0700)
 +
 +
CPU:  Freescale i.MX6UL rev1.2 696 MHz (running at 396 MHz)
 +
CPU:  Automotive temperature grade (-40C to 125C) at 44C
 +
Reset cause: POR
 +
Model: Technologic Systems i.MX6UL TS-7250-V3
 +
Board: TS-7250-V3
 +
DRAM:  512 MiB
 +
MMC:  FSL_SDHC: 0
 +
Loading Environment from MMC... *** Warning - bad CRC, using default environment
 +
 +
In:    serial
 +
Out:  serial
 +
Err:  serial
 +
Net: 
 +
Warning: ethernet@20b4000 using MAC address from ROM
 +
eth1: ethernet@20b4000
 +
Warning: ethernet@2188000 using MAC address from ROM
 +
, eth0: ethernet@2188000
 +
Press ESC twice to abort autoboot in 1 second(s)
 +
</console>
 +
 +
{{Note|The message "*** Warning - bad CRC, using default environment" can be safely ignored. This indicates that u-boot scripts are not being customized. Typing "env save" will hide these messages, but this is not needed.}}
 +
 +
{{Note|The message "using MAC address from ROM" is indicating that the board is using the preprogrammed MAC address as intended.  All boards are assigned 2 unique MAC addresses.}}
 +
 +
This u-boot and its environment is loaded from the SPI flash (/dev/mmcblk0boot0). This a hardware partition that is independent of the main flash on the emmc (/dev/mmcblk0). From here, u-boot will follow u-boots standard Distro boot command. This will check for boot files on the first USB mass storage, and will by default find a bootable image on eMMC. From here the board will boot to our default [[#Debian]] image.
 +
 +
== First Linux Boot ==
 +
When booting with the default settings, a shipped board [[#U-boot Distro Boot|will boot to the eMMC]]. The eMMC by default are pre-programmed with our default [[#Debian 10|Debian 10]] Buster image. After Linux boots it will ask the user to log in with a username and password. This uses "root" as the username with no password. This can be changed after logging in with the command "passwd" to set an account password.
 +
 +
From the Linux prompt you can now begin testing out hardware, or beginning your application development.
 +
 +
== Booting from USB ==
 +
{{:TS-7250-V3 boot from USB}}
  
 
= U-Boot =
 
= U-Boot =
{{:TS-7250-V3_U-Boot_Sections}}
+
{{:TS-7250-V3 U-Boot}}
 +
 
 +
== U-boot Distro Boot ==
 +
{{:TS-7250-V3 Uboot Distro Boot}}
 +
 
 +
== U-Boot Environment ==
 +
{{:TS-7250-V3 u-boot environment}}
 +
 
 +
== U-Boot Development ==
 +
{{:TS-7250-V3 U-boot development}}
 +
 
 +
= Debian 10 =
 +
{{:Debian Buster Description}}
 +
 
 +
== Debian 10 - Getting Started and writing an Image ==
 +
{{:TS-7250-V3 Buster Getting started}}
 +
 
 +
== Debian 10 - Configuring Network ==
 +
{{:TS-7250-V3 Buster Network}}
 +
 
 +
== Debian 10 - Installing New Software ==
 +
{{:Buster installing software}}
  
= Debian Buster(10) =
+
== Debian 10 - Setting Up SSH ==
{{:TS-7250-V3_buster}}
+
{{:Buster setup ssh}}
  
= Buildroot Configuration =
+
== Debian 10 - Starting Automatically ==
{{:TS-7250v3_buildroot}}
+
{{:Buster Startup Scripts}}
  
= Backup / Restore =
+
== Debian 10 - Cross Compiling ==
== Creating A Backup / Production Image ==
+
{{:Buster armhf cross compile docker}}
{{Note|This section is incomplete at this time.}}
 
  
== Restoring Stock / Backup / Production Image ==
+
== Debian 10 - Backup the image ==
=== Booted from USB / NFS ===
+
{{:Buster backup the image}}
{{:TS-7250-V3 eMMC Restore}}
 
  
= Compile the Kernel =
+
== Debian 10 - Compile the Kernel ==
 
{{:TS-7250-V3_kernel_compile_guide}}
 
{{:TS-7250-V3_kernel_compile_guide}}
  
= Production Mechanism =
+
= Buildroot =
The TS-7250-V3's U-Boot has the ability to locate and run a U-Boot script file named /tsinit.ub on the root of a USB drive.  This process occurs when attempting to [[#Entering_U-Boot_shell|boot to the U-Boot shell]].  If this script exists, U-Boot will load and run it automatically.  This is intended for the initial production of units and allows mass programming various media from a USB mass storage device.
+
{{:TS-7250-V3 buildroot general}}
  
The USB blasting image can be downloaded [http://ftp.embeddedarm.com/ftp/ts-arm-sbc/ts-7100-linux/usb-blaster/tsimx6ul_usb_blaster-latest.tar.bz2 here].  This includes a basic Linux kernel and a small initramfs that will mount the USB drive at "/mnt/usb/" and execute "/mnt/usb/blast.sh".
+
== Buildroot - Compiling an Image ==
 +
The default image for the TS-7250-V3 generates a minimalistic OS of around 30MiB.  This includes the kernel, device tree, boot scripts and the bare minimum linux os to run busybox.  Any other libraries besides uclibc would need to be added.
 +
 
 +
<source lang=bash>
 +
git clone https://github.com/embeddedarm/buildroot-ts.git
 +
cd buildroot-ts
 +
git submodule update --init
 +
make ts7250v3_defconfig
 +
make
 +
</source>
  
{{:Tsimx6ul_usb_production}}
+
= USB Production Method =
 +
{{:TS-7250-V3 USB production}}
  
 
= Features=
 
= Features=
 
== ADC ==
 
== ADC ==
{{Note|This section is incomplete at this time.}}
+
{{:TS-7250-V3 ADC}}
=== 0-50 V ===
 
=== 0-12 V ===
 
=== 4-20 mA ===
 
  
 
== Battery Backed RTC ==
 
== Battery Backed RTC ==
 
{{:TS-7250-V3_RTC}}
 
{{:TS-7250-V3_RTC}}
 
TS-7250-V3 board provides battery backed power to the RTC via a replaceable CR1632 coin cell.
 
  
 
== Bluetooth ==
 
== Bluetooth ==
Line 72: Line 154:
  
 
==CAN==
 
==CAN==
The TS-7100-Z CPU has a single FlexCAN port that uses the Linux SocketCAN implementation.  The port can be set up and used with the following command:
+
The TS-7250-V3 CPU has two FlexCAN ports that use the Linux SocketCAN implementation.  These are available on the [[#COM3 Header]]
 +
 
 +
These interfaces can be brought up with:
 
<source lang="bash">
 
<source lang="bash">
 
ip link set can0 up type can bitrate 1000000
 
ip link set can0 up type can bitrate 1000000
 +
ip link set can1 up type can bitrate 1000000
 
</source><br>
 
</source><br>
 
The CAN transceiver is automatically controlled by the kernel.  If the interface is brought up in Linux then the transceiver will be enabled. By default when the kernel boots, the interface is down, and therefore the transceiver is disabled.
 
  
 
At this point, the port can be used with standard SocketCAN libraries. In Debian, we provide the utilities 'cansend' and 'candump' to test the ports or as a simple packet send/receive tool. In order to test the port, tie CAN_H to the CAN_H pin of the bus, doing the same for the CAN_L pin.  Then use the following commands:
 
At this point, the port can be used with standard SocketCAN libraries. In Debian, we provide the utilities 'cansend' and 'candump' to test the ports or as a simple packet send/receive tool. In order to test the port, tie CAN_H to the CAN_H pin of the bus, doing the same for the CAN_L pin.  Then use the following commands:
Line 88: Line 171:
 
</source><br>
 
</source><br>
 
{{:CAN_Generic}}
 
{{:CAN_Generic}}
 
  
 
== CPU ==
 
== CPU ==
 
{{:imx6ul_CPU}}
 
{{:imx6ul_CPU}}
 
  
 
== GPIO ==
 
== GPIO ==
{{Note|This section is incomplete at this time.}}
 
 
 
The i.MX6UL CPU and FPGA GPIO are exposed using a kernel character device. This interface provides a set of files and directories for interacting with GPIO which can be used from any language that interact with special files in linux using ioctl() or similar. For our platforms, we pre-install the "libgpiod" library and binaries. Documentation on these tools can be found [https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/tree/README here]. This section only covers using these userspace tools and does not provide guidance on using the libgpiod library in end applications. Please see the libgpiod documentation for this purpose.
 
The i.MX6UL CPU and FPGA GPIO are exposed using a kernel character device. This interface provides a set of files and directories for interacting with GPIO which can be used from any language that interact with special files in linux using ioctl() or similar. For our platforms, we pre-install the "libgpiod" library and binaries. Documentation on these tools can be found [https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/tree/README here]. This section only covers using these userspace tools and does not provide guidance on using the libgpiod library in end applications. Please see the libgpiod documentation for this purpose.
  
Line 114: Line 193:
  
 
The 'gpiomon' tool can be used to monitor pins for changes.
 
The 'gpiomon' tool can be used to monitor pins for changes.
 
  
 
{|class="wikitable sortable"
 
{|class="wikitable sortable"
 +
! Schematic Net Name
 
! Chip
 
! Chip
 
! Pin
 
! Pin
 
! Location
 
! Location
 
|-
 
|-
 +
| AN_CH1
 
| 0
 
| 0
 
| 0
 
| 0
| [[#ADC|AIN 4]] or [[#Digital_Inputs|Digital Input AIN 4]] on [[#CN32_Terminal_Block|CN32 Terminal]]
+
| [[#ADC Header|ADC Pin 1]]
 
|-
 
|-
 +
| AN_CH2
 +
| 0
 +
| 1
 +
| [[#ADC Header|ADC Pin 3]]
 +
|-
 +
| EN_SD_CARD_3.3V
 
| 0
 
| 0
 
| 4
 
| 4
| [[#ADC|AIN 0]] on [[#CN32_Terminal_Block|CN32 Terminal]]
+
| Onboard
 
|-
 
|-
 +
| AN_CH3
 
| 0
 
| 0
 
| 5
 
| 5
| [[#ADC|AIN 1]] or [[#Digital_Inputs|Digital Input AIN 1]] on [[#CN32_Terminal_Block|CN32 Terminal]]
+
| [[#ADC Header|ADC Pin 5]]
 
|-
 
|-
 +
| AN_CH4
 
| 0
 
| 0
 
| 8
 
| 8
| [[#ADC|AIN 2]] or [[#Digital_Inputs|Digital Input AIN 2]] on [[#CN32_Terminal_Block|CN32 Terminal]]
+
| [[#ADC Header|ADC Pin 7]]
 
|-
 
|-
 +
| AN_CH5
 
| 0
 
| 0
 
| 9
 
| 9
| [[#ADC|AIN 3]] or [[#Digital_Inputs|Digital Input AIN 3]] on [[#CN32_Terminal_Block|CN32 Terminal]]
+
| [[#ADC Header|ADC Pin 9]]
 
|-
 
|-
 +
| TXD1_485_STRAP
 +
| 0
 +
| 16
 +
| [[#Board Variants|Board Variants]]
 +
|-
 +
| TXD2_485_STRAP
 +
| 0
 +
| 17
 +
| [[#Board Variants|Board Variants]]
 +
|-
 +
| COM3_TXD_STRAP
 
| 0
 
| 0
 
| 18
 
| 18
| [[#LEDs|CPU Board Red LED]]
+
| [[#Board Variants|Board Variants]]
 
|-
 
|-
 +
| COM2_TXD_STRAP
 
| 0
 
| 0
 
| 19
 
| 19
| [[#LEDs|CPU Board Green LED]]
+
| [[#Board Variants|Board Variants]]
 
|-
 
|-
 +
| GYRO_INT
 
| 4
 
| 4
 
| 0
 
| 0
| [[#TS-SILO_Supercapacitors|Power Input Failure]]
+
| Onboard
 
|-
 
|-
 +
| FPGA_IRQ
 
| 4
 
| 4
 
| 1
 
| 1
| [[#Interrupts|FPGA Interrupt input pin]]
+
| Onboard
 
|-
 
|-
 +
| EN_EMMC_3.3V
 
| 4
 
| 4
| 4
 
| [[#Relays|Relay 1]] on [[#CN32_Terminal_Block|CN32 Terminal]]
 
|-
 
| 4
 
| 5
 
| [[#Relays|Relay 2]] on [[#CN32_Terminal_Block|CN32 Terminal]]
 
|-
 
| 5
 
| 0
 
| [[#Digital_Outputs|DIO 1 Out]] or PWM on [[#CN32_Terminal_Block|CN32 Terminal]]
 
|-
 
| 5
 
| 1
 
| [[#Digital_Outputs|DIO 2 Out]] or PWM on [[#CN32_Terminal_Block|CN32 Terminal]]
 
|-
 
| 5
 
 
| 2
 
| 2
| [[#Digital_Inputs|DIO 1 In]] on [[#CN32_Terminal_Block|CN32 Terminal]]
+
| Onboard
 
|-
 
|-
| 5
+
| EN_CL_1
| 3
 
| [[#Digital_Inputs|DIO 2 In]] on [[#CN32_Terminal_Block|CN32 Terminal]]
 
|-
 
| 5
 
 
| 4
 
| 4
| [[#Digital_Inputs|DIO 3 In]] on [[#CN32_Terminal_Block|CN32 Terminal]]
 
|-
 
| 5
 
| 5
 
| FPGA DIO 06
 
|-
 
| 5
 
| 6
 
| [[#Digital_Inputs|Digital In 1]] on [[#CN32_Terminal_Block|CN32 Terminal]]
 
|-
 
| 5
 
 
| 7
 
| 7
| [[#Digital_Inputs|Digital In 2]] on [[#CN32_Terminal_Block|CN32 Terminal]]
+
| [[#ADC Header]]
 
|-
 
|-
| 5
+
| EN_CL_2
 +
| 4
 
| 8
 
| 8
| [[#Digital_Inputs|Digital In 3]] on [[#CN32_Terminal_Block|CN32 Terminal]]
+
| [[#ADC Header]]
 
|-
 
|-
| 5
+
| EN_CL_3
 +
| 4
 
| 9
 
| 9
| [[#ADC|AIN 1 4-20 mA current loop enable]]
+
| [[#ADC Header]]
 
|-
 
|-
| 5
+
| EN_RED_LED#
| 10
+
| 0
| [[#ADC|AIN 2 4-20 mA current loop enable]]
+
| 18
 +
| [[#LEDs]]
 
|-
 
|-
| 5
+
| EN_GRN_LED#
| 11
+
| 0
| [[#ADC|AIN 3 4-20 mA current loop enable]]
+
| 19
 +
| [[#LEDs]]
 
|-
 
|-
| 5
+
| EN_XBEE_USB
| 12
+
| 0
| Reserved
+
| 21
 +
| Onboard
 
|-
 
|-
| 5
+
| MAGNET_IRQ
| 13
+
| 0
| Reserved
 
|-
 
| 5
 
 
| 14
 
| 14
| [[#ADC|AIN 4 4-20 mA current loop enable]]
+
| Onboard
 
|-
 
|-
| 5
+
| FPGA_RESET
| 15
+
| 0
| [[#Digital_Outputs|High-Side Switch]] or HSPWM
+
| 13
|-
+
| Onboard
| 6
 
| 1
 
| [[#ADC|AIN 1 0-12 V meas. mode]] <ref name=ain12v>This bit is read only. Clearing the associated current loop enable bit will set this bit, setting the CL enable will clear this bit</ref>
 
 
|-
 
|-
| 6
+
| ISA_RESET
 
| 2
 
| 2
| [[#ADC|AIN 2 0-12 V meas. mode]] <ref name=ain12v/>
 
|-
 
| 6
 
| 3
 
| [[#ADC|AIN 3 0-12 V meas. mode]] <ref name=ain12v/>
 
|-
 
| 6
 
| 4
 
| [[#ADC|AIN 4 0-12 V meas. mode]] <ref name=ain12v/>
 
|-
 
| 6
 
| 5
 
| en usb host 5v
 
|-
 
| 6
 
| 6
 
| eth PHY reset
 
|-
 
| 6
 
 
| 7
 
| 7
| wifi reset
+
| [[#PC104 Header|PC104 B2]]
 
|-
 
|-
| 6
+
| ISA_IOCHK
 +
| 2
 
| 8
 
| 8
| [[#LEDs|I/O Board Red LED]]
+
| [[#PC104 Header|PC104 A1]]
 
|-
 
|-
| 6
+
| LCD_PIN7
 +
| 2
 
| 9
 
| 9
| [[#LEDs|I/O Board Green LED]]
+
| [[#LCD Header|LCD Header pin 7]]
|-
 
| 6
 
| 12
 
| Reserved
 
|-
 
| 6
 
| 13
 
| [[#Digital_Output|DIO 3 Out]] or PWM on [[#CN32_Terminal_Block|CN32 Terminal]]
 
|-
 
| 6
 
| 14
 
| HSPWM enable
 
|-
 
| 6
 
| 15
 
| PWM enable, both OE and dat
 
|-
 
| 7
 
| 0
 
| [[#Interrupts|Touchscreen IRQ]]
 
 
|-
 
|-
| 7
+
| LCD_PIN8
 
| 2
 
| 2
| FPGA Strapping Pin
 
|-
 
| 7
 
| 3
 
| FPGA Strapping Pin
 
|-
 
| 7
 
| 4
 
| FPGA Strapping Pin
 
|-
 
| 7
 
| 5
 
| FPGA Strapping Pin
 
|-
 
| rowspan=2 | 7
 
| rowspan=2 | 6
 
| Data 0: Select 3.3 V power on [[#CN16_XBee_Socket|CN16 XBee Socket]] <ref name=INdis>To disable power on this pin, set the GPIO as an input with 'gpioset' or otherwise</ref>
 
|-
 
| Data 1: Select 4 V power on [[#CN16_XBee_Socket|CN16 XBee Socket]] <ref name=INdis />
 
|-
 
| 7
 
| 8
 
| Enable MODEM on [[#CN16_XBee_Socket|CN16 XBee Socket]] <ref>Default enabled on P2 PCB</ref>
 
|-
 
| 7
 
| 9
 
| Enable USB interface on [[#CN16_XBee_Socket|CN16 XBee Socket]] <ref>This will relocate the USB channel connected to the top [[#USB|USB host port]]</ref>
 
|-
 
| 7
 
 
| 10
 
| 10
| I/O over-current/over-voltage breaker tripped <ref>This bit must be cleared manually after a trip to de-assert the associated IRQ</ref>
+
| [[#LCD Header|LCD Header pin 8]]
 
|-
 
|-
| 7
+
| LCD_PIN9
 +
| 2
 
| 11
 
| 11
| FPGA Strapping Pin
+
| [[#LCD Header|LCD Header pin 9]]
 
|-
 
|-
| 7
+
| LCD_PIN10
 +
| 2
 
| 12
 
| 12
| FPGA Strapping Pin
+
| [[#LCD Header|LCD Header pin 10]]
 
|-
 
|-
| 7
+
| LCD_PIN11
| 13
+
| 2
| Reserved
+
| 15
 +
| [[#LCD Header|LCD Header pin 11]]
 
|-
 
|-
| 7
+
| LCD_PIN12
| 14
+
| 2
| LCD backlight enable
+
| 16
|}
+
| [[#LCD Header|LCD Header pin 12]]
 
 
<references/>
 
 
 
 
 
=== Digital Inputs ===
 
The digital inputs on the TS-7100-Z are capable of supporting various voltage ranges and input modes. The digital inputs support dry contact switches as well as a driven input voltage. The table below lists each digital input, the bank and pin number for reading the input, the maximum input voltage range, the threshold voltages, as well as the location of the input. VIH Min is the minimum voltage on the input to trigger a logic 1 input. VIL Max is the maximum voltage on the input to trigger a logic 0 input. All of the digital inputs are hysteretic. The driving input must be able to at least sink current to drive the input low, but all digital inputs are compatible with push-pull drivers.
 
 
 
{|class="wikitable sortable"
 
! Input Name
 
! Bank
 
! Pin
 
! V Range
 
! VIH Min
 
! VIL Max
 
! Location
 
 
|-
 
|-
| Digital In 1
+
| LCD_PIN13
| 5
+
| 2
| 6
+
| 17
| 0-30 V
+
| [[#LCD Header|LCD Header pin 13]]
|
 
| ~1 V
 
| [[#CN32_Terminal_Block|CN32 Terminal, pin 9]]
 
 
|-
 
|-
| Digital In 2
+
| LCD_PIN14
| 5
+
| 2
| 7
+
| 18
| 0-30 V
+
| [[#LCD Header|LCD Header pin 14]]
|
 
| ~1 V
 
| [[#CN32_Terminal_Block|CN32 Terminal, pin 11]]
 
 
|-
 
|-
| Digital In 3
+
| LCD_WR#
| 5
+
| 2
| 8
+
| 19
| 0-30 V
+
| [[#LCD Header|LCD Header pin 6]]
|
 
| ~1 V
 
| [[#CN32_Terminal_Block|CN32 Terminal, pin 13]]
 
 
|-
 
|-
| DIO 1 In <ref name=DIO>This GPIO should only be read as an input. Its value reflects the voltage on the physical CN32 pin, regardless of [[#Digital_Outputs|output status]]</ref>
+
| LCD_EN
| 5
+
| 2
 +
| 20
 +
| [[#LCD Header|LCD Header pin 5]]
 +
|-
 +
| LCD_RS
 
| 2
 
| 2
| 0-30 V
+
| 23
|
+
| [[#LCD Header|LCD Header pin 3]]
| ~1 V
 
| [[#CN32_Terminal_Block|CN32 Terminal, pin 14]]
 
 
|-
 
|-
| DIO 2 In <ref name=DIO/>
+
| LCD_BIAS
| 5
+
| 2
| 3
+
| 24
| 0-30 V
+
| [[#LCD Header|LCD Header pin 4]]
|
 
| ~1 V
 
| [[#CN32_Terminal_Block|CN32 Terminal, pin 16]]
 
 
|-
 
|-
| DIO 3 In <ref name=DIO/>
+
| NIM_PWR_ON
| 5
+
| 2
| 4
+
| 25
| 0-30 V
+
| Onboard
|
 
| ~1 V
 
| [[#CN32_Terminal_Block|CN32 Terminal, pin 18]]
 
 
|-
 
|-
| AIN 1 In <ref name=AIN>The AIN pins can be used as Digital Inputs, but require software changes first. See the [[#ADC|ADC section]] for more information</ref>
+
| EN_DIO_FET
| 0
+
| 2
| 5
+
| 27
| 0-12 V
+
| [[#DIO Header|DIO Header pin 4]]
|
 
|  
 
| [[#CN32_Terminal_Block|CN32 Terminal, pin 25]]
 
 
|-
 
|-
| AIN 2 In <ref name=AIN/>
+
| SEL_XBEE_USB
| 0
+
| 2
| 8
+
| 28
| 0-12 V
+
| Onboard
|
 
|
 
| [[#CN32_Terminal_Block|CN32 Terminal, pin 23]]
 
 
|-
 
|-
| AIN 3 In <ref name=AIN/>
+
| EN_USB_5V
 +
| 2
 
| 0
 
| 0
| 9
+
| Onboard
| 0-12 V
 
|
 
|
 
| [[#CN32_Terminal_Block|CN32 Terminal, pin 21]]
 
 
|-
 
|-
| AIN 4 In <ref name=AIN/>
+
| FPGA_FLASH_SELECT
| 0
+
| 3
 
| 0
 
| 0
| 0-12 V
+
| Onboard
|
 
|
 
| [[#CN32_Terminal_Block|CN32 Terminal, pin 19]]
 
|}
 
 
 
<references/>
 
 
 
=== Digital Outputs ===
 
The TS-7100-Z supports a handful of digital output pins. These are able to act as high-current low-side switches. The table below lists each digital output, the bank and pin number for accessing it, the maximum voltage rating, the maximum current output, as well as the location of the pin.
 
 
 
{|class="wikitable sortable"
 
! DIO Name
 
! Bank
 
! Pin
 
! Max V Rating
 
! Max A Rating
 
! Location
 
 
|-
 
|-
| DIO 1 Out
+
| DETECT_94-120
| 5
+
| 3
| 0
 
| 30 V
 
| 700 mA (sink) <ref name=breaker>Not to exceed [[#Digital_I/O_Over-Current_Breaker|1000 mA total]] across all three Digital I/O</ref>
 
| [[#CN32_Terminal_Block|CN32 Terminal, pin 14]]
 
|-
 
| DIO 2 Out
 
| 5
 
 
| 1
 
| 1
| 30 V
+
| Onboard
| 700 mA (sink) <ref name=breaker/>
 
| [[#CN32_Terminal_Block|CN32 Terminal, pin 16]]
 
 
|-
 
|-
| DIO 3 Out
+
|  
| 6
 
| 13
 
| 30 V
 
| 700 mA (sink) <ref name=breaker/>
 
| [[#CN32_Terminal_Block|CN32 Terminal, pin 18]]
 
|-
 
| High-Side Switch
 
| 5
 
| 15
 
| 48 V <ref>The output voltage is the same as the TS-7100-Z input voltage</ref>
 
| 330 mA (source) <ref>Exceeding 330 mA will cause the [[#Digital_I/O_Over-Current_Breaker|over-current breaker]] to trip</ref>
 
| [[#CN32_Terminal_Block|CN32 Terminal, pin 27]]
 
 
|}
 
|}
  
 
<references/>
 
<references/>
 
 
==== Digital Output Over-Current Breaker ====
 
The TS-7100-Z I/O PCB in combination with the FPGA on the TS-7100, implements an electronic over-current breaker. When this breaker is tripped all three DIO Out paths will be disable, High-Side Switch output will be disabled, [[##4-20_mA|analog current loops]] will be disabled, and the red LED on the TS-7100-Z I/O board will be illuminated. That is, digital outputs will cease to sink or source any amount of current, and the AIN inputs will have 4-20 mA input disabled. The tripped breaker will also trigger a [[#Interrupts|DIO fault breaker interrupt]] as well as set the associated [[#GPIO|GPIO output, 7 10]]. The GPIO output, 7 10, must be cleared manually in order to reset the IRQ output. However, once the breaker trips, and the trip condition is cleared; all relevant GPIO settings can immediately be re-enabled without clearing this GPIO output bit.
 
 
 
''' Trip Conditions '''
 
 
See the table above for each DIO channel's maximum current rating. Note that the breaker does ''NOT'' enforce these ratings per DIO channel. The breaker will trip if the combined total amount of current sunk from all three digital outputs exceeds 1 A.
 
 
See the table above for the High-Side Switch's maximum current rating. If the rated max supply current is exceeded, the breaker will trip.
 
 
Note that all of these are in parallel. If the combined DIO sink current OR High-Side Switch current is exceeded, then the breaker will trip. The over-current breaker will also disable analog 4-20 mA current loop measurements.
 
  
 
== eMMC Interface ==
 
== eMMC Interface ==
{{Note|This section is incomplete at this time.}}
+
The i.MX6UL SD card controller supports the MMC specification, the TS-7250-V3 includes a soldered down eMMC IC to provide on-board flash media.     
The i.MX6UL SD card controller supports the MMC specification, the TS-7100 includes a soldered down eMMC IC to provide on-board flash media.     
 
  
 
Our default software image contains 2 partitions:
 
Our default software image contains 2 partitions:
Line 511: Line 431:
 
| Full Debian Linux partition
 
| Full Debian Linux partition
 
|}
 
|}
 
  
 
This platform includes an eMMC device, a soldered down MMC flash device. Our off the shelf builds are 4 GB, but up to 64 GB are available for customized builds.  The eMMC flash appears to Linux as an SD card at /dev/mmcblk0. The eMMC includes additional boot partitions that are used by U-Boot and are not affected by the eMMC partition table.
 
This platform includes an eMMC device, a soldered down MMC flash device. Our off the shelf builds are 4 GB, but up to 64 GB are available for customized builds.  The eMMC flash appears to Linux as an SD card at /dev/mmcblk0. The eMMC includes additional boot partitions that are used by U-Boot and are not affected by the eMMC partition table.
  
The eMMC module has a similar concern by default to SD cards in that they should not be powered down during a write/erase cycle.  However, this eMMC module includes support for setting a fuse for a "Write Reliability" mode, and a "psuedo SLC (pSLC)" mode.  With both of these enabled all writes will be atomic to 512 B and each NAND cell will be treated as a single layer rather than a multi-layer cell.  If a sector is being written during a power loss, a block is guaranteed to have either the old or new data.  Even in cases where the wrong data is present on the next boot, fsck is often able to deal with the older data being present in a 512 B block.  The downsides to setting these modes are that it will reduce the overall write speed and halve the available space on the eMMC to roughly 1.759 GiB.  Please note that even with these settings, Technologic Systems strongly recommends designing the end application to eliminate any situations where a power-loss event can occur while any disk is mounted as read/write.  The [[#TS-SILO Supercapacitors|TS-SILO option]] available on certain TS-7100 I/O boards can help to eliminate the dangerous situation.
+
The eMMC module has a similar concern by default to SD cards in that they should not be powered down during a write/erase cycle.  However, this eMMC module includes support for setting a fuse for a "Write Reliability" mode, and a "psuedo SLC (pSLC)" mode.  With both of these enabled all writes will be atomic to 512 B and each NAND cell will be treated as a single layer rather than a multi-layer cell.  If a sector is being written during a power loss, a block is guaranteed to have either the old or new data.  Even in cases where the wrong data is present on the next boot, fsck is often able to deal with the older data being present in a 512 B block.  The downsides to setting these modes are that it will reduce the overall write speed and halve the available space on the eMMC to roughly 1.759 GiB.  Please note that even with these settings, Technologic Systems strongly recommends designing the end application to eliminate any situations where a power-loss event can occur while any disk is mounted as read/write.
  
 
The '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|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|production mechanism scripting]] to complete these steps as part of an end application production process.
 
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|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|production mechanism scripting]] to complete these steps as part of an end application production process.
 
  
 
{{Warning|Enabling these modes causes all data on the disk to become invalid and must be rewritten.  Do not attempt to run the 'mmc' commands from the script individually, all steps in the script must occur as they are or the unit may be unable to boot.  If there are any failures of the script, care must be taken to resolve any issues while the unit is still booted or it may fail to boot in the future.}}
 
{{Warning|Enabling these modes causes all data on the disk to become invalid and must be rewritten.  Do not attempt to run the 'mmc' commands from the script individually, all steps in the script must occur as they are or the unit may be unable to boot.  If there are any failures of the script, care must be taken to resolve any issues while the unit is still booted or it may fail to boot in the future.}}
Line 524: Line 442:
 
{{Note|Enabling these modes is a one-way operation, it is not possible to undo them once they are made.  Because of this, setting these eMMC modes will invalidate Technologic Systems' return/replacement warranty on the unit.  See the [[#Limited_Warranty|warranty section]] for more information on this.}}
 
{{Note|Enabling these modes is a one-way operation, it is not possible to undo them once they are made.  Because of this, setting these eMMC modes will invalidate Technologic Systems' return/replacement warranty on the unit.  See the [[#Limited_Warranty|warranty section]] for more information on this.}}
  
 +
The 'emmc_reliability' script can be found in the [https://github.com/embeddedarm/ts7100-utils TS-7100 utilities github repository].
  
The 'emmc_reliability' script can be found in the [https://github.com/embeddedarm/ts7100-utils TS-7100 utilities github repository].
+
{{Warning|Do not run this on the p1 revision boards}}
  
 
The script must be run when boot from any media other than eMMC, such as NFS, or USB.  No partition of the eMMC disk can be mounted when these commands are run.  Doing so may result in corruption or inability for the unit to boot.  Once the pSLC mode is enabled, all data on the disk will become invalid.  This means the partition table will need to be re-created, the filesystems formatted, and all filesystem contents re-written to disk.  This is why we recommend using this script in conjunction with the [[#Production_Mechanism|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 must be run when boot from any media other than eMMC, such as NFS, or USB.  No partition of the eMMC disk can be mounted when these commands are run.  Doing so may result in corruption or inability for the unit to boot.  Once the pSLC mode is enabled, all data on the disk will become invalid.  This means the partition table will need to be re-created, the filesystems formatted, and all filesystem contents re-written to disk.  This is why we recommend using this script in conjunction with the [[#Production_Mechanism|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.   
Line 536: Line 455:
 
</source>
 
</source>
 
Upon successful run, the script will return 0.  Any errors will return a positive code.  See the script for detailed error code information.
 
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 ==
 
== Ethernet Ports ==
 
The NXP processor implements two 10/100 ethernet controllers with support built into the Linux kernel.  Standard Linux utilities such as ifconfig/ip can be used to control this interface.  See the [[#Configuring the Network|Configuring the Network]] section for more details.  For the specifics of this interface see the [http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/i.mx-applications-processors/i.mx-6-processors/i.mx6qp/i.mx-6ultralite-processor-low-power-secure-arm-cortex-a7-core:i.MX6UL?fpsp=1&tab=Documentation_Tab# CPU manual].
 
The NXP processor implements two 10/100 ethernet controllers with support built into the Linux kernel.  Standard Linux utilities such as ifconfig/ip can be used to control this interface.  See the [[#Configuring the Network|Configuring the Network]] section for more details.  For the specifics of this interface see the [http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/i.mx-applications-processors/i.mx-6-processors/i.mx6qp/i.mx-6ultralite-processor-low-power-secure-arm-cortex-a7-core:i.MX6UL?fpsp=1&tab=Documentation_Tab# CPU manual].
  
 +
== FPGA ==
 +
=== FPGA Registers ===
 +
The TS-7250-V3 FPGA is connected to the CPU over the WEIM bus.  This provides 8-bit, 16-bit, or 32-bit access to the FPGA mapped at 0x5000_0000. 
  
== FPGA ==
+
For example, to read the FPGA information at the first register of the syscon:
{{:TS-7100_FPGA}}
+
<source lang=bash>
 +
root@ts-imx6ul:~# memtool md -l 0x50004000+4
 +
50004000: 00000006
 +
</source>
 +
 
 +
{| class=wikitable
 +
|-
 +
! Offset
 +
! Description
 +
|-
 +
| 0x0000
 +
| [[#FPGA_16550|UART 16550 #0]]
 +
|-
 +
| 0x0100
 +
| [[#FPGA_SPI|Opencore SPI controller #0]]
 +
|-
 +
| 0x0120
 +
| [[#FPGA_SPI|Opencore SPI controller #1]]
 +
|-
 +
| 0x4000
 +
| [[#FPGA_Syscon|FPGA Syscon]]
 +
|-
 +
|}
 +
 
 +
 
 +
==== FPGA 16550 ====
 +
This FPGA includes a 16550 UART peripheral that can be used as a [[#UARTs|standard Linux serial port]]. It is not recommended to interact directly with these registers.
 +
 
 +
==== FPGA SPI ====
 +
This FPGA includes a pair of SPI master devices. These are used for the [[#FRAM|FRAM memory]], accessing the flash used for the [[#Splash_Screen|LCD splash screen image]], and the LCD touch screen itself. All of these operations are handled via the Linux kernel. It is not recommended to interact directly with these registers
 +
 
 +
==== FPGA Syscon ====
 +
The FPGA syscon is the main system control block of the FPGA. Contained in this region is the [[#GPIO|FPGA GPIO]], [[#PWM|PWM]], and IRQ control. It is not recommended to interact directly with these registers unless directed to do so by other manual sections.
 +
 
 +
Some registers are dual purpose, having separate read and write functionality; while others may only have write functionality. Registers that do not read and write the same are indicated with "(RD)" and "(WR)" notation. All other registers read and write the same data set. Any unlisted register addresses are Reserved / Undefined.
 +
 
 +
{| class=wikitable
 +
! Offset
 +
! Bits
 +
! Description
 +
|-
 +
| 0x00 (RD)
 +
| 31:0
 +
| Revision and Info Register.
 +
|-
 +
| 0x10 (RD)
 +
| 15:0
 +
| [[#GPIO|DIO bank 0 Pin State]]
 +
|-
 +
| 0x10 (WR)
 +
| 15:0
 +
| [[#GPIO|DIO bank 0 Data Set]]
 +
|-
 +
| 0x12 (WR)
 +
| 15:0
 +
| [[#GPIO|DIO bank 0 Output Enable Set]]
 +
|-
 +
| 0x14 (RD)
 +
| 15:0
 +
| [[#GPIO|DIO bank 0 Data]]
 +
|-
 +
| 0x14 (WR)
 +
| 15:0
 +
| [[#GPIO|DIO bank 0 Data Clear]]
 +
|-
 +
| 0x16 (RD)
 +
| 15:0
 +
| [[#GPIO|DIO bank 0 Output Enable]]
 +
|-
 +
| 0x16 (WR)
 +
| 15:0
 +
| [[#GPIO|DIO bank 0 Output Enable Clear]]
 +
|-
 +
| rowspan=2 | 0x1C (WR)
 +
| 15:4
 +
| Reserved
 +
|-
 +
| 3:0
 +
| [[#LCD Header|Duty cycle of LCD_BIAS]]
 +
|-
 +
| 0x20 (WR)
 +
| 31:0
 +
| [[#PWM|Fractional clock generator]] <ref>Note that this is also used for UART clock generation.</ref>
 +
|-
 +
| 0x24 (RD)
 +
| 31:0
 +
| [[#FPGA_IRQs|IRQ Status]]
 +
|-
 +
| 0x24 (WR)
 +
| 31:0
 +
| [[#PWM|Fractional PWM generator]]
 +
|-
 +
| 0x40 (RD)
 +
| 15:0
 +
| [[#GPIO|DIO bank 1 Pin State]]
 +
|-
 +
| 0x40 (WR)
 +
| 15:0
 +
| [[#GPIO|DIO bank 1 Data Set]]
 +
|-
 +
| 0x42 (WR)
 +
| 15:0
 +
| [[#GPIO|DIO bank 1 Output Enable Set]]
 +
|-
 +
| 0x44 (RD)
 +
| 15:0
 +
| [[#GPIO|DIO bank 1 Data]]
 +
|-
 +
| 0x44 (WR)
 +
| 15:0
 +
| [[#GPIO|DIO bank 1 Data Clear]]
 +
|-
 +
| 0x46 (RD)
 +
| 15:0
 +
| [[#GPIO|DIO bank 1 Output Enable]]
 +
|-
 +
| 0x46 (WR)
 +
| 15:0
 +
| [[#GPIO|DIO bank 1 Output Enable Clear]]
 +
|-
 +
| 0x48
 +
| 31:0
 +
| [[#FPGA_IRQs|IRQ mask]]
 +
|-
 +
| 0x50 (RD)
 +
| 15:0
 +
| [[#GPIO|DIO bank 2 Pin State]]
 +
|-
 +
| 0x50 (WR)
 +
| 15:0
 +
| [[#GPIO|DIO bank 2 Data Set]]
 +
|-
 +
| 0x52 (WR)
 +
| 15:0
 +
| [[#GPIO|DIO bank 2 Output Enable Set]]
 +
|-
 +
| 0x54 (RD)
 +
| 15:0
 +
| [[#GPIO|DIO bank 2 Data]]
 +
|-
 +
| 0x54 (WR)
 +
| 15:0
 +
| [[#GPIO|DIO bank 2 Data Clear]]
 +
|-
 +
| 0x56 (RD)
 +
| 15:0
 +
| [[#GPIO|DIO bank 2 Output Enable]]
 +
|-
 +
| 0x56 (WR)
 +
| 15:0
 +
| [[#GPIO|DIO bank 2 Output Enable Clear]]
 +
|}
 +
 
 +
<References />
 +
 
 +
==== FPGA IRQs ====
 +
{| class=wikitable
 +
! Bit
 +
! Description
 +
|-
 +
| 31:18
 +
| Reserved
 +
|-
 +
| 17
 +
| PC104 IRQ9
 +
|-
 +
| 16
 +
| PC104 IRQ7
 +
|-
 +
| 15
 +
| PC104 IRQ6
 +
|-
 +
| 14
 +
| PC104 IRQ5
 +
|-
 +
| 13
 +
| PC104 IRQ3
 +
|-
 +
| 12
 +
| SD busy
 +
|-
 +
| 11
 +
| SPI core #2 IRQ
 +
|-
 +
| 10
 +
| SPI core #1 IRQ
 +
|-
 +
| 9
 +
| SPI core #0 IRQ
 +
|-
 +
| 8:0
 +
| UART 8:0 IRQs
 +
|}
 +
 
 +
=== PC104 Bus ===
 +
{{:TS-7250-V3 PC104 bus}}
 +
 
 +
==== PC104 Bus MMAP ====
 +
{{:TS-7250-V3 PC104 MMAP}}
 +
 
 +
==== PC104 Peripherals ====
 +
{{:TS-7250-V3 PC104 Peripherals}}
 +
 
 +
===== TS-ADC16 =====
 +
{{:TS-7250-V3 TS-ADC16}}
 +
 
 +
<!--  ===== TS-ADC24 =====
 +
{{:TS-7250-V3 TS-ADC24}} -->
 +
 
 +
===== TS-BAT10 =====
 +
{{:TS-7250-V3 TS-BAT10}}
 +
 
 +
===== TS-DIO24 =====
 +
{{:TS-7250-V3 TS-DIO24}}
 +
 
 +
===== TS-DIO64 =====
 +
{{:TS-7250-V3 TS-DIO64}}
 +
 
 +
===== TS-ISO485 =====
 +
{{:TS-7250-V3 TS-ISO485}}
 +
 
 +
===== TS-MULTI104 =====
 +
{{:TS-7250-V3 TS-MULTI-104}}
 +
 
 +
===== TS-RELAY8 =====
 +
{{:TS-7250-V3 TS-RELAY8}}
 +
 
 +
===== TS-SER1 =====
 +
{{:TS-7250-V3 TS-SER1}}
 +
 
 +
===== TS-SER2 =====
 +
{{:TS-7250-V3 TS-SER2}}
 +
 
 +
===== TS-SER4 =====
 +
{{:TS-7250-V3 TS-SER4}}
 +
 
 +
===== TS-12W =====
 +
{{:TS-7250-V3 TS-12W}}
 +
 
 +
===== TS-13W =====
 +
{{:TS-7250-V3 TS-13W}}
 +
 
 +
===== TS-9422 =====
 +
{{:TS-7250-V3 TS-9422}}
  
 +
===== TS-9700 =====
 +
{{:TS-7250-V3 TS-9700}}
  
 
== FRAM ==
 
== FRAM ==
Line 550: Line 716:
  
 
The EEPROM file can be found at /sys/bus/spi/devices/spi32766.0/eeprom
 
The EEPROM file can be found at /sys/bus/spi/devices/spi32766.0/eeprom
 
  
 
== I2C ==
 
== I2C ==
Line 562: Line 727:
 
{{Note|This section is incomplete at this time.}}
 
{{Note|This section is incomplete at this time.}}
  
 
== LCD ==
 
=== Splash Screen ===
 
{{:240x320-LCD-splash-screen}}
 
 
The 'splash-convert' tool is available in the [https://github.com/embeddedarm/ts7100-utils TS-7100 utilities] repository.
 
 
 
The "splash.out" file can be written to the SPI NOR flash with the following command:
 
<source lang=bash>
 
dd if=/path/to/splash.out of=/dev/mtdblock0 bs=4096 conv=sync
 
</source>
 
Note that the "bs" and "conv" arguments should always be specified when writing to this SPI NOR device with 'dd' to ensure that the eraseblocks do not receive unnecessary erases and that a full eraseblock is written every time.
 
 
Also note that on the TS-7100, the SPI NOR flash is 2 MiB but the splash screen only consumes 152 KiB of space. The rest of this flash space can be used for general storage if wanted.
 
  
 
== LEDs ==
 
== LEDs ==
Line 592: Line 742:
  
 
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 [https://www.kernel.org/doc/Documentation/leds/leds-class.txt kernel LED documentation] for more information on triggers and general use of LED class devices.
 
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 [https://www.kernel.org/doc/Documentation/leds/leds-class.txt kernel LED documentation] for more information on triggers and general use of LED class devices.
 
  
 
== Relays ==
 
== Relays ==
Line 599: Line 748:
  
 
== Sleep ==
 
== Sleep ==
{{Note| This section is incomplete at this time.
+
{{:TS-7250-V3 Sleep mode}}
=== Suspend-to-RAM ===
 
  
 
== SPI ==
 
== SPI ==
Line 614: Line 762:
  
 
== UARTs ==
 
== UARTs ==
The TS-7100-Z offers 4 total UARTs for communication:
+
The TS-7250-V3 includes UARTs on the CPU, as well as 16550A compatible registers on the FPGA interface.
 +
 
 
{|class="wikitable sortable"
 
{|class="wikitable sortable"
 
! UART Dev.
 
! UART Dev.
Line 620: Line 769:
 
! TX / + Loc.
 
! TX / + Loc.
 
! RX / - Loc.
 
! RX / - Loc.
 +
! CTS
 +
! RTS
 +
! DCD
 +
! DTR
 
|-
 
|-
| ttymxc1
+
| ttymxc0
| RS-232
+
| USB Console
| [[#CN32_Terminal_Block|CN32 Terminal, pin 1]]
+
| P2 MicroUSB
| [[#CN32_Terminal_Block|CN32 Terminal, pin 7]]
+
| P2 MicroUSB
 +
| N/A
 +
| N/A
 +
| N/A
 +
| N/A
 
|-
 
|-
 
| ttymxc2
 
| ttymxc2
 
| Bluetooth
 
| Bluetooth
 +
| Onboard
 +
| Onboard
 +
| N/A
 +
| N/A
 
| N/A
 
| N/A
 
| N/A
 
| N/A
 
|-
 
|-
| ttymxc4
+
| ttymxc3
 +
| 3.3V TTL
 +
| [[#XBEE Header|XBEE pin 3]]
 +
| [[#XBEE Header|XBEE pin 2]]
 +
| [[#XBEE Header|XBEE pin 12]]
 +
| N/A
 +
| N/A
 +
| N/A
 +
|-
 +
| ttymxc6
 +
| 3.3V TTL
 +
| [[#MikroBus Header|MikroBus pin 13]]
 +
| [[#MikroBus Header|MikroBus pin 14]]
 +
| N/A
 +
| N/A
 +
| N/A
 +
| N/A
 +
|-
 +
| ttyS8
 
| RS-232
 
| RS-232
| [[#CN32_Terminal_Block|CN32 Terminal, pin 3]]
+
| [[#DB9 Connector|DB9 pin 3]]
| [[#CN32_Terminal_Block|CN32 Terminal, pin 5]]
+
| [[#DB9 Connector|DB9 pin 2]]
 +
| [[#DB9 Connector|DB9 pin 8]]
 +
| [[#DB9 Connector|DB9 pin 7]]
 +
| [[#DB9 Connector|DB9 pin 1]]
 +
| [[#DB9 Connector|DB9 pin 4]]
 
|-
 
|-
| ttyS0
+
| ttyS9
 +
| RS-232
 +
| [[#COM2 Header|COM2 pin 3]]
 +
| [[#COM2 Header|COM2 pin 2]]
 +
| [[#COM2 Header|COM2 pin 8]]
 +
| [[#COM2 Header|COM2 pin 7]]
 +
| N/A
 +
| N/A
 +
|-
 +
| ttyS10
 +
| RS-232
 +
| [[#COM3 Header|COM3 pin 3]]
 +
| [[#COM3 Header|COM3 pin 2]]
 +
| [[#COM3 Header|COM3 pin 8]]
 +
| [[#COM3 Header|COM3 pin 7]]
 +
| N/A
 +
| N/A
 +
|-
 +
| ttyS11
 
| RS-485
 
| RS-485
| [[#CN32_Terminal_Block|CN32 Terminal, pin 29]]
+
| [[#COM2 Header|COM2 pin 1]]
| [[#CN32_Terminal_Block|CN32 Terminal, pin 31]]
+
| [[#COM2 Header|COM2 pin 6]]
 +
| N/A
 +
| N/A
 +
| N/A
 +
| N/A
 
|-
 
|-
 +
| ttyS12
 +
| RS-485
 +
| [[#COM2 Header|COM2 pin 4]]
 +
| [[#COM2 Header|COM2 pin 9]]
 +
| N/A
 +
| N/A
 +
| N/A
 +
| N/A
 
|}
 
|}
  
 +
=== 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|UARTs section]] for the location of the RS-485 port.
  
=== RS-485 ===
+
=== RS-422 ===
RS-485 is implemented via a UART interface inside of the FPGA. This device handles automatic TXEN assertion and de-assertion for half-duplex RS-485 communication. See the [[#UARTs|UARTs section]] for the location of the RS-485 port.
+
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 ==
 
== USB ==
The TS-7100-Z offers two USB 2.0 host ports. One port that is always available and usable is the bottom port of the USB A host port stack. The top port is switchable, and instead can be connected to the USB pins of an installed XBee device or NimbeLink modem inserted in to the [[#CN16_XBee_Socket|CN16 socket]].
+
The TS-7250-V3 offers two USB 2.0 host ports. Power to the host ports can be controlled with the LED subsystem under the LED device "/sys/class/leds/en-usb-5v/". By writing a value greater than 0 to the "brightness" file in that folder, it will enable USB power. While setting it to 0 will turn it off.  See the [[#Special_DIO|DIO section]] of the manual for more information on this. The USB A host port stack can provide 1 A total power output shared between the two ports.
 
 
Power to the host ports can be controlled with the LED subsystem under the LED device "/sys/class/leds/en-usb-5v/". By writing a value greater than 0 to the "brightness" file in that folder, it will enable USB power. While setting it to 0 will turn it off.  See the [[#Special_DIO|DIO section]] of the manual for more information on this. The USB A host port stack can provide 1 A total power output shared between the two ports.
 
 
 
  
 
== Watchdog ==
 
== Watchdog ==
Line 661: Line 873:
  
 
= Specifications =
 
= Specifications =
{{Note|This section is incomplete at this time.}}
+
== Power Input Specifications ==
== Power Specifications ==
+
{{:TS-7250-V3 Power Supply Specifications}}
The TS-7100-Z accepts a range of voltages from 8 V to 28 V DC.
 
 
 
  
 
== Power Consumption ==
 
== Power Consumption ==
 +
{{:TS-7250-V3 Power Consumption}}
  
 
+
== Board Rails ==
=== TS-SILO SuperCaps ===
+
{{:TS-7250-V3 Board Rails}}
 
 
  
 
= External Interfaces =
 
= External Interfaces =
{{Note|This section is incomplete at this time.}}
+
== ADC Header ==
 
+
{{:TS-7250-V3 ADC Header}}
 +
== Battery Connector ==
 +
{{:TS-7250-V3 Battery Connector}}
 +
== COM2 Header ==
 +
{{:TS-7250-V3 COM2 Header}}
 +
== COM3 Header ==
 +
{{:TS-7250-V3 COM3 Header}}
 +
== DB9 Connector ==
 +
{{:TS-7250-V3 DB9 Connector}}
 +
== DIO Header ==
 +
{{:TS-7250-V3 DIO Header}}
 +
== Ethernet connectors ==
 +
{{:TS-7250-V3 Ethernet Connectors}}
 +
== LCD Header ==
 +
{{:TS-7250-V3 LCD Header}}
 +
== MikroBus Header ==
 +
{{:TS-7250-V3 MikroBus Header}}
 +
== MicroSD Connector ==
 +
{{:TS-7250-V3 MicroSD Connector}}
 +
== MicroUSB Connector ==
 +
{{:TS-7250-V3 MicroUSB Connector}}
 +
== PC104 Header ==
 +
{{:TS-7250-V3 PC104 Header}}
 +
== Power Connectors ==
 +
{{:TS-7250-V3 Power Connectors}}
 +
== USB Ports ==
 +
{{:TS-7250-V3 USB Ports}}
 +
== XBEE Header ==
 +
{{:TS-7250-V3 XBEE Header}}
  
 
= Revisions and Changes =
 
= Revisions and Changes =

Latest revision as of 18:13, 13 July 2020

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


TS-7250-V3
Product Page
Documentation
Schematic
Mechanical Drawing
FTP Path
Processor
NXP i.MX6UL
528MHz or 696MHz
i.MX6UL Product Page
CPU Documentation

Contents

1 Overview

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

2 Getting Started

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

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

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

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

2.1 Connect USB Console

The board includes a USB Micro header connected to the onboard preprogrammed microcontroller. This acts as a USB serial device using the CP210x Virtual COM port. Most operating systems have built-in support for this device, however drivers are available here.


Console from Linux

There are many serial terminal applications for Linux, three common used applications are 'picocom', 'screen', and 'minicom'. These examples demonstrate all three applications and assume that the serial device is "/dev/ttyUSB0" which is common for USB adapters. Be sure to replace the serial device string with that of the device on your workstation.

'picocom' is a very small and simple client.

picocom -b 115200 /dev/ttyUSB0


'screen' is a terminal multiplexer which happens to have serial support.

screen /dev/ttyUSB0 115200


Or a very commonly used client is 'minicom' which is quite powerful but requires some setup:

minicom -s
  • Navigate to 'serial port setup'
  • Type "a" and change location of serial device to '/dev/ttyUSB0' then hit "enter"
  • If needed, modify the settings to match this and hit "esc" when done:
     E - Bps/Par/Bits          : 115200 8N1
     F - Hardware Flow Control : No
     G - Software Flow Control : No
  • Navigate to 'Save setup as dfl', hit "enter", and then "esc"


Console from Windows

Putty is a small simple client available for download here. Open up Device Manager to determine your console port. See the putty configuration image for more details.

Device Manager Putty Configuration

2.2 Powering up

The TS-7250-V3 receives power through either the 5VDC 2pin terminal block connector near the DB9, or the 2 pin 8-28VDC terminal block near the mikrobus connector.

If a power supply is ordered with the TS-7250-V2 it will include the correct terminal block connected to the power supply. Otherwise the terminal block will ship with the unit.

Note: The polarity is marked underneath the removable terminal blocks.

Once power is applied the device will output information via the built in USB console.

The first output is from U-Boot:

Trying to boot from MMC1


U-Boot 2020.01-00009-g99e2080fad (Mar 12 2020 - 08:43:22 -0700)

CPU:   Freescale i.MX6UL rev1.2 696 MHz (running at 396 MHz)
CPU:   Automotive temperature grade (-40C to 125C) at 44C
Reset cause: POR
Model: Technologic Systems i.MX6UL TS-7250-V3
Board: TS-7250-V3
DRAM:  512 MiB
MMC:   FSL_SDHC: 0
Loading Environment from MMC... *** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   
Warning: ethernet@20b4000 using MAC address from ROM
eth1: ethernet@20b4000
Warning: ethernet@2188000 using MAC address from ROM
, eth0: ethernet@2188000
Press ESC twice to abort autoboot in 1 second(s)
Note: The message "*** Warning - bad CRC, using default environment" can be safely ignored. This indicates that u-boot scripts are not being customized. Typing "env save" will hide these messages, but this is not needed.
Note: The message "using MAC address from ROM" is indicating that the board is using the preprogrammed MAC address as intended. All boards are assigned 2 unique MAC addresses.

This u-boot and its environment is loaded from the SPI flash (/dev/mmcblk0boot0). This a hardware partition that is independent of the main flash on the emmc (/dev/mmcblk0). From here, u-boot will follow u-boots standard Distro boot command. This will check for boot files on the first USB mass storage, and will by default find a bootable image on eMMC. From here the board will boot to our default #Debian image.

2.3 First Linux Boot

When booting with the default settings, a shipped board will boot to the eMMC. The eMMC by default are pre-programmed with our default Debian 10 Buster image. After Linux boots it will ask the user to log in with a username and password. This uses "root" as the username with no password. This can be changed after logging in with the command "passwd" to set an account password.

From the Linux prompt you can now begin testing out hardware, or beginning your application development.

2.4 Booting from USB

This board supports booting to an OS image written to a USB drive. This requires a Linux system to write the USB image.

Note: This can be run from the board while booted to eMMC, but this should not rewrite the same USB stick that the system has used to boot. Rewriting an image while it is used as the boot media will result in a corrupt image.

Check lsblk or dmesg to find your USB drive, but the following examples will assume /dev/sdc.

wget http://ftp.embeddedarm.com/ftp/ts-arm-sbc/ts-7250-v3-linux/distributions/debian/tsimx6ul-debian-buster-latest.tar.bz2
sudo sgdisk --zap-all /dev/sdc
sudo sgdisk -n 0:0:0 -t 0:8300 /dev/sdc
sudo mkfs.ext4 /dev/sdc1
sudo mkdir /mnt/usb/
sudo mount /dev/sdc1 /mnt/usb/
sudo tar --numeric-owner -xf tsimx6ul-debian-buster-latest.tar.bz2 -C /mnt/usb/
sudo umount /mnt/usb/

If this USB is plugged into USB on startup, it will be chosen instead of the onboard eMMC. For example:

U-Boot 2020.01-00009-g99e2080fad (Mar 12 2020 - 08:43:22 -0700)

CPU:   Freescale i.MX6UL rev1.2 696 MHz (running at 396 MHz)
CPU:   Automotive temperature grade (-40C to 125C) at 34C
Reset cause: POR
Model: Technologic Systems i.MX6UL TS-7250-V3
Board: TS-7250-V3
DRAM:  512 MiB
MMC:   FSL_SDHC: 0
Loading Environment from MMC... *** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   
Warning: ethernet@20b4000 using MAC address from ROM
eth1: ethernet@20b4000
Warning: ethernet@2188000 using MAC address from ROM
, eth0: ethernet@2188000
Press ESC twice to abort autoboot in 1 second(s)
starting USB...
Bus usb@2184000: USB EHCI 1.00
Bus usb@2184200: USB EHCI 1.00
scanning bus usb@2184000 for devices... 1 USB Device(s) found
scanning bus usb@2184200 for devices... 2 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found

Device 0: Vendor: SanDisk  Rev: 0001 Prod: Extreme         
            Type: Removable Hard Disk
            Capacity: 59836.1 MB = 58.4 GB (122544516 x 512)
... is now current device
Scanning usb 0:1...
Found U-Boot script /boot/boot.scr
675 bytes read in 8 ms (82 KiB/s)
## Executing script at 82000000
5348808 bytes read in 145 ms (35.2 MiB/s)
33863 bytes read in 8 ms (4 MiB/s)
Booting Debian from usb 0:1...
## Flattened Device Tree blob at 83000000
   Booting using the fdt blob at 0x83000000
   Loading Device Tree to 9ef68000, end 9ef73446 ... OK

Starting kernel ...

[    0.005353] /cpus/cpu@0 missing clock-frequency property
[    0.909176] spi_imx 2010000.ecspi: dma setup error -19, use pio
[    0.931343] spidev spi32766.0: buggy DT: spidev listed directly in DT
[    2.891057] EXT4-fs (sda1): couldn't mount as ext3 due to feature incompatibilities
[    3.633452] cgroup: cgroup2: unknown option "nsdelegate"

Welcome to Debian GNU/Linux 10 (buster)!

3 U-Boot

U-boot is a bootloader and comes preinstalled on this board. This is loaded in the eMMC hardware boot partitions in /dev/mmcblk0boot0. U-boot sets up the hardware and then loads the OS from the available storage devices. Most users will not need to customize u-boot further, and can proceed to the #Debian sections for information on application development.

3.1 U-boot Distro Boot

U-boot by default uses u-boots distro bootcmd to determine how to boot. As shipped the board will boot to the preprogrammed eMMC with our #Debian image.

By default this will look at:

Order U-boot device name Description
1 usb0 First detected USB mass storage device
3 mmc0 Onboard eMMC storage
4 dhcp DHCP Option [1]
5 pxe PXE File [2]
  1. DHCP can advertise a TFTP server (next-path, root-path, and filename) to point to a u-boot script.
  2. DHCP can advertise a TFTP server (next-path, root-path, and filename) with a PXE file to control boot.

The default boot order can be left for most users, but boot can be optimized for one boot device by stopping at u-boot and running:

# Boot straight to mmc:
env set boot_targets 'mmc0';
env save

# Boot to usb, then mmc only
env set boot_targets 'usb0 mmc0';
env save

# Set back to default boot order
env set boot_targets 'usb0 mmc0 dhcp pxe'
env save

U-boot will search the boot media on either the 1st partition, or if the disk is partitioned with GPT instead of MBR it will search the "bootable" partition. It will then search for these files:

Order Search for Paths Description
1 extlinux /extlinux/extlinux.conf, /boot/extlinux/extlinux.conf Menu conf file of kernels
2 U-boot script /boot.scr.uimg, /boot.scr, /boot/boot.scr.uimg, /boot/boot.scr u-boot script with instructions to load the OS
3 EFI Binary efi/boot/bootarm.efi EFI binary (such as grub)

Our Debian images use a u-boot script in /boot/boot.scr.uimg.

3.2 U-Boot Environment

The U-Boot environment is stored in the on-board eMMC flash in the /dev/mmcblk0boot0 partition.

# Print all environment variables
env print -a

# Sets the variable bootdelay to 5 seconds
env set bootdelay 5

# Variables can also contain commands
env set hellocmd 'led 0 off; echo Hello world; led 1 on;'

# Execute commands saved in a variable
env run hellocmd

# Commit env changes to the spi flash
# Otherwise changes are lost
env save

# Restore env to default
env default -a

# Remove a variable
env delete hellocmd

3.3 U-Boot Development

TS-7250-V3 U-boot development

4 Debian 10

Debian is a community run Linux distribution. Debian provides tens of thousands of precompiled applications and services. This distribution is known for stability and large community providing support and documentation. The installation is specific to our board, but most Debian documentation applies:

4.1 Debian 10 - Getting Started and writing an Image

Once installed, the default user is "root" with no password.

Note: This is a shared image that supports the TS-7100 and TS-7250-V3

This image can be written to a USB drive, or to the eMMC. For development, a USB thumbdrive will be simplest. If a bootable USB drive is connected this will take priority over other boot media. Plug in a USB drive and check the last output from "dmesg" to get the USB disk. For example, this may be /dev/sdc.

# Erase all older partitions
sudo sgdisk --zap-all /dev/sdc
# Create one GPT Linux partition
sudo sgdisk -n 0:0:0 -t 0:8300 /dev/sdc
# Create a filesystem and mount
sudo mkfs.ext4 /dev/sdc1
sudo mkdir /mnt/usb/
sudo mount /dev/sdc1 /mnt/usb/
# Extract downloaded image:
sudo tar --numeric-owner -xf tsimx6ul-debian-buster-latest.tar.xz -C /mnt/usb/
sudo chmod 755 /mnt/usb/
sudo umount /mnt/usb/

These commands will also work while booted from a USB drive to rewrite the eMMC. Instead of /dev/sdc you would use /dev/mmcblk0, and instead of /dev/sdc1 you would use /dev/mmcblk0p1.

4.2 Debian 10 - Configuring Network

The network in Debian is configured /etc/network/interfaces.d/. For complete documentation, see Debian's documentation here

Some common examples are shown below.

DHCP on eth0:

tee /etc/network/interfaces.d/eth0 <<'EOF' >/dev/null
auto eth0
allow-hotplug eth0
iface eth0 inet dhcp
EOF

Static IP on eth0:

tee /etc/network/interfaces.d/eth0 <<'EOF' >/dev/null
auto eth0
iface eth0 inet static
    address 192.0.2.7/24
    gateway 192.0.2.254

4.3 Debian 10 - Installing New Software

Debian provides the apt-get system which allows management of pre-built applications. The apt tools require a network connection to the internet in order to automatically download and install new software. The update command will download a list of the current versions of pre-built packages.

apt-get update

A common example is installing Java runtime support for a system. Find the package name first with search, and then install it.

root@tsa38x:~# apt-cache search openjdk
default-jdk - Standard Java or Java compatible Development Kit
default-jdk-doc - Standard Java or Java compatible Development Kit (documentation)
default-jdk-headless - Standard Java or Java compatible Development Kit (headless)
default-jre - Standard Java or Java compatible Runtime
default-jre-headless - Standard Java or Java compatible Runtime (headless)
jtreg - Regression Test Harness for the OpenJDK platform
libreoffice - office productivity suite (metapackage)
openjdk-11-dbg - Java runtime based on OpenJDK (debugging symbols)
openjdk-11-demo - Java runtime based on OpenJDK (demos and examples)
openjdk-11-doc - OpenJDK Development Kit (JDK) documentation
openjdk-11-jdk - OpenJDK Development Kit (JDK)
openjdk-11-jdk-headless - OpenJDK Development Kit (JDK) (headless)
openjdk-11-jre - OpenJDK Java runtime, using Hotspot JIT
openjdk-11-jre-headless - OpenJDK Java runtime, using Hotspot JIT (headless)
openjdk-11-jre-zero - Alternative JVM for OpenJDK, using Zero
openjdk-11-source - OpenJDK Development Kit (JDK) source files
uwsgi-app-integration-plugins - plugins for integration of uWSGI and application
uwsgi-plugin-jvm-openjdk-11 - Java plugin for uWSGI (OpenJDK 11)
uwsgi-plugin-jwsgi-openjdk-11 - JWSGI plugin for uWSGI (OpenJDK 11)
uwsgi-plugin-ring-openjdk-11 - Closure/Ring plugin for uWSGI (OpenJDK 11)
uwsgi-plugin-servlet-openjdk-11 - JWSGI plugin for uWSGI (OpenJDK 11)
java-package - Utility for creating Java Debian packages

In this case, the wanted package will likely be the "openjdk-11-jre" package. Names of packages can be found on Debian's wiki pages or the packages site.

With the package name apt-get install can be used to install the prebuilt packages.

apt-get install openjdk-11-jre
# More than one package can be installed at a time.
apt-get install openjdk-11-jre nano vim mplayer

For more information on using apt-get refer to Debian's documentation here.

4.4 Debian 10 - Setting Up SSH

Openssh is installed in our default Debian image, but by default openssh does not permit root logins, and requires a password to be set. To allow remote root login:

sed --in-place 's/#PermitRootLogin prohibit-password/PermitRootLogin yes/' /etc/ssh/sshd_config
systemctl restart ssh.service
passwd root # Set any password

If you ssh to this system it will now support ssh as root.

4.5 Debian 10 - Starting Automatically

A systemd service can be created to start up headless applications. Create a file in /etc/systemd/system/yourapp.service

[Unit]
Description=Run an application on startup

[Service]
Type=simple
ExecStart=/usr/local/bin/your_app_or_script

[Install]
WantedBy=multi-user.target

If networking is a dependency add "After=network.target" in the Unit section. Once you have this file in place add it to startup with:

# Start the app on startup, but will not start it now
systemctl enable yourapp.service

# Start the app now, but doesn't change auto startup
systemctl start yourapp.service
Note: See the systemd documentation for in depth documentation on services.

4.6 Debian 10 - Cross Compiling

Debian only provides their cross compiler for their distribution. Our examples will set up a Docker for Debian to use for development. If using Debian 10 Buster directly, or through a VM then the docker usage can be skipped.

Create a file called "Dockerfile" with these contents:

FROM debian:buster

RUN dpkg --add-architecture armhf

RUN apt-get update && apt-get install -y \
    autogen \
    automake \
    bash \
    bc \
    build-essential \
    bzip2 \
    ca-certificates \
    curl \
    fakeroot \
    file \
    gcc-arm-linux-gnueabihf \
    git \
    gzip \
    kmod \
    libgpiod-dev:armhf \
    libncursesw5-dev \
    libtool \
    lzop \
    make \
    multistrap \
    ncurses-dev \
    pkg-config \
    python \
    qemu-user-static \
    rsync \
    runit \
    u-boot-tools \
    vim \
    wget \
    xz-utils

In the same directory as the file named "Dockerfile" run:

docker build --tag armhf-buster-toolchain .

When this has finished the docker can be used with:

docker run --rm -it --volume $(pwd):/work armhf-buster-toolchain bash

This will map the current directory to /work.

At this point the Debian Docker is ready to compile armhf binaries. For example, create a hello world in your home folder at ~/hello.c

#include <stdio.h>
int main(){
    printf("Hello World\n");
}

To compile this enter the docker with:

docker run -it --volume $(pwd):/work armhf-buster-toolchain bash
# Then from the docker:
cd /work/
arm-linux-gnueabihf-gcc hello.c -o hello

Check "file hello" to verify the binary type:

mark@mark-desktop:~/$ file hello
hello: ELF 32-bit LSB pie executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=8a8cee3341d3ef76ef6796f72d5722ae9d77c8ea, not stripped

This can also be used to develop against dynamic libraries from Debian. The armhf packages can be installed in the Docker. For example, to link against curl:

# Enter the Docker:
docker run -it --volume $(pwd):/work armhf-buster-toolchain bash
cd /work/

apt-get install libcurl4-openssl-dev:armhf
# Download curl's simple.c example
wget https://raw.githubusercontent.com/bagder/curl/master/docs/examples/simple.c
arm-linux-gnueabihf-gcc simple.c -o simple -lcurl

The "simple" binary is now built for armhf and links dynamically to curl.

This will only retain the armhf libcurl package until the docker is exited. To make the changes permanent, add the package to the Dockerfile and rerun:

docker build --tag armhf-buster-toolchain .

4.7 Debian 10 - Backup the image

Buster backup the image

4.8 Debian 10 - Compile the Kernel

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

Enter the cross compile environment:

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

Inside the docker run:

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

export ARCH=arm
export CROSS_COMPILE=arm-linux-gnueabihf-
export TEMP=$(mktemp -d)

make tsimx6ul_defconfig

# Make customizations here

make -j $(nproc --all) all zImage

mkdir "$TEMP/boot/"
cp arch/arm/boot/zImage "$TEMP"/boot/zImage
cp arch/arm/boot/dts/imx6*-ts*.dtb "$TEMP"/boot/ 
INSTALL_MOD_PATH="$TEMP" make modules_install
tar czf kernel.tar.gz -C "$TEMP" .
exit

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

tar -xf kernel.tar.gz -C /

This can also be added to an image with:

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

5 Buildroot

The full-featured stock 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. To assist customers heading down this path we have a created a git tree that uses BR_EXTERNAL to add support for our boards with an unmodified copy of the buildroot git. The buildroot must be compiled from sources to generate an image.

5.1 Buildroot - Compiling an Image

The default image for the TS-7250-V3 generates a minimalistic OS of around 30MiB. This includes the kernel, device tree, boot scripts and the bare minimum linux os to run busybox. Any other libraries besides uclibc would need to be added.

git clone https://github.com/embeddedarm/buildroot-ts.git
cd buildroot-ts
git submodule update --init
make ts7250v3_defconfig
make

6 USB Production Method

The TS-7250-V3 supports using a USB thumbdrive to rewrite the onboard media. If the USB media is present on startup it will be chosen instead of eMMC. The startup script will:

  • Turn on the RED LED
  • Rewrite emmc/sd/u-boot as requested
  • Blink green to indicate a pass

* Blinking red indicates a failure. See the console output for more details.

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

wget http://ftp.embeddedarm.com/ftp/ts-arm-sbc/ts-7250-v3-linux/usb-blaster/ts725v3-usb-production-rootfs-latest.tar.bz2

# This assumes USB drive is /dev/sdc:
sudo mkfs.ext3 /dev/sdc1
sudo mkdir /mnt/usb/
sudo mount /dev/sdc1 /mnt/usb/
sudo tar --numeric-owner -xf /path/to/ts725v3-usb-production-rootfs-latest.tar.bz2 -C /mnt/usb/

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

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

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

Most users should be able to use the above script without modification. Our buildroot sources are available from our github repo with instructions to rebuild this "ts7250v3_usbprod_defconfig" target.

7 Features

7.1 ADC

This board supports 5 channels of 12-bit ADC using an integrated ADC in the i.MX6UL CPU. All channels can sample 0-10VDC, but channels 1-3 can optionally sample 0-20mA as a current loop. 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.

These ADCs are accessed through the IIO layer in Linux. This provides ADC samples up to 6ksps between all channels. The simplest API for slow speed acquisition is through /sys/:

cat /sys/bus/iio/devices/iio\:device0/in_voltage{0,1,5,8,9}_raw
ADC Header Pin Schematic Name IIO device IIO name Voltage Current loop
1 AN_CH1 iio:device0 voltage0 0-30VDC 0-20mA
3 AN_CH2 iio:device0 voltage1 0-30VDC 0-20mA
5 AN_CH3 iio:device0 voltage5 0-30VDC 0-20mA
7 AN_CH4 iio:device0 voltage8 0-30VDC N/A
8 AN_CH5 iio:device0 voltage9 0-30VDC N/A

The current loops are enabled/disabled with GPIO:

gpioset 4 7=0 # AN_CH1 voltage
gpioset 4 8=0 # AN_CH2 voltage
gpioset 4 9=0 # AN_CH3 voltage

gpioset 4 7=1 # AN_CH1 current
gpioset 4 8=1 # AN_CH2 current
gpioset 4 9=1 # AN_CH3 current

The libiio library provides simple access to the IO. The fastest API is in C which will get about 6ksps.

/* Build with gcc adc-test.c -o adc-test -liio 
 * Gets ~6ksps
 * 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)
{
	/* fractions $((330+22)) 22 2500 4095 */
	uint32_t val = raw * 9;
	val += (raw * 629) / 819;

	return val;
}

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;
}

The python bindings currently achieve about 2ksps with similar code.

#!/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))

7.2 Battery Backed RTC

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

7.3 Bluetooth

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

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

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

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

hcitool lescan

This will return a list of devices such as:

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

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

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

The module supports some other commands as well:

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

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

7.4 CAN

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

These interfaces can be brought up with:

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


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

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

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


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

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

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

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

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

int main(void)
{
	int s;
	int nbytes;
	struct sockaddr_can addr;
	struct can_frame frame;
	struct ifreq ifr;
	struct iovec iov;
	struct msghdr msg;
	char ctrlmsg[CMSG_SPACE(sizeof(struct timeval)) + CMSG_SPACE(sizeof(__u32))];
	char *ifname = "can0";
 
	if((s = socket(PF_CAN, SOCK_RAW, CAN_RAW)) < 0) {
		perror("Error while opening socket");
		return -1;
	}
 
	strcpy(ifr.ifr_name, ifname);
	ioctl(s, SIOCGIFINDEX, &ifr);
	addr.can_family  = AF_CAN;
	addr.can_ifindex = ifr.ifr_ifindex;
 
	if(bind(s, (struct sockaddr *)&addr, sizeof(addr)) < 0) {
		perror("socket");
		return -2;
	}
 
 	/* For the ozen myOByDic 1610 this requests the RPM guage */
	frame.can_id  = 0x7df;
	frame.can_dlc = 3;
	frame.data[0] = 3;
	frame.data[1] = 1;
	frame.data[2] = 0x0c;
 
	nbytes = write(s, &frame, sizeof(struct can_frame));
	if(nbytes < 0) {
		perror("write");
		return -3;
	}

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

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

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

	if(frame.data[0] == 0x4)
		printf("RPM at %d of 255\n", frame.data[3]);
 
	return 0;
}

See the Kernel's CAN documentation here. Other languages have bindings to access CAN such as Python using C-types, Java using JNI.

7.5 CPU

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

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

7.6 GPIO

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

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

gpioget 4 0

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

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

gpioset 4 4=1

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

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

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

Schematic Net Name Chip Pin Location
AN_CH1 0 0 ADC Pin 1
AN_CH2 0 1 ADC Pin 3
EN_SD_CARD_3.3V 0 4 Onboard
AN_CH3 0 5 ADC Pin 5
AN_CH4 0 8 ADC Pin 7
AN_CH5 0 9 ADC Pin 9
TXD1_485_STRAP 0 16 Board Variants
TXD2_485_STRAP 0 17 Board Variants
COM3_TXD_STRAP 0 18 Board Variants
COM2_TXD_STRAP 0 19 Board Variants
GYRO_INT 4 0 Onboard
FPGA_IRQ 4 1 Onboard
EN_EMMC_3.3V 4 2 Onboard
EN_CL_1 4 7 #ADC Header
EN_CL_2 4 8 #ADC Header
EN_CL_3 4 9 #ADC Header
EN_RED_LED# 0 18 #LEDs
EN_GRN_LED# 0 19 #LEDs
EN_XBEE_USB 0 21 Onboard
MAGNET_IRQ 0 14 Onboard
FPGA_RESET 0 13 Onboard
ISA_RESET 2 7 PC104 B2
ISA_IOCHK 2 8 PC104 A1
LCD_PIN7 2 9 LCD Header pin 7
LCD_PIN8 2 10 LCD Header pin 8
LCD_PIN9 2 11 LCD Header pin 9
LCD_PIN10 2 12 LCD Header pin 10
LCD_PIN11 2 15 LCD Header pin 11
LCD_PIN12 2 16 LCD Header pin 12
LCD_PIN13 2 17 LCD Header pin 13
LCD_PIN14 2 18 LCD Header pin 14
LCD_WR# 2 19 LCD Header pin 6
LCD_EN 2 20 LCD Header pin 5
LCD_RS 2 23 LCD Header pin 3
LCD_BIAS 2 24 LCD Header pin 4
NIM_PWR_ON 2 25 Onboard
EN_DIO_FET 2 27 DIO Header pin 4
SEL_XBEE_USB 2 28 Onboard
EN_USB_5V 2 0 Onboard
FPGA_FLASH_SELECT 3 0 Onboard
DETECT_94-120 3 1 Onboard


7.7 eMMC Interface

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

Our default software image contains 2 partitions:

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

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

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

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

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

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

WARNING: Do not run this on the p1 revision boards

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

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

Example usage:

./emmc_reliability /dev/mmcblk0

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

7.8 Ethernet Ports

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

7.9 FPGA

7.9.1 FPGA Registers

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

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

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


7.9.1.1 FPGA 16550

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

7.9.1.2 FPGA SPI

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

7.9.1.3 FPGA Syscon

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

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

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

7.9.1.4 FPGA IRQs

Bit Description
31:18 Reserved
17 PC104 IRQ9
16 PC104 IRQ7
15 PC104 IRQ6
14 PC104 IRQ5
13 PC104 IRQ3
12 SD busy
11 SPI core #2 IRQ
10 SPI core #1 IRQ
9 SPI core #0 IRQ
8:0 UART 8:0 IRQs

7.9.2 PC104 Bus

The TS-7250-V3 includes an ISA bus for compatibility with PC104 peripherals. ARM itself has not traditionally had an ISA bus as part of its architecture, so this behaves differently than an X86 where ISA is typically used.

To access the PC104 bus in userspace, open, read, and write the files here:

/sys/devices/soc0/soc/2100000.aips-bus/21b8000.weim/21b8000.weim:fpga@50000000/50004000.syscon/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 an alternate pinout
mem8 8-bit strobes on MEMR/MEMW
mem16 16-bit strobes on MEMR/MEMW
memalt16 16-bit strobes on MEMR/MEMW with an alternate pinout

Any programming language can interface with these using standard file IO. Open a file descriptor to one or more of these files, and seek to the offset of the address you are accessing. Use read/write calls to access data on these busses.

For 16-bit accesses the address must always be aligned to an even byte, and reads/writes must always access multiple of 2 bytes at a time.

For C, or languages with a foreign function interface, we provide a library / header which can be used to handle these accesses.

There is also a command line utility to access the pc104 bus:

root@tsimx6:~# pc104_peekpoke 
Usage pc104_peekpoke <io/mem> <8/16/alt16> <address> [value]
	Eg: pc104_peekpoke io 8 0x140

For kernel access to the PC104 bus see the header here. Using the existing kernel driver will handle locking between userspace and any kernel drivers such as PC104 based UARTs.

On PC104 peripherals these typically have IRQs such as IRQ5/IRQ6/IRQ7. On ARM these are mapped to other IRQ numbers. Using the fpga_intc driver, interrupts on 14/15/16 correspond with the pins on the PC104 header labelled IRQ 5, 6, and 7.

We strongly recommend using the methods described above for accessing the PC104 bus. For users needing to understand the implementation, the registers are described below.

The FPGA presents a 32-bit memory window at 0x50004050 which follows this format:

Bits Description
31 Busy/Go [1]
30 1 = IO, 0 = MEM [2]
29 1 = 8-bit, 0 = 16-bit
28 1 = read cycle, 0 = write cycle
27 0 = standard pinout, 1 = TS Pinout [3]
26:0 Address or Data [4]
  1. On read, a 1 indicates the existing transaction is already busy. A 0 indicates it is available. If written to 0 then bits 26:0 specify address. If written to 1 this starts the bus cycle.
  2. Cycle type indicates if we use IOW/IOR pins, or MEMR/MEMW.
  3. The TS pinout is used on some platforms to remove the need for the 40-pin connnector while still supporting 16-bit peripherals. This does not affect 8-bit accesses. When enabled this uses these pins for the upper 16-bit.
    PC104 pin Data bit
    B4 8
    B17 9
    B18 10
    B25 11
    B20 12
    B26 13
    B14 14
    B28 15
  4. Accepts a written addr when BUSY/GO = 0. This is data on a write when Busy/GO=1, or on a read after BUSY/GO reads 0 after being written to 1.

7.9.2.1 PC104 Bus MMAP

On some previous PC104 implementations the PC104 bus was able to be directly memory mapped. While it is not possible on this hardware to access the bus the same way, we do have a compatibility layer that is able to expose the PC104 bus as if it were memory mapped.

#include <stdio.h>
#include <stdint.h>
#include <unistd.h>
#include <assert.h>

#include "pc104.h"

volatile uint8_t *bus;

int main(int argc, char **argv)
{
	uint8_t i = 0;

	bus = pc104_mmap_init();
	assert(bus != NULL);
	if(bus[0x140] != 0x9b) {
		fprintf(stderr, "TS-RELAY8 not found\n");
	}
	while(1) {
		bus[0x142] = i++;
		usleep(10 * 1000);
	}

}

Accesses below 0x100000 cause IO accesses. Accesses from 0x100000 to 0x200000 cause MEM accesses. This code turns these mmap accesses into pc104_io/mem_8/16 calls.

This example must be compiled with:

gcc -marm test.c pc104.c -o test

7.9.2.2 PC104 Peripherals

The TS-7250-V3 is compatible with most of our PC104 devices. We do not test third party PC104 devices.

WARNING: Do not use third party PC104 power supplies. The -12 and -5V rails are incompatible with our PC104 implementation.

This list is of our current PC104 peripherals. While none are electrically incompatible, some may require additional driver work in order to function on this platform.

Product Compatibility Notes
TS-ADC16 yes
TS-ADC24 No
TS-DIO24 yes Current example code does not support IRQs.
TS-DIO64 yes Current example code does not support IRQs.
TS-ISO485 yes
TS-MULTI104 yes
TS-RELAY8 yes Relays will flicker on power on for several ms.
TS-SER1 yes
TS-SER2 yes
TS-SER4 yes
TS-9700 yes
TS-9422 yes
TS-12W yes prevents board sleep modes
TS-13W yes prevents board sleep modes
7.9.2.2.1 TS-ADC16
TS-ADC16
TS-ADC16.gif
Product Page
alt 16-bit IO

The TS-ADC16 provides 16 channels of 16-bit analog to digital conversion at 4 channels of 12-bit digital to analog conversion, 4 digital inputs, 4 16-bit edge counters, and 1 digital output. On the TS-7250-V3 this will support a max sample rate of 16khz with 2 channels enabled.

Refer to the TS-ADC16 manual for register / hardware documentation.

This example assumes only JP3 is installed on the TS-ADC16

# Verify the TS-ADC16 is detected.  This should return 0x3E in the lower byte
pc104_peekpoke io alt16 0x100

The TS-ADC16 can FIFO up to 512 samples before it overruns and stops the state machine. For continuous samples the max speed is limited by how fast Linux is able to access this FIFO. If the CPU load is too great that this cannot empty the FIFO fast enough, the ADCDLY should be increased for consistent sampling.

To make Linux more deterministic the governor should be changed to performance:

echo "performance" > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor

The default "ondemand" scheduler is beneficial for power savings, but when the system detects a load and it changes clock speed this can stop Linux from scheduling other processes too long that the FIFO can overflow.

The below sample c code will pull data from the FIFO as fast as possible and output it to stdout in binary form.

#include <stdio.h>
#include <stdint.h>
#include <assert.h>
#include <unistd.h>
#include <time.h>
#include <math.h>

#include "pc104.h"

#define TSADC16_BASE 0x100
#define SAMPLE_SIZE 1024

/* 
 * The TS-7250-V3 
 * 1/32000000=31.35ns increments
 2000 * 31.35ns = 62.7us.  1/0.0000627 = 15949hz sample rate
 */
#define ADCDLY 2000

/* 
 * We always sample from the lowest channel to the max channel 
 * https://docs.embeddedarm.com/TS-ADC16#ADC_pins
 */
#define MAX_CHAN_PAIR 0

int main(int argc, char **argv)
{
	uint16_t reg;
	int i, fifocnt, ret;

	if(isatty(fileno(stdout))) {
		fprintf(stderr, "Pipe to a file for raw ADC data\n");
		return 1;
	}

	pc104_init();
	if((pc104_io_16_alt_read(TSADC16_BASE) & 0xff) != 0x3E) {
		fprintf(stderr, "TS-ADC16 not detected");
		return 1;
	}

	assert(MAX_CHAN_PAIR < 8);

	/* Set ADCDLY */
	pc104_io_16_alt_write(TSADC16_BASE + 0x4, ((uint32_t)ADCDLY) >> 16);
	pc104_io_16_alt_write(TSADC16_BASE + 0x6, ((uint32_t)ADCDLY) & 0xffff);

	/* Set ADCCFG
	 * Trigger with SYSCOM bit
	 * Single ended
	 * 0v to 5V */
	reg = 0x160 | (MAX_CHAN_PAIR << 1);
	pc104_io_16_alt_write(TSADC16_BASE + 0x2, reg);
	pc104_io_16_alt_write(TSADC16_BASE + 0x2, reg | 0x1);
	do {
		reg = pc104_io_16_alt_read(TSADC16_BASE + 0x8);
		fifocnt = reg >> 6;
		if(!fifocnt) {
			reg = pc104_io_16_alt_read(TSADC16_BASE + 0x2);
			if(reg & 0x1)
				continue;
			fprintf(stderr, "Increase ADCDLY, can't keep up\n");
			return 1;
		}

		for (i = 0; i < fifocnt; i++) {
			uint16_t buffer = pc104_io_16_alt_read(TSADC16_BASE + 0xa);
			ret = write(1, &buffer, sizeof(uint16_t));
			assert(ret == sizeof(uint16_t));
		}
	} while(1);

	return 0;
}

This will continuously output raw binary data from the lowest to highest enabled ADC channel.


7.9.2.2.2 TS-BAT10
TS-BAT10
TS-BAT10.jpg
Product Page
8-bit IO

The TS-BAT10 is a 2000mAH 5V battery backup.

Refer to the TS-BAT10 manual for hardware documentation.

This example will charge the battery when it is low and has power, or shutdown when it does not have power and 3.3V is low.

#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <assert.h>
#include <unistd.h>

#include "pc104.h"

#define TSBAT10_BASE 0x110
 
typedef enum
{
	SW1_OPEN = 1 << 7,
	OVER33V = 1 << 6,
	VIN_OK = 1 << 5,
	BATTERY_EN = 1 << 4,
	BAT1CHARGING = 1 << 3,
	BAT1CHARGED = 1 << 2,
	BAT2CHARGING = 1 << 1,
	BAT2CHARGED = 1 << 0
} StatusFlags;
 
typedef enum
{
	RESERVED = 1 << 7,
	BAT2SLOWCHARGE = 1 << 6,
	BAT1SLOWCHARGE = 1 << 5,
	BAT2CHARGEEN = 1 << 4,
	BAT1CHARGEEN = 1 << 3,
	BAT2TIMERDISABLE = 1 << 2,
	BAT1TIMERDISABLE = 1 << 1,
	SOFTDISABLE = 1 << 0
} ConfigurationFlags;

int main(int argc, char **argv)
{
	uint8_t conf;
	pc104_init();

	if(argc > 1) { /* Poweroff only */
		pc104_io_8_write(TSBAT10_BASE, SOFTDISABLE);
		return 0;
	}

	conf = BAT1CHARGEEN | BAT2CHARGEEN;
	while(1) {
		uint8_t status;
		status = pc104_io_8_read(TSBAT10_BASE);

		if(status & BATTERY_EN) {
			printf("Battery disabled by JP4\n");
			goto SLEEP;
		}

		if(!(status & VIN_OK)) {
			/* If we dont have 5v, and 3.3V is low, shut down*/
			if(!(status & OVER33V)) {
				printf("TS-BAT10 is low & has no VIN.  Shutting down!\n");
				system("shutdown -h now");
			} else { 
				printf("VIN not ok, but 3.3V not low yet\n");
			}
		} else {
			if(!(status & OVER33V)) {
				/* If battery is not > 3.3V, charge */
				printf("Battery is low, VIN present.  Charging.\n");
				pc104_io_8_write(TSBAT10_BASE, conf);
			} else {
				printf("VIN OK, but battery is charged\n");
			}
		}
SLEEP:		
		sleep(5);
	}

	return 0;
}

Compile and install this with:

gcc tsbat10.c pc104.c -o tsbat10
cp tsbat10 /usr/local/bin/

Under systemd create a service file at /etc/systemd/system/tsbat10.service

[Unit]
Description=TS-BAT10 daemon

[Service]
Type=simple
ExecStart=/usr/local/bin/tsbat10

[Install]
WantedBy=multi-user.target

Enable and start this service with:

systemctl enable --now tsbat10.service
7.9.2.2.3 TS-DIO24
TS-DIO24
TS-DIO24.jpg
Product Page
8-bit IO

The TS-DIO24 provides 24 0-5V digital I/O. The I/O connector is an Opto-22 compatible interface that provides 16 I/O points configurable as input or output (24 mA as outputs) as well as 4 dedicated outputs capable of driving 48 mA and 4 dedicated outputs capable of sinking 1 Amp

Refer to the TS-DIO24 manual for register / hardware documentation:

The TS-DIO24 currently does not have a kernel driver which would be needed to use the interrupts. The Digital inputs/outputs however can be used from userspace without a driver.

This example assumes no jumpers are installed on the TS-DIO24.

# Verify the TS-DIO24 is detected.  This should return 0x54
pc104_peekpoke io 8 0x100

# Set A0 to 5V and turn off the rest of A
pc104_peekpoke io 8 0x105 0x1

# Set PORT B to to high outputs, and set PORT C to an input
pc104_peekpoke io 8 0x106 0xff # PORT B Data
pc104_peekpoke io 8 0x104 0x2 # B output, C input

# Read PORT C
pc104_peekpoke io 8 0x107
7.9.2.2.4 TS-DIO64
TS-DIO64
TS-DIO64.jpg
Product Page
8-bit IO

The TS-DIO64 provides 64 digital I/O points (32 inputs plus 32 open drain outputs) through two 34-pin locking connectors that are compatible with ribbon cables. The outputs are capable of sinking 200mA for pins 1-22, or 23-32 can sink up to 400mA. These sinking outputs support up to 40V.

Refer to the TS-DIO64 manual for register / hardware documentation:

The Digital inputs/outputs can be used from userspace without a driver.

This example assumes no jumpers are installed on the TS-DIO64.

# Verify the board is present.  Should return 0xA4
pc104_peekpoke io 8 0x100

# Enable the sink on pin 1, and all other outputs off
pc104_peekpoke io 8 0x104 0x1 # Pins 1-7
pc104_peekpoke io 8 0x105 0x0 # Pins 9-16
pc104_peekpoke io 8 0x106 0x0 # Pins 17-24
pc104_peekpoke io 8 0x107 0x0 # Pins 25-32

# Read IO
pc104_peekpoke io 8 0x108 # Pins 1-7
pc104_peekpoke io 8 0x109 # Pins 9-16
pc104_peekpoke io 8 0x10a # Pins 17-24
pc104_peekpoke io 8 0x10b # Pins 25-32
7.9.2.2.5 TS-ISO485
TS-ISO485
TS-ISO485.jpg
Product Page
8-bit IO

The TS-ISO485 provides two isolated half duplex RS-485 ports, or two isolated RS-422 ports.

Refer to the TS-ISO485 manual for more information about the hardware UART usage.

The TS-ISO485 implements 16550A based UARTs which require a kernel driver. Under Linux this requires a device tree change. See the Kernel compile section for more details about getting set up the compile the kernel.

This below example will set up the serial devices for a TS-ISO485 with the IRQ2,IRQ4, and SHARE jumpers installed. Open the device tree at arch/arm/boot/dts/imx6ul-ts7250v3.dts. Add the highlighted section to the device tree and recompile.

 1 pc104bus: fpgaisa@50 {
 2 	compatible = "technologic,pc104-bus";
 3 	reg = <0x50 0x4>;
 4 
 5 	ranges = <0 0 0x1000>;
 6 	reset-gpio = <&gpio3 7 0>;
 7 
 8 	#address-cells = <0x1>;
 9 	#size-cells = <0x1>;
10 
11 	status = "okay";
12 
13 	/* TS-ISO485 COMA */
14 	ts16550@3e8 {
15 		compatible = "technologic,ts16550";
16 
17 		reg = <0x3e8 8>;
18 		interrupt-parent = <&fpga_intc>;
19 		interrupts = <15>;
20 
21 		status = "okay";
22 	};
23 
24 	/* TS-ISO485 COMB */
25 	ts16550@2e8 {
26 		compatible = "technologic,ts16550";
27 
28 		reg = <0x2e8 8>;
29 		interrupt-parent = <&fpga_intc>;
30 		interrupts = <15>;
31 
32 		status = "okay";
33 	};
34 };

On the next boot check the "dmesg" output to verify it loaded:

root@tsimx6:~# dmesg | grep ts16550
[    2.259413] ts16550 50004050.fpgaisa:ts16550@3e8: Adding 16550 UART ttyS0
[    2.268166] ts16550 50004050.fpgaisa:ts16550@2e8: Adding 16550 UART ttyS1

Now that these are loaded:

Device Description
/dev/ttyS0 COMA
/dev/ttyS1 COMB

In this mode COMA/COMB are full duplex RS-485 (RS-422). See the TS-ISO485 manual for mroe details on the HD jumpers to use half duplex.

7.9.2.2.6 TS-MULTI104
TS-MULTI-104
TS-MULTI-104.jpg
Product Page
8-bit IO

The TS-MULTI-104 supports serial based Multitech Socketmodems for cellular support.

The TS-MULTI-104 implements 16550A based UART which require a kernel driver. Under Linux this requires a device tree change. See the Kernel compile section for more details about getting set up the compile the kernel.

This below example will set up the serial devices for a TS-MULT-104 with the IRQ6, COM1, and 1.8MHz jumpers installed. Open the device tree at arch/arm/boot/dts/imx6ul-ts7250v3.dts. Add the highlighted section to the device tree and recompile.

 1 pc104bus: fpgaisa@50 {
 2 	compatible = "technologic,pc104-bus";
 3 	reg = <0x50 0x4>;
 4 
 5 	ranges = <0 0 0x1000>;
 6 	reset-gpio = <&gpio3 7 0>;
 7 
 8 	#address-cells = <0x1>;
 9 	#size-cells = <0x1>;
10 
11 	status = "okay";
12 
13 	/* TS-MULTI-104 */
14 	ts16550@3f8 {
15 		compatible = "technologic,ts16550";
16 
17 		reg = <0x3f8 8>;
18 		interrupt-parent = <&fpga_intc>;
19 		interrupts = <15>;
20 
21 		status = "okay";
22 	};
23 };

On the next boot check the "dmesg" output to verify it loaded:

root@tsimx6:~# dmesg | grep ts16550
[    2.259413] ts16550 50004050.fpgaisa:ts16550@3f8: Adding 16550 UART ttyS0

The device node /dev/ttyS0 can be used to access this UART. As a simple test: picocom -b 115200 /dev/ttyS0

Type in "ATI" and press enter. This should return the cell radio name, and "OK".

For cell modems requiring the 921600 baud rate, remove the 1.8MHz jumper and in the device tree add uartclk = <14745600>; after specifying the interrupts. This will allow Linux to request the baud rate 921600.

The TS-MULTI-104 manual has a second on setting up pppd with tmobile, but refer to your specific modem's documentation for more information on setting up a connection specific to your modem/carrier.

The power to this modem is also under user control. By default, the modem will be powered.

# Turn off Cell modem power
pc104_peekpoke io 8 0x140 0x1

# Turn modem back on:
pc104_peekpoke io 8 0x140 0x0
7.9.2.2.7 TS-RELAY8
TS-Relay8
Ts-relay8.jpg
Product Page
8-bit IO

The TS-RELAY8 includes 8 SPDT relays. These are capable of switching up to 5A at 30VDC or 30VAC.

See sections of the TS-RELAY8 guide for register / jumper documentation:

WARNING: The TS-RELAY8 will energize relays immediately on poweron due to a hardware bug with this specific combination of hardware. Make sure your usage can tolerate this small flicker on poweron of several ms.

This example assumes no jumpers are installed on the TS-RELAY8.

# Verify the TS-RELAY8 is detected.  This should return 0x9b
pc104_peekpoke io 8 0x140

# Turn on just RLY1
pc104_peekpoke io 8 0x142 0x1

#Turn on RLY1 and RLY4
pc104_peekpoke io 8 0x142 0x9

# Turn on all relays.
pc104_peekpoke io 8 0x142 0xFF

# Turn off all relays (default state)
pc104_peekpoke io 8 0x142 0x0
7.9.2.2.8 TS-SER1
TS-SER1
Ts-ser1.jpg
Product Page
8-bit IO

The TS-SER1 provides a single RS-232 port.

The TS-SER1 implements 16550A based UART which require a kernel driver. Under Linux this requires a device tree change. See the Kernel compile section for more details about getting set up the compile the kernel.

This below example will set up the serial devices for a TS-SER1 with the IRQ6 and COM3 jumpers installed. Open the device tree at arch/arm/boot/dts/imx6ul-ts7250v3.dts. Add the highlighted section to the device tree and recompile.

 1 pc104bus: fpgaisa@50 {
 2 	compatible = "technologic,pc104-bus";
 3 	reg = <0x50 0x4>;
 4 
 5 	ranges = <0 0 0x1000>;
 6 	reset-gpio = <&gpio3 7 0>;
 7 
 8 	#address-cells = <0x1>;
 9 	#size-cells = <0x1>;
10 
11 	status = "okay";
12 
13 	/* TS-SER1 */
14 	ts16550@3e8 {
15 		compatible = "technologic,ts16550";
16 
17 		reg = <0x3e8 8>;
18 		interrupt-parent = <&fpga_intc>;
19 		interrupts = <15>;
20 
21 		status = "okay";
22 	};
23 };

On the next boot check the "dmesg" output to verify it loaded:

root@tsimx6:~# dmesg | grep ts16550
[    2.259413] ts16550 50004050.fpgaisa:ts16550@3e8: Adding 16550 UART ttyS0

The device node /dev/ttyS0 can be used to access this UART.

7.9.2.2.9 TS-SER2
TS-SER2
Ts-ser2.jpg
Product Page
8-bit IO

The TS-SER2 provides two RS-232, RS-485 half duplex or full duplex (RS-422) ports and a parallel port.

Refer to the TS-SER2 manual for hardware documentation.

The parallel port is currently not supported on this platform.

The TS-ISO485 implements 16550A based UARTs which requires a kernel driver. Under Linux this requires a device tree change. See the Kernel compile section for more details about getting set up the compile the kernel.

This below example will set up the serial devices for a TS-ISO485 with JP 14 through JP18, COMB 6, and COMA 5 jumpers installed. Open the device tree at arch/arm/boot/dts/imx6ul-ts7250v3.dts. Add the highlighted section to the device tree and recompile.

 1 pc104bus: fpgaisa@50 {
 2 	compatible = "technologic,pc104-bus";
 3 	reg = <0x50 0x4>;
 4 
 5 	ranges = <0 0 0x1000>;
 6 	reset-gpio = <&gpio3 7 0>;
 7 
 8 	#address-cells = <0x1>;
 9 	#size-cells = <0x1>;
10 
11 	status = "okay";
12 
13 	/* TS-SER2 COMA */
14 	ts16550@2e8 {
15 		compatible = "technologic,ts16550";
16 
17 		reg = <0x2e8 8>;
18 		interrupt-parent = <&fpga_intc>;
19 		interrupts = <14>;
20 
21 		status = "okay";
22 	};
23 
24 	/* TS-SER2 COMB */
25 	ts16550@3e8 {
26 		compatible = "technologic,ts16550";
27 
28 		reg = <0x3e8 8>;
29 		interrupt-parent = <&fpga_intc>;
30 		interrupts = <15>;
31 
32 		status = "okay";
33 	};
34 };

On the next boot check the "dmesg" output to verify it loaded:

root@tsimx6:~# dmesg | grep ts16550
[    2.259413] ts16550 50004050.fpgaisa:ts16550@2e8: Adding 16550 UART ttyS0
[    2.268166] ts16550 50004050.fpgaisa:ts16550@3e8: Adding 16550 UART ttyS1

Now that these are loaded:

Device Description
/dev/ttyS0 COMA
/dev/ttyS1 COMB

In this mode COMA/COMB are full duplex RS-485 (RS-422). See the TS-ISO485 manual for mroe details on the HD jumpers to use half duplex.

7.9.2.2.10 TS-SER4
TS-SER4
Ts-ser4.jpg
Product Page
8-bit IO

The TS-SER4 supports 4 UARTs as RS-232, RS-485, or RS-422. Refer to the TS-SER4 manual for hardware documentation.

The TS-SER4 implements 16550A based UARTs which require a kernel driver. Under Linux this requires a device tree change. See the Kernel compile section for more details about getting set up the compile the kernel.

This below example will set up the serial devices for a TS-SER4 with the IRQ2,IRQ6, and COM1 jumpers installed. Open the device tree at arch/arm/boot/dts/imx6ul-ts7250v3.dts. Add the highlighted section to the device tree and recompile.

 1 pc104bus: fpgaisa@50 {
 2 	compatible = "technologic,pc104-bus";
 3 	reg = <0x50 0x4>;
 4 
 5 	ranges = <0 0 0x1000>;
 6 	reset-gpio = <&gpio3 7 0>;
 7 
 8 	#address-cells = <0x1>;
 9 	#size-cells = <0x1>;
10 
11 	status = "okay";
12 
13 	/* COMA */
14 	ts16550@3f8 {
15 		compatible = "technologic,ts16550";
16 
17 		reg = <0x3f8 8>;
18 		interrupt-parent = <&fpga_intc>;
19 		interrupts = <15>;
20 
21 		status = "okay";
22 	};
23 
24 	/* COMB */
25 	ts16550@2f8 {
26 		compatible = "technologic,ts16550";
27 
28 		reg = <0x2f8 8>;
29 		interrupt-parent = <&fpga_intc>;
30 		interrupts = <15>;
31 
32 		status = "okay";
33 	};
34 
35 	/* COMC */
36 	ts16550@3e8 {
37 		compatible = "technologic,ts16550";
38 
39 		reg = <0x3e8 8>;
40 		interrupt-parent = <&fpga_intc>;
41 		interrupts = <15>;
42 
43 		status = "okay";
44 	};
45 
46 	/* COMD */
47 	ts16550@2e8 {
48 		compatible = "technologic,ts16550";
49 
50 		reg = <0x2e8 8>;
51 		interrupt-parent = <&fpga_intc>;
52 		interrupts = <15>;
53 
54 		status = "okay";
55 	};
56 };

On the next boot check the "dmesg" output to verify it loaded:

root@tsimx6:~# dmesg | grep ts16550
[    2.259413] ts16550 50004050.fpgaisa:ts16550@3f8: Adding 16550 UART ttyS0
[    2.268166] ts16550 50004050.fpgaisa:ts16550@2f8: Adding 16550 UART ttyS1
[    2.278539] ts16550 50004050.fpgaisa:ts16550@3e8: Adding 16550 UART ttyS2
[    2.287455] ts16550 50004050.fpgaisa:ts16550@2e8: Adding 16550 UART ttyS3

Now that these are loaded:

Device Description
/dev/ttyS0 COMA
/dev/ttyS1 COMB
/dev/ttyS3 COMC
/dev/ttyS4 COMD
7.9.2.2.11 TS-12W
TS-12W
TS-12W.jpg
Released Mar. 2004
Product Page

The TS-12W provides 2.4A on PC104 5V supporting a VIN of 10-30VDC. The TS-7250-V3 has a built in regulator supporting 8-28VDC which is recommended instead, but for legacy products with existing mechanical requirements this board will continue to work. Powering the system from PC104 does prevent the Board's low power sleep mode from functioning.

Refer to the TS-12W manual for more information on hardware features.

7.9.2.2.12 TS-13W
TS-13W
TS-13W.jpg
Released June 2009
Product Page

The TS-13W provides 2.6A on PC104 5V supporting a VIN of 8-30VDC. The TS-7250-V3 has a built in regulator supporting 8-28VDC which is recommended instead, but for legacy products with existing mechanical requirements this board will continue to work. Powering the system from PC104 does prevent the Board's low power sleep mode from functioning.

Refer to the TS-13W manual for more information on hardware features.

7.9.2.2.13 TS-9422
TS-9422
TS-9422.jpg
Product Page
8-bit IO

The TS-9422 is a POST code output board designed for x86 systems. ARM does not use POST to indicate its boot status, but this board does work to display two hexadecimal values written to 0x80 on the ISA bus.

WARNING: Make sure the board mounting holes line up on PC104. Unlike most PC104 boards this faces away from the main CPU in order to remain visible while in a stack.
# Shows 55 on the PC104 bus
pc104_peekpoke io 8 0x80 0x55
7.9.2.2.14 TS-9700
TS-9700
TS-9700.jpg
Product Page
8-bit IO

The TS-9700 provides 8 channels of 12-bit ADC which support 0-2.5V, 0-10V, or 0-20mA. Optionally this board can include 4x 0-5V DAC channels.

Refer to the TS-9700 manual for register / hardware documentation.

This example assumes addr 0x160 selected by having JP1/2/3 removed.

The TS-9700 identifies as 0x97:

pc104_peekpoke io 8 0x161

The TS-9700 is accessed in userspace with this sample C code.

#include <stdio.h>
#include <stdint.h>
#include <assert.h>
#include <unistd.h>

#include "pc104.h"
#define TS9700_BASE 0x160

void ts9700_set_dac(uint8_t channel, uint16_t val)
{
	assert(channel <= 3);
	assert(val <= 0xFFF);
	pc104_io_8_write(TS9700_BASE + 0x4, val & 0xff);
	pc104_io_8_write(TS9700_BASE + 0x5, (channel << 6) | (val >> 8));

	while((~pc104_io_8_read(TS9700_BASE + 0x6)) & (1 << 7)){
		usleep(10); /* Wait until the DAC is ready */
	}
}

uint16_t ts9700_single_sample(uint8_t channel)
{
	uint16_t sample;

	assert (channel < 8);
	pc104_io_8_write(TS9700_BASE, channel | (1 << 4));
	while((~pc104_io_8_read(TS9700_BASE)) & (1 << 7)){
		usleep(9); /* Wait until the sample is ready */
	}
	sample = pc104_io_8_read(TS9700_BASE + 0x2);
	sample |= ((uint16_t)pc104_io_8_read(TS9700_BASE + 0x3) << 8);
	return sample;
}

int main(int argc, char **argv)
{
	int i;

	pc104_init();

	/* Verify the TS-9700 is detected */
	if(pc104_io_8_read(TS9700_BASE + 0x1) != 0x97) {
		fprintf(stderr, "TS-9700 not detected");
		return 1;
	}

	for (i = 0; i < 8; i++)
		printf("chan%d=0x%X\n", i, ts9700_single_sample(i));

	ts9700_set_dac(0, 0); // Set channel 0 to 0V
	ts9700_set_dac(1, 4095); // Set to 5V (max)
	ts9700_set_dac(2, 2048); // Set to 2.5V
	ts9700_set_dac(3, 819); // Set to ~1V

	return 0;
}

Compile this on the unit with:

gcc ts9700.c tspc104.c -o ts9700

7.10 FRAM

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

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

7.11 I2C

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


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


7.12 Interrupts

Note: This section is incomplete at this time.


7.13 LEDs

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

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


The following LEDs are available on this system:

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

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

7.14 Relays

Note: This section is incomplete at this time.


7.15 Sleep

TS-7250-V3 Sleep mode

7.16 SPI

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


7.17 TS-SILO Supercapacitors

7.18 UARTs

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

UART Dev. Type TX / + Loc. RX / - Loc. CTS RTS DCD DTR
ttymxc0 USB Console P2 MicroUSB P2 MicroUSB N/A N/A N/A N/A
ttymxc2 Bluetooth Onboard Onboard 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
ttymxc6 3.3V TTL MikroBus pin 13 MikroBus pin 14 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
ttyS9 RS-232 COM2 pin 3 COM2 pin 2 COM2 pin 8 COM2 pin 7 N/A N/A
ttyS10 RS-232 COM3 pin 3 COM3 pin 2 COM3 pin 8 COM3 pin 7 N/A N/A
ttyS11 RS-485 COM2 pin 1 COM2 pin 6 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

7.18.1 RS-485

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

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

7.19 USB

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

7.20 Watchdog

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

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

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

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

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

See the Linux WDT API documentation for more information.


7.21 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

8 Specifications

8.1 Power Input Specifications

TS-7250-V3 Power Supply Specifications

8.2 Power Consumption

TS-7250-V3 Power Consumption

8.3 Board Rails

TS-7250-V3 Board Rails

9 External Interfaces

9.1 ADC Header

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

For example:

# Disable current loops:
Signals Pin Layout
Pin Signal
1 GPIO1_IO00/ADC?
2 GND
3 GPIO1_IO01/ADC?
4 GND
5 GPIO1_IO05/ADC?
6 GND
7 GPIO1_IO08/ADC?
8 GND
9 GPIO1_IO09/ADC?
10 GND

TS-7250-V3-ADC.svg

9.2 Battery Connector

The #RTC uses removable lithium cr1632 batteries.

TS-7250-V3-Battery.jpeg

9.3 COM2 Header

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

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

TS-7250-V3-COM2.svg

9.4 COM3 Header

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

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

TS-7250-V3-COM3.svg

9.5 DB9 Connector

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

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

DB9.svg

9.6 DIO Header

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

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

TS-7250-V3-DIO Header.svg

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

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

9.7 Ethernet connectors

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

TS-7250-V3 Eth.svg

9.8 LCD Header

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

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

TS-7250-V3-LCD Header.svg

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

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

For example, this would write to the display:

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

For example, running:

lcdmesg Technologic Systems

will display:

LCD LED example.jpg

9.9 MikroBus Header

The Mikrobus header is a 0.1" pitch 2x8 header which supports the Mikroe Click board ecosystem. This header features 3.3V, 5V, SPI, GPIO, ADC, PWM, a UART, and PWM. All IO are 3.3V tolerant.

Signals Pin Layout
Pin Signal
1 #Silabs ADC
2 MIKRO_RESET# GPIO Bank 7 IO 0
3 spidev 0.1 CS#
4 spidev 0.1 CLK
5 spidev 0.1 MISO
6 spidev 0.1 MOSI
7 3.3V
8 GND
9 GND
10 5V
11 /dev/i2c-2 DAT
12 /dev/i2c-2 CLK
13 ttymxc6 TXD
14 ttymxc6 RXD
15 MIKRO_INT
16 MIKRO_PWM

TS-7250-V3-Mikrobus Header.svg


9.10 MicroSD Connector

TS-7250-V3 MicroSD Connector

9.11 MicroUSB Connector

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

TS-7250-V3 USB Console.jpg

9.12 PC104 Header

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

TS-7250-V3 PC104 pinout.svg

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

9.13 Power Connectors

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

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

TS-7250-V3 removable power connector.jpg

9.14 USB Ports

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

# Route USB to XBEE
gpioset 2 28=1

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

9.15 XBEE Header

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

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

# Turn on the USB
gpioset 2 28=1

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

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

# For 3.3V modules:
gpioset 6 4=1

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

For serial modules refer to these related links:

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

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

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

./xbeetest /dev/ttymxc3

This will print out the module information such as:

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

TS-7250-V3-XBEE Header.svg


10 Revisions and Changes

Note: This section is incomplete at this time.

10.1 FPGA Changelog

10.2 Microcontroller Changelog

10.3 PCB Revisions

10.4 Software Images

10.4.1 Debian Changelog

10.5 U-Boot

11 Product Notes

11.1 FCC Advisory

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

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

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

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

11.2 Limited Warranty

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

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

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

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

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


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