The i.MX286 based TS-7400-V2 is designed as a direct upgrade path from the EP9302 based TS-7400. While these SBCs have the same form factor and a very identical pinout, there are a few software concerns that need to be addressed. Since the TS-7400-V2 utilizes a different CPU than the TS-7400, accessing any of the DIO or peripherals directly though memory mapped addresses will require code differences between the two SBCs. Pinouts are matched as best as possible between the two SBCs, however some pins may not apply from one to the other. This makes for a minor amount of hardware differences which may affect your upgrade. This guide is intended to provide details in differences between the TS-7400 and TS-7400-V2, for both hardware and software. This guide will also link to relevant sections of the TS-7400-V2 manual for more in-depth information on software and hardware ports.
2 Pin-by-pin Comparison
2.1 Upper header pin-out (26-pin)
|1||TDO||TS Production Reserved||I2C_DAT||CPU DIO3_25 or I2C Data|
|2||TMS||TS Production Reserved||M0_SW_CLK||Reserved|
|4||TDI||TS Production Reserved||M0_SW_DIO||Reserved|
|5||BLAST_BOOT#||Blast boot (9441 boot)||CPU DIO1_7||CPU DIO1_7|
|6||TCK||TS Production Reserved||I2C_CLK||CPU DIO3_24 or I2C Clock|
|7||UART0_TXD||UART0 TXD||DEBUG_TXD||Debug UART TXD|
|8||UART0_RXD||UART0 RXD||DEBUG_RXD||Debug UART RX|
|9||SPI_MISO||SPI MISO||SPI_MISO ||CPU DIO2_04 or SPI MISO|
|10||3.3V||3.3V Output||3.3V||3.3V Output|
|11||BLAST_EE_CS#||Chip select 9441 flash||CPU DIO1_8||CPU DIO1_8|
|12||SPI_MOSI||SPI MOSI||SPI_MOSI ||CPU DIO2_06 or SPI MOSI|
|13||FLASH_CS#||Chip select 9441 EEPROM||CPU DIO1_9||CPU DIO1_9|
|14||SPI_CLK||SPI clock output||SPI_CLK ||CPU DIO2_7 or SPI clock|
|15||5V||5V regulated power input||5V||5V regulated power input|
|16||EXT_RESET#||External reset input||HARD_REBOOT#||External reset input|
|17||BLAST_PRESENT#||Boot hijacker present input||CPU DIO1_10||CPU DIO1_10|
|19||PORTB_4||CPU DIO||DIO_19||CPU DIO1_24|
|21||EN_5V||Switching power supply en||CPU DIO1_11||CPU DIO1_11|
|22||EP_USB+||EP93xx USB data||USB_OTG_P||i.MX286 USB OTG data|
|23||FIL_VIN||Reserved||CPU DIO1_12||CPU DIO3_25|
|24||EP_USB-||EP93xx USB data||USB_OTG_M||i.MX286 USB OTG data|
|25||PORTB_7||CPU DIO||DIO_25||CPU DIO1_25(1.6 V)|
|26||USB_5V||USB 5V power||USB_SW_5V||Switched USB 5V power|
2.2 Lower header pin-put (40-pin)
|1||DIO_00||GPIO0 or GPBUS AD0||DIO_00||CPU DIO1_16|
|2||3.3V||3.3V Output||3.3V||3.3V Output|
|3||DIO_01||GPIO1 or GPBUS AD1||DIO_01||CPU DIO1_17|
|4||DIO_02||GPIO2 or GPBUS AD2||DIO_02||CPU DIO1_18|
|5||DIO_03||GPIO3 or GPBUS AD3||DIO_03||CPU DIO1_19|
|6||DIO_04||GPIO4 or GPBUS AD4||DIO_04||CPU DIO1_20|
|7||DIO_05||GPIO5 or GPBUS AD5||DIO_05||CPU DIO1_21|
|8||DIO_06||GPIO6 or GPBUS AD6||DIO_06||CPU DIO1_22|
|9||DIO_07||GPIO7 or GPBUS AD7||DIO_07||CPU DIO1_23|
|10||DIO_08||GPIO8 or GPBUS ALE||DIO_08||CPU DIO1_15|
|11||DIO_09||GPIO9 or GPBUS RD||DIO_09||CPU DIO1_14|
|13||DIO_10||GPIO10 or GPBUS WR||CAN_RX0||CPU DIO3_13 or CAN RX0|
|14||DIO_11||GPIO11 or GPBUS IRQ||CAN_RX1||CPU DIO3_15 or CAN RX1|
|15||DIO_15||GPIO12 or GPBUS DRQ||CAN_TX0||CPU DIO3_12 or CAN TX0|
|16||DIO_13||GPIO13 or GPBUS 14.7456Mhz||CAN_TX1||CPU DIO3_14 or CAN TX1|
|17||DIO_14||GPIO14||UART3_TXD||CPU DIO2_19 or UART3|
|18||5V||5V regulated power input/output||5V||5V regulated power input|
|19||DIO_15||GPIO15 or UART2 TXEN||DIO_15||CPU DIO3_29 or PWM4|
|20||DIO_16||GPIO16 or UART2 RXD||UART2_RXD||CPU DIO2_16 or UART2|
|21||DIO_17||GPIO17 or UART2 TXD||UART2_TXD||CPU DIO2_17 or UART2|
|22||DIO_18||GPIO18 or UART0 TXD||UART0_TXD||CPU DIO3_01 or UART0|
|23||DIO_19||GPIO19 or UART0 RXD||UART0_RXD||CPU DIO3_00 or UART0|
|24||UART1_RXD||UART1 RXD||UART1_RXD||CPU DIO3_04 or UART1|
|25||UART1_TXD||UART1 TXD||UART1_TXD||CPU DIO3_05 or UART1|
|26||1.8V||1.8V||UART3_RXD||CPU DIO2_18 or UART3|
|27||ADC0||EP93xx ADC0||ADC0||i.MX286 ADC0|
|28||ADC1||EP93xx ADC1||ADC1||i.MX286 ADC1|
|29||ADC2||EP93xx ADC2||ADC2||i.MX286 ADC2|
|30||ADC3||EP93xx ADC3||ADC3||i.MX283 ADC3|
|32||ABIT_CLK||EP93xx CPU AC97||I2S_BIT_CLK||CPU DIO3_22 or I2S Clock|
|33||ASDO||EP93xx CPU AC97||I2S_TXD||CPU DIO3_23 or I2S TXD|
|34||ASYNCH||EP93xx CPU AC97||I2S_FRAME||CPU DIO3_21 or I2S Frame|
|35||ARST#||EP93xx CPU AC97||I2S_MCLK||CPU DIO3_20 or I2S MCLK|
|36||ASDI||EP93xx CPU AC97||I2S_RXD||CPU DIO3_26 or I2S RXD|
|37||SSP_TX||EP93xx SPI/SSP/I2S signal||SPI_MOSI ||CPU DIO2_06 or SPI MOSI|
|38||SSP_RX||EP93xx SPI/SSP/I2S signal||SPI_MISO ||CPU DIO2_04 or SPI MISO|
|39||SSP_FRM||EP93xx SPI/SSP/I2S signal||SPI_CS# ||CPU DIO2_05 or SPI Chip select|
|40||SSP_CLK||EP93xx SPI/SSP/I2S signal||SPI_CLK ||CPU DIO2_07 or SPI Clock|
- These two SPI ports are electrically connected and are the same interface
3 Peripheral Functions
The TS-7400-V2 does not offer an AC'97 audio port. Audio functionality can still be achieved by using I2S audio.
The TS-7400-V2 has 4 ADCs exposed from the CPU. Three of them are LRADC (ADC0-ADC2), low-resolution ADC, and ADC3 is a HSADC, high-speed ADC. Both ADCs can sample at 12bit resolution, the HSADC can sample at maximum 2Msps while the LRADC has a maximum sample rate of 460ksps. The LRADC has an input range of 0-1.85 or 0-3.3v based on register configuration. The HSADC core can sample all of the ADC pins, while ADC3 is dedicated to only HSADC. The LRADC core can sample ADC0-ADC2. The LRADC supports 16 physical channels that can be mapped to 8 virtual channels at one time. ADC0-2 are channels 0-2 of the physical channels. Other channels include measuring internal and external temperature, measuring the 1.8v and 1.2v rails, 5v input, and a channel to measure the bandgap reference voltage which can be used to calibrate out a portion of the LRADC measurement error. All 8 virtual channels of the LRADC are saved on the same clock edge, and then are converted one by one until conversion is complete. The HSADC core can only sample one of the pins at a time.
These two CPU peripherals are located at two separate addresses, HSADC at 0x80002000, LRADC at 0x80050000, it is possible to use just the HSADC peripheral to measure all of the ADC pins. However, if the application needs to measure multiple pins on the same clock edge, or get information on voltage rails, and use all 4 ADC pins, both peripherals will need to be used.
Code changes can range from fairly small to large. The simplest solution is to use the LRADC is the same mode as the TS-7400 ADCs, one single conversion at a time converted on demand. This would only require mmap()ing the new address, Setting up CTRL0, CTRL1, CTRL2, CTRL3, and CTRL4 registers for fine-tuned sampling control, start conversion in CTRL0, poll for completion in CTRL1 interrupt, then read result out of desired channel register. Please note that each register actually has 4 addresses associated with it in order to provide atomic set/clear/toggle accesses, a read/write register (Same as standard registers in the TS-7400 EP9302), a set address, a clear address, and a toggle address. Any bits written as a 1 to the set/clear/toggle address will cause that bit to be set/cleared/toggled atomically in the register. This same procedure can be used to sample each pin one at a time, or sample multiple pins on the same clock edge and then convert them, polling until all of the requested channels have been converted.
See the TS-7400-V2 manual and the i.MX28 manual for more information.
The CAN ports of the TS-7400-V2 start up in peripheral mode, however the kernel driver is modularized and not loaded by default. This means the pins are safe to use as DIO.
There are a few fundamental differences between DIO access on the TS-7400 and the TS-7400-V2. On the TS-7400-V2 nearly every pin has multiple functions associated with it, one of them being DIO, and one to three of them being other CPU peripherals. This mux must be set to DIO mode before a pin can be utilized as a DIO. The TS-7400 refers to different DIO clusters as "Ports" that are then subdivided in to pins, i.e. PORTA_1, PORTB_7, etc. The TS-7400-V2 has groupings of all pins held in "Banks" that are subdivided in to pins, i.e. DIO3_20, DIO2_16, etc. The bank and pin number are important to driving the correct DIO pin. All DIO and its associated registers are able to be accessed at base 0x80018000 with all resisters residing within a 4kbyte address space. IRQ settings start at 0x80019000 and are also within a 4kbyte address space, however these registers should not normally need to be modified; any changes to IRQs and their settings should be made in-kernel.
Code changes should not require great amounts of additional code to support the changed DIO. Differences should include mmap()ing the new base address, additional memory accesses to the MUXSEL register(s) to put the needed DIO in the correct mode, using a different address for DOE (Formerly the Data Direction Register in the TS-7400 EP9302), using a different address for DOUT (Formerly the Data Register in the TS-7400 EP9302), and adding calls to the DIN register (Reading DIO states was achieved by reading the Data Register in the TS-7400 EP9302). Please note that each register actually has 4 addresses associated with it in order to provide atomic set/clear/toggle accesses, a read/write register (Same as standard registers in the TS-7400 EP9302), a set address, a clear address, and a toggle address. Any bits written as a 1 to the set/clear/toggle address will cause that bit to be set/cleared/toggled atomically in the register.
On the TS-7400-V2 most pins start up in DIO while others are in peripheral. Those that start up in a peripheral mode will likely have a kernel driver associated with them. Changing the MUXSEL bits of any pin that is a peripheral may result in system instability, loss of peripheral functionality, or the associated MUXSEL register being set back in to peripheral mode by the driver with no warning. Please verify that any pin(s) to be used do not have a loaded and running kernel module to support a peripheral used on the aforementioned pin(s).
Each pin is also interrupt capable. Combined with our userspace IRQs, it allows interrupt driven userspace applications to be written very easily.
At this time the GPBUS provided on the TS-7400 has not been ported over to the TS-7400-V2. This is a very simplistic bus that can easily be implemented in DIO. Contact Technologic Systems for more information on this
The TS-7400 did not have a real I2C port and any use of I2C needed to be bit-banged on DIO. The TS-7400-V2 does offer a real I2C peripheral however. Existing applications using I2C would likely experience a faster and simpler migration by simply updating the codebase to continue to use the DIO bit-banging method. It will result in few lines of code and continue using an already proven out codebase. Bear in mind that timings may need to be adjusted to account for the speed increase of the TS-7400-V2 CPU. See the DIO section for more information. Note that the RTC is attached to the I2C bus and is using two addresses, 0xAE and 0xDE; any other devices on the I2C pins should use different addresses.
The TS-7400-V2 uses I2S in order to output audio in lieu of AC'97. Other methods like USB can be used as well for audio output, however that is not covered by this guide. I2S on the TS-7400-V2 is placed over top of the lines that implemented AC'97 on the TS-7400, making the TS-7400-V2 incompatible with existing applications that utilized AC'97. On the TS-7400 I2S was electrically in parallel with the SPI pins as the same CPU peripheral in the EP9302 implemented both SPI and I2S. The TS-7400-V2 has these separated out, using SPI does not restrict the use of I2S.
Currently, I2S is unused by any drivers and full support for these pins have not been implemented. When the TS-7400-V2 boots up they are in peripheral mode, however since they are unused they are safe to be used as DIO.
See the TS-7400-V2 manual and the i.MX28 manual for more information.
The TS-7400-V2 provides the same barrel connector on the front of the SBC as the TS-7400. The TS-7400-V2 still requires 5 V input, however its ranges must be within 4.8-5.2 VDC. Going below this range may result in system instability, and going above this voltage may result in damage to the CPU. Just like the TS-7400 there is a Zener protection diode with a 5 V knee in order to protect from over-voltage damage.
When transferring in the TS-7400-V2 to any existing application, the power supply should be verified to be within the correct operating range. If the voltage falls below 4.8 V the CPU internal regulators will no longer be able to regulate properly and may cause system instability.
Additionally, the TS-7400-V2 can optionally support 8-28 VDC input as the TS-7400 does as well. Both the TS-7400 and TS-7400-V2 share the same input parameters for this port on the rear of the PCB.
The TS-7400 used a kernel driver to present the RTC interface through the `hwclock` command. The TS-7400-V2 instead uses a userspace application to get and set the time:
tshwctl --getrtc tshwctl --setrtc
This allows a kernel upgrade path in the future. By talking to the RTC from userspace it allows the kernel to change without much code to be adapted to the new kernel. This method also allows easy access to the 128 bytes of NVRAM that is contained inside the RTC from userspace applications.
See the tshwctl.c sources for code that demonstrates interacting will the RTC.
3.10 SD Card
The TS-7400-V2 is natively booted from SD card or NAND. Two SD card sockets are provided on the TS-7400-V2, a full size SD card socket in the same location as the TS-7400, as well as a microSD card socket on the top side of the PCB. These sockets are wired in parallel, which means that only one can be used at a time. If both SD card sockets are populated simultaneously they will conflict and the TS-7400-V2 will likely be unable to boot.
The TS-7400-V2 names the SD card /dev/mmcblk0, with individual partitions being labeled p1, p2, etc. The only conflict this could have with current applications are those that mount and unmount the SD card during their operation. If that is the case, the code must be updated to utilize the new device naming scheme.
The TS-7400-V2 has one SPI port exposed on the two pin headers with one chip select under the peripheral control. If more than one chip select is needed a standard DIO may be used under software control. Note that the MISO, MOSI, and CLK pins are each available on two sets of pins while the CS line is only brought out to one. The TS-7400 shared I2S and SPI on the same pins, on the TS-7400-V2 these two peripherals are separate. The TS-7400-V2 has a kernel module to enable the SPI port use through the standard linux SPI framework, as well as the spidev framework. It is also possible to use the SPI port by directly talking to the SPI peripheral registers in the CPU. The SPI peripheral used is SSP2 which has a base address of 0x80014000 in the i.MX286 CPU and is inside a 4kbyte address space.
Code changes for basic SPI functionality should not require great amounts of additional code to support the different register layout. The SSP peripheral in the CPU supports multiple protocols, including SD/MMC/SDIO, SPI master and slave, and SSI. This means that there are only a few of the registers needed to complete SPI bus cycles. Differences should include mmap()ing the new base address, setting up the CTRL0 and CTRL1 registers, and then writing data to and reading from the DATA register. Please note that each register actually has 4 addresses associated with it in order to provide atomic set/clear/toggle accesses, a read/write register (Same as standard registers in the TS-7400 EP9302), a set address, a clear address, and a toggle address. Any bits written as a 1 to the set/clear/toggle address will cause that bit to be set/cleared/toggled atomically in the register.
On the TS-7400-V2 the SPI pins start up in SPI mode on port SSP2, however the kernel drivers are modularized and not loaded by default. These pins are safe to use as DIO.
3.12 Temperature Sensor
The TS-7400 had an SPI temperature sensor that could be read very easily from userspace. The TS-7400-V2 actually has 3 temperature sensors, one connected to the CPU die, a diode sitting very close to the CPU used as a sensor, and a temperature sensor inside the RTC further from the CPU to measure ambient temperatures. All three of these sensors can be read from the command line with the following commands:
tshwctl --cputemp external_temp=26.313 internal_temp=44.849 tshwctl --rtcinfo rtc_present=1 rtctemp_millicelsius=29000 ...
There is other output from the --rtcinfo flag, see the TS-7400-V2 manual for more information.
The temperature of all three sensor outputs is in Celsius, external_temp is the diode sensor, internal_temp is the on-die temperature sensor in the i.MX286 CPU, and rtctemp_millicelsius is the temperature sensor located on the die of the RTC.
All of these can be accessed through code as well, see the tshwctl.c sources for examples on how this is done.
The TS-7400s only temperature sensor was connected to SPI, while the internal/external and RTC temp sensors on the TS-7400-V2 are accessed through the LRADC register, and over I2C respectively. While it may be wise for an application to know all three temperatures, only two or even just one could be required. However, since tshwctl already implements all of these, code could easily be pulled from there and adapted in to existing applications.
The TS-7400-V2 adds more UARTs than the original TS-7400 provides. In linux, the TTY layer takes care of all underlying peripheral and pin access for the various UARTs in the system. Currently all of the UART ports on the TS-7400-V2 start up in peripheral mode, however the kernel drivers are modularized and not loaded by default. These pins are safe to use as DIO. In order to change the number of UARTs used by the driver or to make any modifications to the pin muxes or startup states, the kernel will need to be modified. The TS-7400-V2 has a Debug UART that is always intended to be such, in addition to that there are 4 UARTs for a total of 5; the TS-7400 only has 3 UARTs total. Please note that the TS-7400 used UART0 in two places on the pin headers, the TS-7400-V2 replaces one of these with the Debug UART and UART0 is a separate device. All UARTs in the TS-7400-V2 are CPU UARTs. Also note that UART2 does not offer an automatic TXEN on the TS-7400-V2, there is a DIO pin there in its place that can be used as a TXEN.
Code changes should only require changing the device name of the UART(s) used. The setup steps for configuring the port itself will likely require no changes. See the comparison to identify which pins are being used by which UARTs.
See the TS-7400-V2 manual and the i.MX28 manual for more information.
|Port||TS-7400 name||TS-7400-V2 name|