# Auditeon

### Site Tools

software:linux:jtag

# Using ftdi 2232 with linux

Install drivers for the ftdi device from here:

cd ~/Downloads
tar xjf libftdi1-1.0.tar.bz2
cd libftdi1-1.0

sudo apt-get install build-essential
sudo apt-get install pkg-config
sudo apt-get install cmake
sudo apt-get install git-core
sudo apt-get install doxygen

Ended up with:

Click to display ⇲

Click to hide ⇱

...
Err http://no.archive.ubuntu.com/ubuntu/ quantal-updates/main linux-libc-dev i386 3.5.0-24.37
...
Err http://no.archive.ubuntu.com/ubuntu/ quantal-updates/main libruby1.9.1 i386 1.9.3.194-1ubuntu1.2
Err http://security.ubuntu.com/ubuntu/ quantal-security/main libruby1.9.1 i386 1.9.3.194-1ubuntu1.2
...
Err http://no.archive.ubuntu.com/ubuntu/ quantal-updates/main ruby1.9.1 i386 1.9.3.194-1ubuntu1.2
...
Err http://security.ubuntu.com/ubuntu/ quantal-security/main ruby1.9.1 i386 1.9.3.194-1ubuntu1.2
...
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?

Solved these errors with1):

wget http://launchpadlibrarian.net/130603929/linux-libc-dev_3.5.0-24.37_i386.deb
sudo dpkg -i linux-libc-dev_3.5.0-24.37_i386.deb
sudo apt-get upgrade

Then for ruby:

sudo apt-get install ruby1.9.1 ruby1.9.1-dev rubygems1.9.1 irb1.9.1 ri1.9.1 rdoc1.9.1 build-essential libopenssl-ruby1.9.1 libssl-dev zlib1g-dev

Check installation with

ruby --version

Install dependencies:

sudo apt-get install libusb-1.0-0-dev
sudo apt-get install libconfuse-dev
sudo apt-get install swig python-dev
sudo apt-get install libboost-all-dev
sudo apt-get autoremove

Clone the git repository:

mkdir -p ~/devel/libftdi
cd ~/devel/libftdi
git clone git://developer.intra2net.com/libftdi

Then make libftdi:

cd libftdi/
mkdir build
cd build/
cmake -DCMAKE_INSTALL_PREFIX="/usr" ../
make
sudo make install

## Testing ftdi 2232 devices

I have two different ftdi 2232 based devices. Testing them should reveal the same result. The OpenMoko has some issue that it cannot be opened, as can be seen below. However this does not seem to affect the JTAG functionality as can be seen further below.

Test if the device TIAO USB Multi-Protocol Adapter is properly recognized with libftdi with the find_all_pp tool, which is in ../build/examples:

./find_all_pp -v 0x0403 -p 0x8a98
Found devices ( VID: 0x403, PID: 0x8a98 )
------------------------------------------------
FTDI (0x86984b8): , ,  (Open FAILED)

If it throws “Open FAILED”, then it has probably a missing udev rule, giving this device the correct rights. Verify if this is the case with trying the same with sudo:

sudo ./find_all_pp -v 0x0403 -p 0x8a98
Found devices ( VID: 0x403, PID: 0x8a98 )
------------------------------------------------
FTDI (0x92927c8): TIAO, TIAO USB Multi-Protocol Adapter, TIVYLJQO (Open OK)

This looks OK. To use this device without the sudo command create an udev rule. See below for more information.

### OpenMoko Debug Board for Neo1973

Test if the OpenMoko Debug Board for Neo1973 is properly recognized with libftdi with the find_all_pp tool, which is in ../build/examples:

./find_all_pp -v 0x1457 -p 0x5118

## Intermezzo: Modifying find_all_pp

The find_all_pp tool will without arguments according to this page not find the OpenMoko debug board. To correct this, change the file at this location:

~/devel/libftdi/libftdi/examples/examples/find_all_pp.cpp

the line beginning with this:

  int vid = 0x0403, pid = 0x6010, tmp = 0;

into:

  int vid = 0x1457, pid = 0x5118, tmp = 0;

Rename this file into: find_all_pp2
Then make this with following line:

gcc -o find_all_pp2 ~/devel/libftdi/libftdi/examples/examples/find_all_pp2.cpp \$(pkg-config --cflags --libs libftdipp1)

Please note a difference for pkg-config between c programs and c++ programs. For c programs libftdi1 is used and for c++ programs lbftdipp1

## Intermezzo: JTAG clk signal integrity observations

After realizing the JTAG clk signal was in the order of 30MHz, the signal integrity in terms of transmission line properties became significant. Reflections on improper terminated cable ends as well as wrong cable impedance would have influence on the signal integrity. To be able to perform measurements on the signal, following changes were made to the TIAO JTAG interface board:

• Pin 47 of the 74LVC16T245 had been isolated from the FT2232HL.
• A separate square wave signal of 5.5 MHz, Vpp of 3.3 V, with a 50 Ohm termination close to this pins had been fed into this IC.
• The signal ground was attached to pin 45.

In documentation about the output characteristics2) of the LVC16 family, to which the 74LVC16T245 buffer IC belongs, the output impedance is about 15 Ohm. Rather than the previously used separate wires, a 1/20 inch flat cable was taken with following specifications:

• Belden AWM 2651 See 7.5, characteristic impedance of 105 Ohm, Ground-Signal-Ground configuration. Total cable length: 20cm.

The flat cable was taken from an old computer diskette drive. It was not 100% clear whether the specifications from belden.com applied actually to this cable. Initially I thought the characteristic impedance was 90 Ohm. With channel 1 showing the buffer input signal and channel 2 showing the cable end, measurements show the following:

RS=97 Ohm
Termination: 100 Ohm
Signal source cable: 0.5m
RS=97 Ohm
No termination
Signal source cable: 0.5m
RS=97 Ohm
Termination: 90 Ohm
Signal source cable: 0.5m
RS=90 Ohm
Termination 90 Ohm
Signal source cable: 1m

Where RS is the sum of the output impedance and the series resistor at the output of the buffer IC.

Being unsure about the impedance of the flat cable, I tried driving the cable additionally with 105 Ohm (With and without taking into account the 15 Ohm internal buffer resistance) and 105 Ohm termination.

RS=120 Ohm
Termination: 105 Ohm
Signal source cable: 1m
RS=105 Ohm
Termination: 105 Ohm
Signal source cable: 1m
RS=105 Ohm
Termination: 105 Ohm
Signal source cable: 1m
RS=105 Ohm
AC termination: 105 Ohm + 120pF
Signal source cable: 1m

Interestingly, from the initial attempt to measure signal reflection, by analyzing the images, my attention fell on two things:

• The buffer output signal becomes shortly negative when the waveform returns to zero. This behavior can be seen as well at the input signal. The effects are very small when the termination is open. I think the 105 Ohm load is so relatively large, that it draws a lot of current from the buffer power supply, causing the ground plane around the buffer IC to become shortly negative when the waveform returns to zero.
• The propagation delay (round trip travel time) through 20cm of cable is about 2ns (5ns/m, 2 x 20cm)3). If a reflection occurs, it is expected this would become visible in the output signal. The images above don't make this really clearer, because the supply power problem as described above has a much larger effect.
• The output impedance of the buffer including the series resistor (Which is together 105 Ohm) cancels all bounced reflections.

After realizing the buffer output impedance cancels the bounced reflections, I measured the signal with no termination. The result looks fine and should be according to the waveform sufficient to control the memory device. The signal looks like this:

RS=105 Ohm
No termination
Signal source cable: 1m

When compared to the second image which had a 97 Ohm output impedance, the square waveform has less disturbances and enables faster rise times. Two changes may have contributed to this:

• A corrected total buffer output impedance of 105 Ohm, matched the cable impedance. The default 56 Ohm resistor after the buffered output was replaced by another resistor. Together with the buffer internal resistance, 15 Ohm, this makes a total output resistance of 105 Ohm. This means a resistor of 90 Ohm (I selected 100 Ohm parallel with 910 Ohm) should be the correct value.
• An additional capacitor at the bottom of the circuit board, at the via to pin 7, Vccb, buffers the input power supply. I had to scratch some of the ground plane away, making space for a capacitor. This had to be done careful, because other vias are at near distance. For the capacitor I selected a value of 10 uF.

After the modifications I measured the clk signal from the FTDI2232H, going via the buffer:

Real clk signal
RS=105 Ohm
No termination
JTAG cable length: 20cm

The LVC16T245 buffer is causing a delay of about 6ns for the CLK signal.

1)
This is probably not necessary, since the procedure to install the build tools was not properly followed. If properly followed, issue all commands one by one instead of all apt-get install packages in one line. Then manually installing linux-libc-dev_3.5.0-24.37_i386 and ruby etc. is probably not necessary.
4)
udevinfo is in ubuntu udevadm. Test for example with:
info -q all -n /dev/ttyUSB0
udevadm info -q all -n /dev/bus/usb/002/003