TS-7520-BOX

TS-7520

Product Page
Documentation
Schematic
Mechanical Drawing
FTP Path
CPU Datasheet
CPU Manual

This document is for a product still in development and is subject to change at any time.

Overview

The TS-7520 is a multi-functional industrial controller based on a Cavium 250MHz ARM9 CPU that provides Modbus and a very powerful IO controller.

Getting Started

A Linux PC is recommended for development. For developers who use Windows, virtualized Linux using VMWare or similar are 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 target platform. 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.
• Builds such as Linux kernel, buildroot, yocto, distro-seed will not work from WSL1/2 on a case insensitive filesystem.

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.

The TS-7520 receives power through the bottom left terminal block which accepts 5-30 VDC.

Get a Console

If you have a TS-9448, you can connect that to the 16 pin header facing outwards and use the 10 pin header (labeled "Console") which will by default be the console port. If you do not have a TS-9448, you can hold the reset button for 5 seconds (until the red led lights up) and let go to switch the console port to CN1-M5 pins 5 and 6 using the standard 8n1, no flow control, 115200 baud rate. This will initialize xuartctl configured on port 0.

You can also telnet to the board with the default network configuration, though this will omit the TS-BOOTROM messages which are useful for debugging.

Use a null modem cable to connect the ARM system to your workstation. If you do not have a COM port on your system (as many newer systems do not), you can find a USB serial adapter that will bring out RS232.

Console from Linux

There are many serial clients for Linux, but 3 simple ones would be picocom, screen, and minicom. These examples assume that your COM device is /dev/ttyUSB0 (common for USB adapters), but replace them with the COM device on your workstation.

Linux has a few applications capable of connecting to the board over serial. You can use any of these clients that may be installed or available in your workstation's package manager:

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:

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.

Initrd / Busybox

After the board is first booted you will be at this shell:

  >> TS-BOOTROM - built Oct 12 2011 13:35:38
  >> Copyright (c) 2009, Technologic Systems
  >> Booting from SD card...
  .
  .
  .
  >> Booted from: SD card                 Booted in: 3.93 seconds
  >> SBC Model number: TS-XXXX            SBC Sub-model number: 0
  >> CPU clock rate: 250MHz               RAM size: 64MB
  >> NAND Flash size: 256MB               NAND Flash Type: 0xdcec (Samsung)
  >> MAC number: 00:D0:69:4F:6F:04        SBC FPGA Version: 7
  >> Temperature Sensor: 37.500 degC      MODE1 bootstrap: ON
  >> RTC present: YES                     Date and Time: Jan  1 1970 00:00:03
  >> MODE2 bootstrap: OFF                 SD card size: 1886MB
  >> Offboard SPI flash type: Micron      Offboard SPI flash size: 8MB
  >> XUARTs detected: 3                   CAN present: NO
  >> Linux kernel version: 2.6.24.4       Linux kernel date: Jun 8 2011
  >> Bootrom date: Oct 12 2011            INITRD date: Dec 27 2011
  >> ts7500ctl date: Jun  8 2011          sdctl date: Jun  8 2011
  >> canctl date: Jun  8 2011             nandctl date: Aug 15 2011
  >> spiflashctl date: Aug 15 2011        xuartctl date: Aug 15 2011
  >> dioctl date: Feb 10 2011             spictl date: Jan 24 2011
  >> dmxctl date: Jun  8 2011             busybox date: Jun 30 2010 (v1.14.2)
  >> ts7500.subr date: Jun 10 2011        daqctl date: Aug 15 2011
  >> linuxrc date: Aug 31 2011            rootfs date: Jan  1 1970
  >> MBR date: Jul 14 2009
  
  Type 'tshelp' for help
  # 

Note:

Your version dates may be different depending on ship date and the image used.

This is a busybox shell which presents you with a very minimalistic system. This filesystem is loaded into memory, so none of the changes will be saved unless you type 'save', or mount a filesystem as read write. This can also provide a simple mechanism for running your application in an entirely read only environment. The linuxrc script will be the first thing executed as soon as the kernel is loaded. This sets the default IP address, loads a reloadable FPGA bitstream if one is present, starts the userspace ctl applications, and more. Read the linuxrc for more information.

While busybox itself doesn't contain much functionality, it does mount the Debian partition under /mnt/root/. It will also add common paths and load libraries from the Debian system. Many of the Debian applications will work by default. If an application relies on certain paths being in certain places, or running services, you should instead boot to Debian to run them.

This shell when started on the COM port is what is blocking a Debian boot. If you close it by typing 'exit', the boot process will continue. If you are connected through telnet, this will instead open up its own instance of the shell so typing 'exit' will only end that session. Through any connection method you can relink the linuxrc script to always boot into Debian.

The initrd has these boot scripts available:

Script	Function
linuxrc-fastboot (default)	Boots immediately to a shell in ramdisk. This will mount whichever boot medium you have selected to /mnt/root/. When you type 'exit', it will boot to that medium.
linuxrc-nandmount	Same as the linuxrc-fastboot script, but will mount and boot the debian partition from NAND.
linuxrc-sdmount	Same as the linuxrc-fastboot script, but will mount and boot the debian partition from SD.
linuxrc-sdroot	Boots immediately to the Debian stored on either SD or NAND depending on which device you have currently selected.
linuxrc-sdroot-readonly	Same as linuxrc-sdroot, except it will mount the Debian partition read only while creating a unionfs with a ramdisk. Changes will only happen in memory and not on disk.
linuxrc-usbroot	Mounts the first partition of the first detected USB mass storage device and boots there.

Note:

Keep in mind the boot medium is selected by the pinout on your baseboard, not through software.

For example, to set the linuxrc to boot immediately to Debian on SD or NAND, you would run this:

rm linuxrc; ln -s /linuxrc-sdroot /linuxrc; save

To use any of the other boot scripts, you can simply replace 'linuxrc-sdroot' with the script name mentioned above. Once you have booted to Debian you can return to the initrd by creating the file "fastboot" in root.

touch /fastboot

To automatically boot back to Debian you will need to remove this file.

The small default initrd is only 2Mbyte but there is space for approximately 800 Kbyte of additional user applications. The binaries on the initrd are dynamically linked against embedded Linux's "uclibc" library instead of the more common Linux C library "glibc". "uclibc" is a smaller version of the standard C library optimized for embedded systems and requires a different set of GCC compiler tools which are available here.

The compiled instance of busybox includes several internal commands listed below:

   # /bin/busybox --help
   BusyBox v1.14.2 (2009-08-07 14:43:48 MST) multi-call binary
   Copyright (C) 1998-2008 Erik Andersen, Rob Landley, Denys Vlasenko
   and others. Licensed under GPLv2.
   See source distribution for full notice.
   
   Usage: busybox [function] [arguments]...
      or: function [arguments]...
   
           BusyBox is a multi-call binary that combines many common Unix
           utilities into a single executable.  Most people will create a
           link to busybox for each function they wish to use and BusyBox
           will act like whatever it was invoked as!
   
   Currently defined functions:
           [, [[, ash, basename, cat, chgrp, chmod, chown, chroot, cmp, cp,
           cpio, cttyhack, cut, date, dd, depmod, devmem, df, dirname, dmesg,
           du, echo, egrep, env, expr, false, fdisk, fgrep, find, grep, gunzip,
           gzip, halt, head, hostname, hush, ifconfig, insmod, kill, killall,
           ln, login, ls, lsmod, md5sum, mdev, mkdir, mknod, modprobe, more,
           mount, msh, mv, netstat, ping, pivot_root, poweroff, printf, ps,
           pwd, reboot, rm, rmdir, rmmod, route, rx, sed, setconsole, setsid,
           sh, sleep, stty, sync, tail, tar, telnetd, test, tftp, top, tr,
           true, udhcpc, umount, unzip, usleep, uudecode, uuencode, vi, wget,
           xargs, yes, zcat

Also on the initrd are the TS specific applications: sdctl, spiflashctl, nandctl, daqctl, ts7500ctl, canctl, and xuartctl. We also provide the ts7500.subr which provides the following functions:

 cvtime()
 usbload()
 sdsave()
 spiflashsave()
 save()
 sd2spiflash()
 spiflash2sd()
 setdiopin()
 getdiopin()
 setrelay()
 setout()
 getin()
 tshelp()
 gettemp()

By default, linuxrc will not insert the necessary modules into the kernel to mount and use USB devices within the initrd/busybox environment if there is no USB device present upon bootup (USB support is enabled by default within the Debian environment). The quickest way to get a USB device (like a USB thumb drive) to mount in the initrd/busybox environment is to ensure that it is plugged in before the SBC is powered up. In order to get hot-swappable USB devices regardless of device presence at bootup time, you must "modprobe" the necessary modules. This has been done for you in the ts7500.subr file with the usbload() function.

Boot Process

File:Boot-diagram.png

Boot Process

This section describes what code is executed when a system is powered on or reset using our TS-BOOTROM. The sequence is:

• CPU BootROM
• TS-BOOTROM
• Linux kernel
• linuxrc (initrd)
• Debian init
• Embedded application

The Debian init step may be excluded on systems that do not require Debian.

This board does not support U-Boot, RedBoot, or other standard bootloaders. The TS-BOOTROM is optimized for speed. This makes our systems ideal for applications that need to start immediately upon power-up. The TS-BOOTROM performs basic register initializations and RAM initialization, and then it selects a boot media based on jumper settings. If the media indicated by the jumper is clearly not bootable, the bootrom may fall back and boot from the other device.

Once the boot media is chosen, the TS-BOOTROM passes control to the 446 bytes of code found in the MBR. This code scans the partition table for partitions with an ID of 0xDA. The first partition found with this magic ID is loaded into RAM and treated as a kernel binary. If a second partition with this id is found, it is loaded into RAM and treated as an initial ramdisk. When this is done, execution jumps into the kernel.

For the small minority of systems that have a need to perform other behavior at boot time instead of executing a Linux kernel, developers will need to fully understand the functionality of the TS-BOOTROM. Second stage bootloaders, custom microcontroller-style binaries, or other operating systems can be loaded by TS-BOOTROM as long as they have an execution entry point in the same place as the Linux kernel would have on the particular System-on-Module in question. Contact embeddedTS if you need to execute a binary besides Linux.

Boot Selection With TS-9448

Switch Pos.	SDBOOT Jumper	Boot Behavior
Down	Off	XNAND
Any	On	Offboard SPI Flash
Up	Off	MicroSD

Note:

JP1 will cause the bootloader to only boot to SPI Flash

Boot Selection Without TS-9448

SDBOOT Jumper	Boot Behavior
Off	XNAND
On	MicroSD

Backup / Restore

If you are using a Windows workstation there is no support for writing directly to block devices. However, as long as one of your booting methods still can boot a kernel and the initrd you can rewrite everything by using a usb drive. This is also a good way to blast many stock boards when moving your product into production. You can find more information about this method with an example script here.

Note:

Note that the MBR installed by default on this board contains a 446 byte bootloader program that loads the initial power-on kernel and initrd from the first and second partitions. Replacing it with an MBR found on a PC would not work as a PC MBR contains an x86 code bootup program.

MicroSD Card

These instructions for rewriting the SD card must be done either on the arm system, or on a linux workstation. We do not support any method using Windows to rewrite the cards, but many virtual machines offer USB redirection which will also work with the USB card reader supplied in the development kit. The methods using dd and sdctl to rewrite the SD card will completely erase everything on the card and set up our MBR, kernel, intird, and Debian filesystem. No prior formatting to the card is needed.

After plugging in the USB adapter to your PC you will need to determine the block device. You can usually find this in the output of 'dmesg' after inserting the SD card and you will typically see something like '/dev/sdb' as the block device and '/dev/sdb1' for the first partition. On some newer kernels you will see '/dev/mmcblk0' as the block device and '/dev/mmcblkop1' for the first partition. For these examples I will use the '/dev/mmcblk0' format.

You can find the latest SD card image here. Make sure you decompress the image first before writing. For example to decompress on most Linux workstations you can run:

bzip2 -d dblstorimg-4gbsd-latest.dd.bz2

To update to our latest image from your workstation:

dd if=/path/to/dblstorimg-4gbsd-latest.dd of=/dev/mmcblk0 bs=32k && sync && sync

From Workstation

---

Backup

Entire SD card

dd if=/dev/mmcblk0 of=/path/to/backup.dd bs=32k && sync && sync

Kernel

dd if=/dev/mmcblk0p2 of=/path/to/zImage bs=32k && sync && sync

Initrd

dd if=/dev/mmcblk0p3 of=/path/to/initrd bs=32k && sync && sync

Restore

Entire SD card

dd if=/path/to/backup.dd of=/dev/mmcblk0 bs=32k && sync

Kernel

dd if=/path/to/zImage bs=32k of=/dev/mmcblk0p2 && sync

Initrd

dd if=/initrd bs=32k of=/dev/mmcblk0p3 && sync

From SBC

---

Backup

Entire card

# Determine the block size
eval $(sdctl)
dd if=/dev/nbd5 of=/path/to/backup.dd bs=512 count=$cardsize_sectors conv=sync && sync

Kernel

sdctl -R 4096 -z 512 --seek part1 > kernel

Initrd

sdctl -R 4096 -z 512 --seek part2 > initrd

Restore

The entire card from SBC

dd if=/path/to/2gbsd-noeclipse-latest.dd bs=512 conv=sync of=/dev/nbd5 && sync

Kernel

dd if=/mnt/root/zImage bs=512 conv=sync of=/dev/nbd7 && sync

Initrd

dd if=/mnt/root/initrd bs=512 conv=sync of=/dev/nbd8 && sync

Offboard SPI Flash (TS-9448)

This needs to be done directly on the SBC. You can find the latest SPI image here. Once downloaded you can decompress the image using bzip2:

bzip2 -d 4mb-spiflash-latest.dd.bz2

Some of this series contains a 4MB SPIflash embedded on the board that can be written to by specifying lun 0, or "-l 0" which will use that chip select. The offboard flash found on various baseboards, or console boards like the TS-9448 or TS-9449 can be written to using lun 1, or "-l 1".

Backup

Backup the entire SPI flash containing the MBR, Kernel, and initrd

spiflashctl -l 1 -R 64 -z 65536 > spiflash.dd

Backup only the Kernel

spiflashctl -l 1 -R 4095 -z 512 -k part1 > /temp/zImage

Backup only the Initrd

spiflashctl -l 1 -R 32 -z 65536 -k part2 > /temp/initrd

Restore

Write the entire SPI flash containing the MBR, Kernel, and initrd

spiflashctl -l 1 -W 64 -z 65536 -i /path/to/4mb-spiflash-latest.dd

Write a new Kernel

spiflashctl -l 1 -W 4095 -z 512 -k part1 -i /temp/zImage

Write a new Initrd

spiflashctl -l 1 -W 32 -z 65536 -k part2 -i /temp/initrd

Fastboot Recovery Commands

Since the Aug 5 2010 release, scripts have been added to the bash subroutine to ease in saving, recovering, and moving around images from one flash device to another. Below is a brief list of the commands that are provided as well as what they do. See the file /ts7500.subr (or /initrd/ts7500.subr from full Debian) for more information on the commands and what they do.

 save - Copy current initrd ramdisk to the media that the SBC is booted from
 sdsave - Copy current initrd ramdisk to mSD card
 sd2nand - Copy mSD kernel and initrd to NAND
 sd2flash - Copy mSD kernel and initrd to on-board SPI flash
 sd2flash1 - Copy mSD kernel and initrd to off-board SPI flash
 flash2sd - Copy booted SPI flash kernel and initrd to mSD card
 flashsave - Copy current initrd ramdisk to on-board flash (TS-7500 only)
 flash1save - Copy current initrd ramdisk to off-board flash (TS-752 or TS-9448)
 flash2flash - Copy booted SPI flash kernel and initrd to opposing SPI flash device (on-board to off-board and vice versa)
 flashallsave - Copy current initrd ramdisk to all SPI flash (on-board and off-board)
 nand2sd - Copy NAND flash kernel and initrd to mSD card
 nandsave - Copy current initrd ramdisk to NAND
 nand2flash - Copy NAND flash kernel and initrd to off-board flash
 flash2nand - Copy booted SPI flash kernel and initrd to NAND
 recover - Attempt to copy booted kernel and initrd to all other available flash devices

Operating System

Linux

Debian

Our boards boot a standard Debian installation which provides a large amount of software that you can install with relatively little effort. See the Debian page for more general information on installing/removing software, and further documentation.

For this series we provide Debian Etch and Debian Lenny. Further Debian releases have switched to EABI binaries (see EABI vs OABI), so we will not release Debian Squeeze or later for this board. The Cavium CNS2132 CPU supports the calls needed for EABI, but the Debian EABI binaries require thumb support which the Cavium does not support. If you require any specific software to be newer, you will have to manually build a later version.

We provide our distributions separate from the disk images. You can find them on this folder on the ftp. You will need a linux system to extract it:

# Replace the mmcblk0p4 device with the SD card
# on your workstation
mount /dev/mmcblk0p4 /mnt/sd/
cd /mnt/sd/
tar --numeric-owner -xvf /path/to/debian-lenny-arm-latest.tar.gz
cd ../
umount /mnt/sd/

You can download the Debian Etch and Debian Lenny minimal install for x86 from here and install it on a PC or virtual machine to become more familiar with a debian environment.

Note:

As of March 27th 2012 Debian Lenny has moved to archive. To use apt-get your will need to edit /etc/apt/sources.list to contain only the line "deb http://archive.debian.org/debian lenny main".

Software Development

Most of our examples are going to be in C, but Debian will include support for many more programming languages. Including (but not limited to) C++, PERL, PHP, SH, Java, BASIC, TCL, and Python. Most of the functionality from our software examples can be done from using system calls to run our userspace utilities. For higher performance, you will need to either use C/C++ or find functionally equivalent ways to perform the same actions as our examples. Our userspace applications are all designed to go through a TCP interface. By looking at the source for these applications, you can learn our protocol for communicating with the hardware interfaces in any language.

The most common method of development is directly on the SBC. Since debian has space available on the SD card, we include the build-essentials package which comes with everything you need to do C/C++ development on the board.

Editors

Vim is a very common editor to use in Linux. While it isn't the most intuitive at a first glance, you can run 'vimtutor' to get a ~30 minute instruction on how to use this editor. Once you get past the initial learning curve it can make you very productive. You can find the vim documentation here.

Emacs is another very common editor. Similar to vim, it is difficult to learn but rewarding in productivity. You can find documentation on emacs here.

Nano while not as commonly used for development is the easiest. It doesn't have as many features to assist in code development, but is much simpler to begin using right away. If you've used 'edit' on Windows/DOS, this will be very familiar. You can find nano documentation here.

Compilers

We only recommend the gnu compiler collection. There are many other commercial compilers which can also be used, but will not be supported by us. You can install gcc on most boards in Debian by simply running 'apt-get update && apt-get install build-essential'. This will include everything needed for standard development in c/c++.

You can find the gcc documentation here. You can find a simple hello world tutorial for c++ with gcc here.

Build tools

When developing your application typing out the compiler commands with all of your arguments would take forever. The most common way to handle these build systems is using a make file. This lets you define your project sources, libraries, linking, and desired targets. You can read more about makefiles here.

If you are building an application intended to be more portable than on this one system, you can also look into the automake tools which are intended to help make that easier. You can find an introduction to the autotools here.

Cmake is another alternative which generates a makefile. This is generally simpler than using automake, but is not as mature as the automake tools. You can find a tutorial here.

Debuggers

Linux has a few tools which are very helpful for debugging code. The first of which is gdb (part of the gnu compiler collection). This lets you run your code with breakpoints, get backgraces, step forward or backward, and pick apart memory while your application executes. You can find documentation on gdb here.

Strace will allow you to watch how your application interacts with the running kernel which can be useful for diagnostics. You can find the manual page here.

Ltrace will do the same thing with any generic library. You can find the manual page here.

Cross Compiling

If your sources are large enough that compiling on the board is too encumbering, we provide toolchains that you can use from another Linux or Cygwin environment.

For this board you will want to use this toolchain. Extract it to the root of your filesystem, and run that version of gcc to prepare the ARM binary.

To compile your application, you only need to use the version of GCC in the cross toolchain instead of the version supplied with your distribution. The resulting binary will be for ARM.

[user@localhost]$ /usr/local/arm-oabi-toolchain/arm-unknown-linux-gnu/bin/arm-unknown-linux-gnu-gcc hello.c -o hello
[user@localhost]$ file hello
hello: ELF 32-bit LSB executable, ARM, version 1, dynamically linked (uses shared libs), for GNU/Linux 2.6.26, not stripped

This is one of the simplest examples. If you want to work with a project, you will typically create a makefile. You can read more about makefiles [here]. Another common requirement is linking to third party libraries provided by Debian on the board. There is no exact set of steps you can take for every project, but the process will be very much the same. Find the headers, and the libraries. Sometimes you have to also copy over their binaries. In this example, I will link to sqlite from Debian.

Install the sqlite library and header on the board:

apt-get update && apt-get install -y libsqlite3-0 libsqlite-dev

This will fetch the binaries from the internet and install them. You can list the installed files with dpkg:

dpkg -L libsqlite3-0 libsqlite3-dev

The interesting files from this output will be the .so files, and the .h files. In this case you will need to copy these files to your project directory.

I have a sample example with libsqlite3 below. This is not intended to provide any functionality, but just call functions provided by sqlite.

#include <stdio.h>
#include <stdlib.h>
#include "sqlite3.h"

int main(int argc, char **argv)
{
	sqlite3 *db;
	char *zErrMsg = 0;
	int rc;
	printf("opening test.db\n");
	rc = sqlite3_open("test.db", &db);
	if(rc){
		fprintf(stderr, "Can't open database: %s\n", sqlite3_errmsg(db));
		sqlite3_close(db);
		exit(1);
	}
	if(rc!=SQLITE_OK){
		fprintf(stderr, "SQL error: %s\n", zErrMsg);
	}
	printf("closing test.db\n");
	sqlite3_close(db);
	return 0;
}

To build this with the external libraries I have the makefile below. This will have to be adjusted for your toolchain path. In this example I placed the headers in external/include and the library in external/lib.

CC=/opt/7500/arm-unknown-linux-gnu/bin/arm-unknown-linux-gnu-gcc
CFLAGS=-c -Wall

all: sqlitetest

sqlitetest: sqlitetest.o
        $(CC) sqlitetest.o external/lib/libsqlite3.so.0 -o sqlitetest
sqlitetest.o: sqlitetest.c
        $(CC) $(CFLAGS) sqlitetest.c -Iexternal/include/

clean:  
        rm -rf *o sqlitetest.o sqlitetest

You can then copy this directly to the board and execute it. There are many ways to transfer the compiled binaries to the board. Using a network filesystem such as sshfs or NFS will be the simplest to use if you are frequently updating data, but will require more setup. See your linux distribution's manual for more details. The simplest network method is using ssh/sftp. You can use winscp if from windows, or scp from linux. Make sure you set a password from debian for root. Otherwise the ssh server will deny connections. From winscp, enter the ip address of the SBC, the root username, and the password you have set. This will provide you with an explorer window you can drag files into.

For scp in linux, run:

#replace with your app name and your SBC IP address
scp sqlitetest root@192.168.0.50:/root/

After transferring the file to the board, execute it:

ts7500:~# ./sqlitetest 
opening test.db
closing test.db

Kernel Overview

The TS kernel is built from the same Linux sources Cavium Networks has tested and used on their CPU evaluation boards. There are no Technologic Systems specific drivers or kernel support implemented. Instead, there has been userspace driver support implemented for the SPI NOR flash, MicroSD cards, XNAND drive, battery-backed real-time clock, XUART serial port channels, watchdog, and GPIO pins. This allows easy migration to newer kernels when either Cavium or the mainline Linux kernel community creates them. In the past, constant Linux-internal API redesign required rewriting and revisiting custom drivers with each new kernel revision, in effect locking customers in to whatever kernel version was released and tested during initial product release. Being free to update to newer kernels in the future allows easier support of the new USB devices as those drivers tend to only be developed for the newest kernel sources.

We provide 2.6.24 as the supported kernel.

We also have 2.6.36, though USB device does not work (host does). This is provided as is.

Kernel Compile Guide

WARNING:

BACKUP YOUR DATA FIRST

Prerequisites

RHEL/Fedora/CentOS:

yum install ncurses-devel ncurses
yum groupinstall "Development Tools" "Development Libraries"

Ubuntu/Debian:

apt-get install build-essential libncurses5-dev libncursesw5-dev

For other distributions, please refer to their documentation to find equivalent tools.

Set up the Sources and Toolchain

# Download the cross compile toolchain (OABI)from Technologic Systems:
wget ftp://ftp.embeddedTS.com/ts-arm-sbc/ts-7500-linux/cross-toolchains/crosstool-linux-arm-uclibc-3.4.6.tar.gz

#Extract to current working directory:
tar xvf crosstool-linux-arm-uclibc-3.4.6.tar.gz

#Download the Cavium Sources
wget ftp://ftp.embeddedTS.com/ts-arm-sbc/ts-7500-linux/sources/linux-2.6.24-ts-src-aug102009.tar.gz

#Extract the Kernel Sources
gzip -dc linux-2.6.24-ts-src-aug102009.tar.gz | tar xf -

cd linux-2.6.24-cavium/

export ARCH=arm
export CROSS_COMPILE=../arm-uclibc-3.4.6/bin/arm-linux-

# This sets up the default configuration for the Cavium CPU
make ts7500_defconfig

Note:

If you get the message "Make: *** mixed implicit and normal rules. Stop." Then you may need to downgrade your version of make.

make menuconfig

This will bring up a graphical menu where you can edit the configuration to include support for new devices. For Example, to include CIFS support, use the arrow and Enter keys to navigate to Filesystems -> Network File Systems -> CIFS Support. Press "y" to include CIFS support into the kernel (alternatively, you could modularize the feature with "m" so you can enable or disable the module on demand which will also enable you to simply copy/paste the cifs.ko into the correct path in the kernel instead of copying the entire kernel (outlined below in appendix)). Keep hitting "exit" until you're prompted to save changes, choose "yes".

Once you have it configured, start building. This usually takes a few minutes.

make && make modules

The new kernel will be at "arch/arm/boot" in a compressed format called zImage. The uncompressed version is simply called Image. With the default partitioning scheme it is REQUIRED that the kernel be < 2096640 bytes in size. If you need to shorten the size, try including your changes to the kernel as modules instead. Otherwise you will need to resize the kernel partition to account for the size difference.

Now that you have a kernel you can install it as you would our stock. See the #Backup / Restore section for examples on writing this to disk.

Now we need to install the modules.

mkdir newmodules
INSTALL_MOD_PATH=newmodules make modules_install

#Replace /dev/sdb with your sd card
mkdir /mnt/miniSD4
mount /dev/sdb4 /mnt/miniSD4/

#Remove existing modules:
rm -r /mnt/miniSD4/lib/modules/*
cp -r newmodules/* /mnt/miniSD4/

umount /mnt/miniSD4

After you install the new modules, you will need to boot the kernel and run "depmod -a" to rebuild the dependency map. You can them use modprobe to load the individual modules.

You can also copy individual modules to your existing kernel assuming the kernel is the exact same version as the installed one.

If you require functionality from a newer kernel, we also provide sources for the 2.6.36 kernel patched with support as-is. You can find the sources here. You will need to also use this toolchain. The rest of the steps for building the kernel are the same. This kernel should function the same as the other, however the USB device driver is not implemented. We strongly suggest using the 2.6.24 kernel unless you have a requirement for a later kernel as the 2.6.24 is supported and has gone through much more testing through various productions.

We also now have a copy of a 3.4.0 kernel source here. These same instructions are applicable but you will need to use this toolchain instead of the one used with 2.6.24.

CPU Functionality

This board features a CNS2132 250MHz ARM9 processor. For more details see the CPU Datasheet.

I2C

The I2C_SCL and I2C_SDA pins bring out the I2C bus from the CNS2132 CPU. We do have an example for connecting to the I2C bus that uses the temperature sensor used on some of this series. You can find the C example here.

Please refer to the CNS2132 user's guide, page 55, 144, and 312 for more information on this I2C bus.

USB Host

The Cavium CPU supplies standard USB 2.0 ports. The power to the USB can also be toggled by setting a DIO.

# This is sourced in the initrd, but if you are running
# from Debian you will need to source the subroutine file.
source /initrd/ts7500.subr

# Power off USB
setdiopin 7 0

# Power on USB
setdiopin 7 1

WIFI-N-USB

See the WIFI-N-USB page for information on using the WIFI-N-USB module.

WIFI-G-USB-2

Note:

The WIFI-G-USB-2 USB adapter went end of life in June 2011. This has been replaced with the WIFI-N-USB

The WIFI-G-USB-2 kernel module is included in the Debian modules.

WIFI-G-USB

Note:

The WIFI-G-USB USB adapter is EOL. This has been replaced with the WIFI-N-USB

The WIFI-G-USB kernel module is included in the Debian modules.

FPGA Functionality

If you are accessing any registers here manually, you will need to acquire the SBUS lock. todo

Syscon

todo

FPGA Programming

Note:

We do not provide support for the opencores under our free support, however we do offer custom FPGA programming services. If interested, please contact us.

The opencore FPGA sources are available here.

We have prepared the opencore projects which gives you the ability to reprogram the FPGA while either preserving or removing our functionality as you choose. The code sources are in verilog, and we use Lattice Diamond to generate the JEDEC file. You can download Lattice Diamond from their site. You can request a free license, and it will run in either Windows or Linux (only Redhat is supported). In the sources you can find the functionality switches in the <boardname>_top.v file:

parameter sdcard_opt = 1'b1;
parameter spi_opt = 1'b1;
parameter nandflash_opt = 1'b1;
parameter can_opt = 1'b1; /*If CAN is enabled, only two XUARTs can be used*/
/* software currently requires these to be enabled/disabled contiguously. */
parameter xuart0_opt = 1'b1;
parameter xuart1_opt = 1'b1;
parameter xuart2_opt = 1'b0;
parameter xuart3_opt = 1'b0;
parameter xuart4_opt = 1'b0;
parameter xuart5_opt = 1'b0;
parameter xuart6_opt = 1'b0;
parameter xuart7_opt = 1'b0;

You can use these switches to enable and disable functionality. We do not enable everything at the same time because of space constraints on the FPGA. So for example, to disable CAN and enable the rest of the XUARTS:

parameter sdcard_opt = 1'b1;
parameter spi_opt = 1'b1;
parameter nandflash_opt = 1'b1;
parameter can_opt = 1'b0; /*If CAN is enabled, only two XUARTs can be used*/
/* software currently requires these to be enabled/disabled contiguously. */
parameter xuart0_opt = 1'b1;
parameter xuart1_opt = 1'b1;
parameter xuart2_opt = 1'b1;
parameter xuart3_opt = 1'b1;
parameter xuart4_opt = 1'b1;
parameter xuart5_opt = 1'b1;
parameter xuart6_opt = 1'b1;
parameter xuart7_opt = 1'b1;

For more advanced changes you may look to opencores.org which has many examples of FPGA cores. To build the FPGA with your new changes, go to the 'Processes' tab and double-click 'JEDEC File'. This will build a jedec file in the project directory. On a linux system, either x86 compatible or ARM, we provide an application called jed2vme.

jed2vme for x86

jed2vme for ARM (oabi)

We also have the sources here.

WARNING:

Do not use the 'jed2vme' provided by Lattice. Their version writes to flash and as the opencores do not contain the bootrom so this will brick your board.

jed2vme can be used like this:

jed2vme bitstream.jed | gzip > bitstream.vme.gz

To execute this on your board run this:

ts7500ctl --loadfpga=bitstream.vme
# or
ts7500ctl --loadfpga=bitstream.vme.gz

As space is constrained in the initrd it is suggested to gzip the file as shown in the jed2vme example. To load this bitstream automatically you can place it in the root of the initrd and name it '/ts7500_bitstream.vme.gz'. The linuxrc script will by default load this bitstream immediately on startup (before the fastboot shell). You should first test it manually to make sure it loads ok.

The FPGA contains flash memory which contains Technologic System's default FPGA flash load. Using an SRAM bitstream generated by our "jed2vme" with "ts7500ctl --loadfpga" will not overwrite the flash memory of the FPGA and will only load the SRAM contents of the FPGA, making for an unbrickable system.

XUARTs

The XUARTs are userspace implemented seial devices. See the xuartctl page for more information on working with these UARTs.

Battery powered RTC

The RTC connects through I2C to the FPGA. Typically, the battery-backed real time clock is only set or read in the linuxrc bootup script by the ts7500ctl utility. It is only necessary to read the RTC once per bootup to initialize the Linux time of day. This is done with the command "ts7500ctl --getrtc". To set the RTC time, you simply set the Linux time of day (with e.g. the "date" utility) and then run ts7500ctl --setrtc. RTC's are already set before shipment to atomic UTC time and should hold time within 15 PPM while at room temperature.

WARNING:

Be careful when handling board with a battery inserted -- the battery holder leads are through-hole and should the board be placed on a conductive surface and short the battery leads, the RTC will loose its track of time and need to be reset.

SD

todo

SPI

This core is for high speed SPI with auto-CS#. Starts at offset 0x40 on the this series. Chip select #0 is typically used for onboard spiflash. Chip select #1 is used for offboard spiflash. The last 2 chip selects are always available on the Cavium series boards.

The SPI controller is an FPGA core which is accessed using spictl. The simplest method for communication is calling spictl through bash:

# Read 32 bytes from LUN1
spictl --lun=1 --readstream=32

# Write Hello (68:65:6c:6c:6f)
spictl --lun=1 --writestream=68:65:6c:6c:6f

Usage:

ts7500:~# spictl --help
Technologic Systems SPI controller manipulation.

General options:
-c | --clock=frequency    SPI clock frequency
-e | --edge=value         set clock edge (positive for > 0, negative for < 0)
-w | --writestream=data   write colon delimited hex octets to SPI
-d | --readwrite=data     write colon delimited hex octets to SPI while reading to stdout
-r | --readstream=bytes   read specified number of bytes from SPI to stdout
-o | --holdcs             don't de-assert CS# when done
-l | --lun=id             Talk to specified chip number
-s | --server=<port>      Daemonize and run as server listening on port
-p | --port=<host><:port> Talk to spictl server
hex octets are hexadecimal bytes. for example,
this command reads 32 bytes of CS#1 SPI flash from address 8192:
./spictl -l 1 -w 0B:00:20:00:00 -r 32

The spictl utility can also run as a TCP server which lets you easily access SPI in your application. To start the tcp server on port 7755:

spictl --server=7755

The data stream packet to a spictl server consists of opcodes and operands. Each opcode is one byte long and may encode part or all of the operand. Some opcodes specify that additional bytes of data follow to contain the remainder of the operands.

There are four opcodes encoded in the two msb of the opcode byte:

• OPCODE 0 = CHIP SELECT
  • The chip number is encoded in the two LSB.
    • 00 = CS#0
    • 01 = CS#1
    • 10 = CS#2
    • 11 = CS#3
  • If Bit 5 is set, OPCODE = ASSERT CHIP SELECT.
  • Then If Bit 3 is set, Bit 2 is the new SPI edge to use (1 = positive edge, 0 = negative edge). Also, two additional bytes follow as operands. These two bytes are a big-endian encoded clock value. This value multiplied by 2048 is the SPI clock frequency to use. If Bit 5 is clear, OPCODE = DE-ASSERT CHIP SELECT
• OPCODE 1 = READ
  • The number of bytes to read must be a power of two, encoded in the 6 lsb. These six bits represent the number to raise 2 to the power of to get the length. So,
    • 00_0000 = 1 byte
    • 00_0001 = 2 bytes
    • ...
    • 00_1100 = 4096 bytes
• OPCODE 2 = WRITE
  • The number of bytes to write is encoded in the same manner as for a READ opcode. After the opcode byte, the number of bytes to write follows as the operands.
• OPCODE 3 = READWRITE
  • This opcode encodes identically as the WRITE opcode. However it specifies that bytes are to be READ as well as written.

You can also use the spictl --server=<port> and run a second invokation of spictl with --port=<port> to have the second instance act as a client to the server. You can then use tcpdump to see the exact tcp packets being sent back and forth for various operations.

The table below is the register map for the SPI in the FPGA:

Offset	Access	Bit(s)	Description
0x40	Read Only	15	SPI MISO state
	Read/Write	14	SPI CLK state
	Read/Write	13:10	Speed - 0 (highest), 1 (1/2 speed), 2 (1/4 speed)...
	Read/Write	9:8	LUN (0-3 representing the 4 chip selects)
	Read/Write	7	CS (1 - CS# is asserted)
	N/A	6:1	Reserved
	Read/Write	0	Speed
0x42	Read Only	15:0	Previous SPI read data from last write
0x44	N/A	15:0	Reserved
0x46	N/A	15:0	Reserved
0x48	Read/Write	15:0	SPI read/write with CS# to stay asserted
0x4a	Read Only	15:0	SPI pipelined read with CS# to stay asserted
0x4c	Read/Write	15:0	SPI Read/Write with CS# to deassert post-op
0x4e	N/A	15:0	Reserved

The SPI clk state register should be set when CS# is deasserted. Value 0 makes SPI rising edge (CPOL=0), 1 is falling edge (CPOL=1). This only applies to speed >= 1. For speed == 0, SPI clock polarity/skew must be set from the PLL phase adjust registers in the syscon block.

Where the base clock is 75Mhz (extended temp alters this to 50Mhz), speed settings break down as follows:

 0 - 75Mhz (/1)
 1 - 37.5Mhz (/2)
 2 - 18.75Mhz (/4)
 3 - 12.5Mhz (/6)
 4 - 9.375Mhz (/8)
 5 - 7.5Mhz (/10)
 6 - 6.25Mhz (/12)
 7 - 5.36Mhz (/14)
 8 - 4.68Mhz (/16)
 9 - 4.17Mhz (/18)
 ...
 15 - 2.5Mhz (/30)
 ... 
 19 - 1.97MHz (/38)
 ...
 31 - 1.21MHz (/62)

Bits 10-15 were not present on TS-75XX FPGA prior to rev 4. On those TS-75XX's, SPI speed was hardcoded to 75Mhz and 75Mhz only.

The pipelined read register is for read bursts and will automatically start a subsequent SPI read upon completion of the requested SPI read. Reading from this register infers that another read will shortly follow and allows this SPI controller "a head start" on the next read for optimum read performance. This register should be accessed as long as there will be at least one more SPI read with CS# asserted to take place. This register is an appropriate target address for SBUS burst reads.

SPI Flash

The SPI flash is also implemented in userspace with NBD, however it is not mounted or running by default. Even when you are booted to SPI, it does not need to access it directly since the bootrom will load it into memory before the Linux kernel is even executing. If you want to mount any part of it see the spiflashctl page for usage.

Data Acquisition Core (ADC, PWM, Counters, DIO)

The data acquisistion core is controlled by daqctl. The inputs and outputs specific to the TS-7558 are shown below. Please see the daqctl page for more information on using and programming with these IOs.

Inputs

Outputs

The output number listed here can be used in conjunction with daqctl to control

Number	Type	Location
0	Low Side Switch	A1
1	Low Side Switch	A2
2	Low Side Switch	A5
3	Low Side Switch	A7
4	Low Side Switch	A8
5	Low Side Switch	B1
6	Low Side Switch	B2
7	Low Side Switch	B5
8	Low Side Switch	B7
9	Low Side Switch	B8
10	Low Side Switch	C1
11	Low Side Switch	C2
12	Low Side Switch	C8
13	Low Side Switch	F5
14	Low Side Switch	G1
15	Low Side Switch	G2
16	Low Side Switch	G5
17	Low Side Switch	G7
18	Low Side Switch	G8
19	Low Side Switch	H1
20	Low Side Switch	H2
21	Low Side Switch	H5
22	Low Side Switch	H7
23	Low Side Switch	H8
24	Low Side Switch	J1
25	Low Side Switch	J2
26	Low Side Switch	J5
27	Low Side Switch	J7
28	Low Side Switch	J8
29	Low Side Switch	K7
30	Low Side Switch	K8
31	Low Side Switch	L7
32	Low Side Switch	L8
43	High Side Switch	A3
44	High Side Switch	B3
45	High Side Switch	C3
46	ADC_CH2

Watchdog

By default the watchdog is fed by ts7500ctl. This way if userspace, the kernel, or the FPGA communication has any issue the board will reboot. For many applications this may be enough, but you can tailor this more specifically to your application by feeding the watchdog on your own criteria. The watchdog feed register is write-only. Valid write values are:

Value	Result
0	feed watchdog for another .338s
1	feed watchdog for another 2.706s
2	feed watchdog for another 10.824s
3	disable watchdog

Watchdog by default comes out of reset armed for .338 seconds. TS-BOOTROM firmware feeds for 10.824 and OS code has 10.824 seconds to take over. If you would like to run your own watchdog you will need to kill ts7500ctl when switching to your own application. You can feed the watchdog from your application by poking a register:

// Compile with gcc filename.c -o watchdog
#include <stdio.h>
#include <unistd.h>
#include "sbus.h"

int main(int argc, char **argv)
{
        // This is an example of feeding the watchdog for 10s
        for (;;) 
        {
                sbuslock();
                sbus_poke16(0x74, 2);
                sbusunlock();
                sleep(5); // Sleeping half of the 
                          // feeding time is usually a safe value
        }

        return 0;
}

CAN

The FPGA contains a SJA1000C compatible CAN controller that can be accessed using canctl which provides a CAN network service. Any application on the network can make use of this service to send or receive CAN packets using the API defined by canctl. Thus, it is possible to develop code written in other languages (java, python, etc.) and/or to run this code under other operating systems.

The canctl server is started by running:

Note:

Due to a bug in some releases, daqctl will grab the IRQ before canctl. If CAN is unable to take the IRQ you can stop the daqctl process to reclaim it: killall daqctl canctl --server

The easiest interface to CAN is calling "canctl" through the command line:

canctl --port=127.0.0.1 --txdat=01:02:03:04:05:06

# canctl --help
Technologic Systems CAN controller manipulation.
-a | --address=ADR        CAN register address
-b | --baud=BAUD          CAN baud rate (7500 to 1000000)
-R | --peek8r             CAN register read
-W | --poke8w=VAL         CAN register write
-i | --txid=ID            CAN TX packet ID
-T | --txrtr              TX RTR packet
-d | --txdat=DAT          TX packet with data DAT
-s | --server==<port>     Daemonize and run as server
-D | --dump               Receive and print all CAN packets
-0 | --btr0=BTR0          SJA1000 BTR0 bus timing reg val
-1 | --btr1=BTR1          SJA1000 BTR1 bus timing reg val
-t | --txtest             Send TX test pattern
-r | --rxtest             Do RX test
-p | --port=<host><:port> Talk to canctl server
-S | --std                Send standard frame (not extended)
-v | --recover            Automatically recover from bus-off

The canctl application implements network CAN functionality using the can_rx_remote() and can_tx_remote() functions. These functions which read and write one fixed-size packet of struct canmsg to a TCP socket descriptor. Writing your own canctl client in the language of your choice is as simple as doing the same thing. The format of the each CAN packet sent or received via the network interface is described below. The terms "Rx" and "Tx" are relative to the client, so "Rx" would describe packets read from CAN over the network and "Tx" would describe packets written to CAN over the network.

 UINT32   flags:
          bit 7 - set on Tx if packet is a control packet
                  control packets are intercepted by the
                  canctl server to allow control functionality.
          bit 6 - set if message originates locally (unused)
          bit 5 - set if CAN message has extended ID
          bit 4 - set if remote transmission request (RTR)
          bit 3 - set on Rx if CAN error warning condition occurred
          bit 2 - set on Rx if CAN bus had a data overrun
          bit 1 - set on Rx if CAN bus went error passive
          bit 0 - set on Rx if a CAN bus error occurred
          Error conditions are reported for informational
          purposes.  The server normally handles these errors
          and recovers from them.
              control information present (reserved for future use)
              message originates from this node (unused)
 UINT32   CAN id
 UINT32   timestamp_seconds
 UINT32   timestamp_microseconds
 UINT32   bytes of CAN data which are valid
          if bit 7 of flags is set, this byte is instead interpreted
          as a command number:
            0 = set acceptance filter
              if the acceptance filter has been set, then only
              CAN packets which pass the filter will be received.
              to pass the filter, all bits in the acceptance filter
              which are to be checked (specified by a 1 in the
              corresponding bit of the mask) are compared (filter
              id compared to corresponding bit in received id).
              only if all bits to be checked do match will the
              packet be received.
 UINT8[8] CAN data
          if bit 7 of flags is set, this byte is instead interpreted
          as follows:
            cmd 0:
              UINT32 acceptance filter id
              UINT32 acceptance filter mask

UINT32 values are sent in little-endian format.

So for example, to send a standard CAN packet of length 6 with contents 01:02:03:04:05:06 and CAN id 55 it would be necessary to open a TCP connection to port 7552 on the device with the canctl server running, and the write the following packet to the socket:

  00 00 00 00 55 00 00 00 00 00 00 00 00 00 00 00 06 00 00 00 01 02 03 04 05 06 00 00

DIO

This board brings out only FPGA DIO. Since the FPGA is connected to the processor using SPI which is not atomic, we have created the SBUS which allows safe access from multiple processes. The SBUS mechanism of locking as well as it being a serial bus to the FPGA does put a limit on how fast the DIO can be read or set. Depending on the needs of the application the code can be structured to provide a bit of flexibility in speeds.

The "ts7500.subr" file provides the simplest method for accessing these DIO:

# If you're in the initrd:
source /ts7500.subr

# If you're in Debian:
source /initrd/ts7500.subr

#Usage: setdiopin <pin> <1,0,Z> <b>
setdiopin 20 0

#Usage: getdiopin <pin>
getdiopin 21

You can also interface with this DIO in C using the example here.

...
sbuslock();
setdiopin(21, (getdiopin(21) ^ 0x01));
sbusunlock();
...

Using this method of an atomic read-modify-write will achieve about a 20KHz wave with a 50% duty cycle.

...
sbuslock();
setdiopin(21, 1);
setdiopin(21, 0);
sbusunlock();
...

Using this method of atomic writes will achieve about a 30KHz wave with about a 20% duty cycle.

The SBUS link between the FPGA and CPU is SPI with a 16-bit data frame per bus cycle. When setting and reading one pin at a time, a whole 16-bit cycle is used to accomplish the needed goal. If multiple pins need to be set or read at once, a performance gain can be had from reading/writing entire 16bit registers at a time as opposed to iterating through each pin sequentially.

Other factors can contribute to speeds of the SBUS. Since the SBUS is shared across multiple peripherals there could be bus contention. It may also be that there are very few other applications wanting access to the bus, it all depends on usage. There is more overhead in doing a sbuslock() and sbusunlock() after every transaction than there would be to queue up transactions, lock the bus, and then do them all at once. There is also another function provided in sbus.c that is a smarter version of sbusunlock(), it is called sbuspreempt(). sbuspreempt() will check to see if any other applications are blocked in acquiring the lock, if there are, the SBUS is unlocked, giving other applications access to it. If there are no other applications waiting for the lock, the current application retains the lock. The benefit of this, is next time sbuslock() is called, the function returns almost instantly because the lock is already held. This greatly reduces overhead.

It may be necessary to "tune" an application with locking, unlocking, and preempting the SBUS to find what works best if speed is a factor.

The DIO registers are described in the #Syscon section. This board has 40 logical DIO registers on the FPGA to remain consistant with the series, but not all of the pins are brought out. DIO 9 by default is an external reset which is pulled high, and when it is set to 0 the board will reboot. You can disable this functionality by clearing bit 4 of 0x76 in the #Syscon.

Random Number Generator

The FPGA has a random number generator. On startup, ts7500ctl is called with the --setrng option to seed Linux's random number generator from the hardware random number generator. Without a good source of entropy, Linux's random number generator will start up in a very predictable state which is undesirable for the security of many cryptography protocols.

External Reset

Driving the external reset pin (DIO 9) low will reset the CPU by default. You can disable this functionality by running:

ts7500ctl --resetswitchoff

Temperature Sensor

The TS-7520 uses a temperature sensor that it communicates with over I2C. You can find a source code example here. Otherwise you can use 'ts7500ctl -T' to print the temperature.

Connectors

16x RJ45

Pin Location	Channel	Type
A1	0	Low Side Switch
A2	1	Low Side Switch
A3	43	High Side Switch
A4		Ground
A5	2	Low Side Switch
A6		Ground
A7	3	Low Side Switch
A8	4	Low Side Switch
B1	5	Low Side Switch
B2	6	Low Side Switch
B3	44	High Side Switch
B4		Ground
B5	7	Low Side Switch
B6		Ground
B7	8	Low Side Switch
B8	9	Low Side Switch
C1	10	Low Side Switch
C2	11	Low Side Switch
C3	45	High Side Switch
C4		Ground
C5	55	Analog Output
C6		Ground
C7	56	Analog Output
C8	12	Low Side Switch
D1	AD0	Analog Input
D2		Ground
D3	ADC1	Analog Input
D4		Ground
D5	ADC2	Analog Input
D6		Ground
D7	ADC3	Analog Input
D8		Ground
E1	AD4	Analog Input
E2		Ground
E3	ADC5	Analog Input
E4		Ground
E5	ADC6	Analog Input
E6		Ground
E7	ADC7	Analog Input
E8		Ground
F1	59	Isolated Input +
F2		Isolated Input -
F3	48	High Side Switch
F4		Ground
F5	13	Low Side Switch
F6		Ground
F7	60	Isolated Input -
F8	60	Isolated Input +

16 Pin Header

TS-7558 also includes a .1" pin spacing external header for board to board interfacing.

Diagram

   -----------------------
  | 2  4  6  8 10 12 14 16|
* | 1  3  5  7  9 11 13 15|
   -----------------------

Pinout

Pin #	Name	Function
1	JTAG_DOUT
2	JTAG_TMS	4.7k pull-up
3	GND	Ground
4	JTAG_DIN	4.7k pull-up
5	MODE2	Latched boot up mode 2, 4.7k pull-up
6	JTAG_CLK	2.2k pull-up
7	CONSOLE_TXD	Console TX, latched boot up mode 1, 4.7k pull-up
8	CONSOLE_RXD	Console RX, 4.7k pull-up
9	BOOT_SPI_MISO	SPI master-in slave-out
10	3.3V	3.3V power
11	BOOT_SPI_CS1	SPICS#1 output
12	BOOT_SPI_MOSI	SPI master-out slave-in
13	SDA	I2C/DIO-driven by CPU, 2.2k pull-up
14	BOOT_SPI_CLK	SPI clock output
15	SCL	I2C/DIO-driven by CPU, 2.2k pull-up
16	WD_RESET	Watchdog or system reset output

COM Ports

The XUART ports will be controlled with xuartctl. By default they will not have devices in /dev/.

Name	Type	Location

Enclosures

The TS-7520 is only compatible with the enclosure it ships with. This measures 5.01"x1.8"x7.5".

Product Notes

FCC Advisory

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

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

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

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

Limited Warranty

See our Terms and Conditions for more details.