TS-7580-BOX
| TODO: IMAGE MISSING | |
| TODO: Product Page | |
| TODO: Product Images | |
| TODO: Specifications Page | |
| Documentation | |
|---|---|
| Schematic | |
| TODO: Mechanical Drawing | |
| FTP Path | |
| Processor | |
| Cavium CNS2312 250MHz Arm®v4T ARM922 (Arm9™-compatible) | |
| CPU Datasheet |
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.
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-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.
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.
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.
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
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.
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.
Features
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.
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 |
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) |
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.
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
- The chip number is encoded in the two LSB.
- 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
- 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,
- 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 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. |
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
| Note: | The default bitstream does not include CAN. See the #FPGA_Functionality section for a list of the available bitstreams including CAN. |
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.
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-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.
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. |
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. |
External Interfaces
Terminal Blocks
| Note: | If you have a REV A board disregard the P1-P10 labeling as printed on the PCB. |
|
|
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
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 |
| 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. |
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:
| Jumper 1 | Jumper 1 |
| Off | Off |
| Jumper 2 | Jumper 2 |
| Off | Off |
| Jumper 1 | Off |
| Jumper 1 | Off |
| Jumper 2 | Off |
| Jumper 2 | Off |
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.
Trademarks
Arm9 is a trademark, and Arm is a registered trademark, of Arm Limited (or its subsidiaries) in the US and/or elsewhere.