From Technologic Systems Manuals
Jump to: navigation, search

Contents

1 Migration

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)

TS-7400 TS-7400-V2
Pin # Name Function Name Function
1 TDO TS Production Reserved I2C_DAT CPU DIO3_25 or I2C Data
2 TMS TS Production Reserved M0_SW_CLK Reserved
3 GND Ground GND Ground
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 [1] 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 [1] 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 [1] 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
18 GND Ground GND Ground
19 PORTB_4 CPU DIO DIO_19 CPU DIO1_24
20 GND Ground GND Ground
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)

TS-7400 TS-7400_V2
Pin # Name Function Name Function
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
12 GND Ground GND Ground
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
31 GND Ground GND Ground
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 [1] CPU DIO2_06 or SPI MOSI
38 SSP_RX EP93xx SPI/SSP/I2S signal SPI_MISO [1] CPU DIO2_04 or SPI MISO
39 SSP_FRM EP93xx SPI/SSP/I2S signal SPI_CS# [1] CPU DIO2_05 or SPI Chip select
40 SSP_CLK EP93xx SPI/SSP/I2S signal SPI_CLK [1] CPU DIO2_07 or SPI Clock
  1. 1.0 1.1 1.2 1.3 1.4 1.5 1.6 These two SPI ports are electrically connected and are the same interface

3 Peripheral Functions

3.1 AC'97

The TS-7400_V2 does not offer an AC'97 audio port. Audio functionality can still be achieved by using I2S audio.


3.2 ADC

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.


3.3 CAN

The TS-7400_V2 offers two CAN ports on pins that the TS-7400 used as DIO or GPBUS.

An example of working with the CAN bus will be made available soon.

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.

See the TS-7400_V2 manual and the i.MX28 manual for more information.


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

See the TS-7400_V2 manual and the i.MX28 manual for more information.


3.5 GPBUS

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


3.6 I2C

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.


3.7 I2S

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


3.8 Power

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 5v input, however its ranges must be within 4.8v and 5.2v. 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 5v 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.8v the CPU internal regulators will no longer be able to regulate properly and may cause system instability.


3.9 RTC

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.


3.11 SPI

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.

A code example of writing to an SPI device will be made available soon.

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.MX283, 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.

Code changes to access any of the temperature sensors will produce a large diff. 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.


3.13 UARTs

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
Debug UART /dev/ttyAM0
UART0 /dev/ttyAM0 /dev/ttySP0
UART1 /dev/ttyAM1 /dev/ttySP1
UART2 /dev/ttyTS0 /dev/ttySP2
UART3 /dev/ttySP3