From embeddedTS Manuals
TODO: Product Page
TODO: Product Images
TODO: Specifications Page
TODO: Mechanical Drawing
FTP Path
Cavium CNS2312 250MHz Arm®v4T ARM922 (Arm9™-compatible)
CPU Datasheet

1 Overview

he TS-7580-BOX features a 250MHz Cavium ARM9 CPU and a 8000 LUT Lattice FPGA. With 64MB RAM booting from MicroSD card slots, the TS-7580-BOX is a powerful and extremely reliable industrial embedded solution. External devices can connect to the TS-7580-BOX via Ethernet, USB, RS-232, RS-485, or CAN. The TS-7580-BOX is powered by a DC power supply anywhere in the 10-28V range. Dual internal microSD slots allows for expanded storage.

2 Getting Started

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

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

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

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

The TS-7580 receives power through the green CN2 connector which accepts 12-28V input. The board will also work when supplied as low as 5V, but below 11V DAQ and the high side switches may not behave as expected.

2.1 Get a Console

The TS-7580-BOX supplies console through the DB9 connector. During startup the console by default goes to the internal 16 pin JTAG header on pins 7 (TXD) and 8 (RXD). The TS-7580 will also redirect console to pins 2 (RXD) and 3 (TXD) on the DB9 header if you hold the reset button until the red LED turns on (approximately 5 seconds).

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.

Device Manager Putty Configuration

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.

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


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.

3 Boot Process

When the board is first powered on it looks at the available boot media and loads the first 512B. On the TS-7580 this will include the SD socket #0. If you are using DoubleStore the bootloader will attempt a fallback to the second SD card. The first 446 bytes of this contains relevant code to continue to boot the board. This will look for the first partition of type 0xda and load it as the kernel. The second partition of type 0xda is loaded as the initrd. These both must be on primary partitions, and other partition type are ignored at this stage. Our default images will account for this configuration.

Note: If you are using the serial console on the 16 pin header with the TS-9448 it will print dot for the first three steps (MBR loaded, kernel loaded, initrd loaded).

After the kernel and initrd are loaded the board will execute the kernel. The first step out of the kernel is the linuxrc script which is further described in the #Initrd / Busybox section.

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

4.1 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


Entire SD card

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


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


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


Entire SD card

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


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


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

From SBC


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


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


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


The entire card from SBC

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


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


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

4.2 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 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


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

4.3 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

5 Operating System

5.1 Linux

5.1.1 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".

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


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.


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.


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);
		fprintf(stderr, "Can't open database: %s\n", sqlite3_errmsg(db));
		fprintf(stderr, "SQL error: %s\n", zErrMsg);
	printf("closing test.db\n");
	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.

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/

        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@

After transferring the file to the board, execute it:

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

5.1.3 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




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


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.

6 Features

6.1 CPU Functionality

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

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

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

6.2 FPGA Functionality

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

Our FPGA has the capability to be reloaded on startup and reprogram itself with different configurations. The default bitstream is hardcoded into the FPGA, but the soft reloaded bitstreams can be placed in /ts7500_bitstream.vme.gz on the initrd root to make the board load the bitstream on startup. If we do not have a configuration you need, you can build a new bitstream, or contact us for our engineering services.

Bitstream ADC SD Card SPI CAN XUARTs PWM Channels
Default On On On Off 0-3 0-48

6.2.1 Syscon

The syscon is the FPGA core that provides general configuration for the board. For communicating with these addresses you can use the SBUS in your code, or you can call ts7500ctl. For example, this will read the Board ID which is the first register in this core.

ts7500ctl --address=0x60 --peek16
Offset Bits Access Function
0x60 15-0 Read Only Model ID
0x60 15-4 Write Only Reserved (Write 0)
3 Write Only SD#1 LED blink enable
2 Write Only SD#1 LED enable
1 Write Only SD#0 LED blink enable
0 Write Only SD#0 LED enable
0x62 15 Read/Write Green LED (1 = on)
14 Read/Write Red LED (1 = on)
13 Read/Write RTC SCL input
12 Read/Write RTC SDA input
11 Read/Write RTC SCL direction (1 - output)
10 Read/Write RTC SDA direction (1 - output)
9 Read/Write RTC SCL output
8 Read/Write RTC SDA output
7-4 Read Only Board submodel
3-0 Read Only FPGA revision
0x64 15-0 Read Only 16-bits of random data changed every 1 second.
0x66 15-12 Read Only DIO input for pins 40(MSB)-37(LSB)
11-8 Read/Write DIO output for pins 40(MSB)-37(LSB)
7-4 Read/Write DIO direction for pins 40(MSB)-37(LSB) (1 - output)
3 Read/Write Lattice tagmem clock
2 Read/Write Lattice tagmem serial-in (RW)
1 Read/Write Lattice tagmem CSn
0 Read Only Lattice tagmem serial-out (RO)
0x68 15-0 Read Only DIO input for pins 36(MSB)-21(LSB)
0x6a 15-0 Read Only DIO output for pins 36(MSB)-21(LSB)
0x6c 15-0 Read/Write DIO direction for pins 36(MSB)-21(LSB) (1 - output)
0x6e 15-0 Read/Write DIO input for pins 20(MSB)-5(LSB)
0x70 15-0 Read/Write DIO output for pins 20(MSB)-5(LSB)
0x72 15-0 Read/Write DIO direction for pins 20(MSB)-5(LSB) (1 - output)
0x74 15-0 Write Only #Watchdog feed register
0x76 15-11 N/A Reserved
10-6 Read/Write PLL phase (set by TS-BOOTROM)
5 Read Only mode3 latched bootstrap bit
4 Read/Write Reset switch enable (1 - auto reboot when dio_i[9] == 0)
3-2 Read/Write scratch reg
1 Read Only mode2 latched bootstrap bit
0 Read Only mode1 latched bootstrap bit
0x78 15 Read Only Reserved
14-10 Read Only DIO Input for pins 4(MSB)-0(LSB)
9-5 Read/Write DIO output for pins 4(MSB)-0(LSB)
4-0 Read/Write DIO direction for pins 4(MSB)-0(LSB)
0x7a 15-8 Read/Write DIO output for pins 48(MSB)-41(LSB)
7-0 Read/Write DIO direction for pins 48(MSB)-41(LSB)
0x7c 15-13 Read Only Reserved
12 Read Only VIN comparitor input
11-0 Read Only DIO input for pins 52(MSB)-41(LSB)
0x7e 15-8 Read/Write PWM duty output for VIN (0xff is 100%)
7-4 Read/Write DIO output for pints 52(MSB)-49(LSB)
3-0 Read/Write DIO direction for pins 52(MSB)-49(LSB)

6.2.2 XUARTs

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

See the #COM Ports section for a complete mapping.

6.2.3 SD


6.2.4 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


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:

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

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

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

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

The input channels are mapped to a standard format for all boards with the DAQ core here. This will cover the analog inputs, quadrature inputs, counters, and digital inputs. To sample the digital inputs:

daqctl --dumpcsv --chan=10 --speed=2khz

This will return channel 10 as a 64 bit number which correspond with the DIO IDs mapped here. For example, input ID 44 would be bit 44 in the DIO sample.

To sample the ADC inputs:

daqctl --dumpcsv --chan=0-7 --speed=100hz Outputs

The outputs are mapped directly to the ID's shown here. Every 7 DIO has it's own PWM frequency. 0-6 are on one frequency, 7-13 are on another, and so on.

For example, to set DIO 0-30 to output a PWM frequency of 100hz with a 50% duty cycle:

daqctl --pwm=0-30:50%@100hz

To toggle the DIO to be on or off, you would simply set a 0% or 100% duty cycle. To set DIO 30-40 low:

daqctl --pwm=30-40:0%
Note: The default bitstream has the IO IDs 0-48 enabled for PWM by default. If you use a bitstream that doesn't include the IO you are trying to control, it will still work as a DIO. The PWM values of 0-49% will set the output low, and 50-100 will set the output high. See the #FPGA Functionality section for the available configurations.

6.2.7 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 (;;) 
                sbus_poke16(0x74, 2);
                sleep(5); // Sleeping half of the 
                          // feeding time is usually a safe value

        return 0;

6.2.8 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= --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
Note: The default bitstream does not include CAN. See the #FPGA_Functionality section for a list of the available bitstreams including CAN.

6.2.9 DIO

Most of the DIO on the TS-7580 are simply controlled by setting the PWM value from 0% to 100%. For more information, see this section. For the rest of the DIO see the #Syscon for the register map to manipulate the data direction and data values. The Syscon map does not control access to all of the DIO on the RJ45 connectors which instead must be done through the daqctl interface.

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

6.2.11 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

6.2.12 Temperature Sensor

The TS-7580 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.

6.3 COM Ports

This board has 1 CPU UART at /dev/ttyS0 used for debugging, and up to 5 XUARTs. The XUARTs by default do not have a /dev/ entry, but you can use xuartctl to create one.

Port Type RX (or 485 +) TX (or 485 -)
ttyS0 TTL #JTAG Header pin 8 #JTAG Header pin 7
XUART0 RS232 DB9 pin 2 DB9 pin 3
XUART1 RS485 MODBUS port 0 RJ45 pin 4 MODBUS port 0 RJ45 pin 5
XUART2 RS485 MODBUS port 1 RJ45 pin 4 MODBUS port 1 RJ45 pin 5
XUART3 MODBUS port 2 RJ45 pin 4 MODBUS port 2 RJ45 pin 5
XUART4 TTL #XBEE Socket pin 2 #XBEE Socket pin 3
XUART5 RS232 DB9 pin 7 DB9 pin 8
XUART6 Isolated RS232 P8 pin 8 P8 pin 7
XUART7 isolated RS485 P8 pin 5 P8 pin 6
Note: XUARTs 4 and above are not included in the default bitstream. See the #FPGA Functionality section for a list of available bitstreams with more XUARTs included.

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

7 External Interfaces

7.1 Terminal Blocks

Note: If you have a REV A board disregard the P1-P10 labeling as printed on the PCB.
Pin ID Description
1 8 Low side switch
2 9 Low side switch
3 10 Low side switch
4 11 Low side switch
5 12 Low side switch
6 13 Low side switch
7 14 Low side switch
8 15 Low side switch
9 N/A Ground
10 N/A Ground
11 N/A Ground
12 N/A Ground
Pin ID Description
1 0 Low side switch
2 1 Low side switch
3 2 Low side switch
4 3 Low side switch
5 4 Low side switch
6 5 Low side switch
7 6 Low side switch
8 7 Low side switch
9 N/A Ground
10 N/A Ground
11 N/A Ground
12 N/A Ground
Pin ID Description
1 AD6 Analog Input
2 N/A Ground
3 AD7 Analog Input
4 N/A Ground
5 55 Analog Output
6 N/A Ground
7 56 Analog Output
8 N/A Ground
9 57 Analog Output
10 N/A Ground
11 58 Analog Output
12 N/A Ground
Pin ID Description
1 AD0 Analog Input
2 N/A Ground
3 AD1 Analog Input
4 N/A Ground
5 AD2 Analog Input
6 N/A Ground
7 AD3 Analog Input
8 N/A Ground
9 AD4 Analog Input
10 N/A Ground
11 AD5 Analog Input
12 N/A Ground
Pin ID Description
1 16 Low side switch
2 17 Low side switch
3 18 Low side switch
4 19 Low side switch
5 20 Low side switch
6 21 Low side switch
7 22 Low side switch
8 23 Low side switch
9 N/A Ground
10 N/A Ground
11 N/A Ground
12 N/A Ground
Pin ID Description
1 N/A 10-28VDC
2 N/A 10-28VDC
3 N/A 10-28VDC
4 N/A 10-28VDC
5 N/A 10-28VDC
6 N/A 10-28VDC
7 N/A 10-28VDC
8 N/A 10-28VDC
9 N/A 10-28VDC
10 N/A 10-28VDC
11 N/A Ground
12 N/A Ground
Pin ID Description
1 43 High side switch
2 44 High side switch
3 45 High side switch
4 46 High side switch
5 47 High side switch
6 48 High side switch
7 49 High side switch
8 50 High side switch
9 N/A Ground
10 N/A Ground
11 N/A Ground
12 N/A Ground
Pin ID Description
1 N/A Isolated Common Ground
2 N/A Isolated Common Ground
3 N/A Isolated CAN_H
4 N/A Isolated CAN_L
5 N/A Isolated RS485+
6 N/A Isolated RS485-
7 N/A Isolated RS232 TXD
8 N/A Isolated RS232 RXD
9 60 Isolated Input +
10 60 Isolated Input -
11 59 Isolated Input +
12 59 Isolated Input -
Pin ID Description
1 32 Low side switch
2 33 Low side switch
3 34 Low side switch
4 35 Low side switch
5 36 Low side switch
6 37 Low side switch
7 38 Low side switch
8 39 Low side switch
9 N/A Ground
10 N/A Ground
11 N/A Ground
12 N/A Ground
Pin ID Description
1 24 Low side switch
2 25 Low side switch
3 26 Low side switch
4 27 Low side switch
5 28 Low side switch
6 29 Low side switch
7 30 Low side switch
8 31 Low side switch
9 N/A Ground
10 N/A Ground
11 N/A Ground
12 N/A Ground

7.2 16 Pin Header

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


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


Pin # Name Function
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
WARNING: Reprogramming the FPGA through the JTAG pins exposed on this header is not supported or recommended. Rewriting the FPGA through these pins can brick your board. See the #FPGA Programming section for the recommended method.

7.3 USB Redirect Header

The TS-7520 allows you to redirect the external top USB host port to the internal top USB port. This allows you to use a fully enclosed USB device. The two jumper configurations are below:

USB External
Jumper 1 Jumper 1
Off Off
Jumper 2 Jumper 2
Off Off
USB Internal
Jumper 1 Off
Jumper 1 Off
Jumper 2 Off
Jumper 2 Off

8 Enclosures

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

9 Product Notes

9.1 FCC Advisory

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

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

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

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

9.2 Limited Warranty

See our Terms and Conditions for more details.

9.3 Trademarks

Arm9 is a trademark, and Arm is a registered trademark, of Arm Limited (or its subsidiaries) in the US and/or elsewhere.