User Tools

Site Tools


software:linux:jtag

Using ftdi 2232 with linux

Install drivers for the ftdi device from here:

cd ~/Downloads
wget http://www.intra2net.com/en/developer/libftdi/download/libftdi1-1.0.tar.bz2
tar xjf libftdi1-1.0.tar.bz2
cd libftdi1-1.0

Read the README.build, install build tools:

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
  404  Not Found [IP: 130.239.18.137 80]
...
Err http://no.archive.ubuntu.com/ubuntu/ quantal-updates/main libruby1.9.1 i386 1.9.3.194-1ubuntu1.2
  404  Not Found [IP: 130.239.18.137 80]
Err http://security.ubuntu.com/ubuntu/ quantal-security/main libruby1.9.1 i386 1.9.3.194-1ubuntu1.2
  404  Not Found [IP: 91.189.92.200 80]
...
Err http://no.archive.ubuntu.com/ubuntu/ quantal-updates/main ruby1.9.1 i386 1.9.3.194-1ubuntu1.2
  404  Not Found [IP: 130.239.18.137 80]
...
Err http://security.ubuntu.com/ubuntu/ quantal-security/main ruby1.9.1 i386 1.9.3.194-1ubuntu1.2
  404  Not Found [IP: 91.189.91.13 80]
...
Failed to fetch http://no.archive.ubuntu.com/ubuntu/pool/main/l/linux/linux-libc-dev_3.5.0-24.37_i386.deb  404  Not Found [IP: 130.239.18.137 80]
Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/r/ruby1.9.1/libruby1.9.1_1.9.3.194-1ubuntu1.2_i386.deb  404  Not Found [IP: 91.189.92.200 80]
Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/r/ruby1.9.1/ruby1.9.1_1.9.3.194-1ubuntu1.2_i386.deb  404  Not Found [IP: 91.189.91.13 80]
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.

TIAO USB Multi-Protocol Adapter

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
[sudo] password for fida: 
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
fida@bona:~/devel/libftdi/libftdi/build/examples$ ./find_all_pp -v 0x1457 -p 0x5118
Found devices ( VID: 0x1457, PID: 0x5118 )
------------------------------------------------
FTDI (0x9da3420): , ,  (Open FAILED)

If it throws “Open FAILED”, try the same with sudo:

sudo ./find_all_pp -v 0x1457 -p 0x5118
[sudo] password for fida: 
Found devices ( VID: 0x1457, PID: 0x5118 )
------------------------------------------------
FTDI (0xa00f420): , ,  (Open FAILED)

The open FAILED error still appears with using sudo. To find out why this behaves differently, test it with lsusb to see if a clue can be found:

sudo lsusb
Bus 002 Device 005: ID 1457:5118 First International Computer, Inc. OpenMoko Neo1973 Debug board (V2+)

The format for verbose information from lsusb is: sudo lsusb -v -s [BUS_NUMBER]:[DEVICE_NUMBER], which is in this case:

sudo lsusb -v -s 002:005

Gives:

Click to display ⇲

Click to hide ⇱

Bus 002 Device 005: ID 1457:5118 First International Computer, Inc. OpenMoko Neo1973 Debug board (V2+)
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         8
  idVendor           0x1457 First International Computer, Inc.
  idProduct          0x5118 OpenMoko Neo1973 Debug board (V2+)
  bcdDevice            5.00
  iManufacturer           1 OpenMoko
  iProduct                2 Debug Board for Neo1973
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           55
    bNumInterfaces          2
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              2 Debug Board for Neo1973
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              2 Debug Board for Neo1973
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x04  EP 4 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
Device Status:     0x0000
  (Bus Powered)

Further reading about the OpenMoko Debug Board v3, states that the ftdi_sio module should be removed from the linux kernel and then added with specifying the vendor-id and product-id.:

rmmod ftdi_sio
modprobe ftdi_sio vendor=0x1457 product=0x5118

or the equivalent in your modules.conf.

Usage without sudo: udev rules

If you read with the find_all_pp program the following (or similar) output with the Open FAILED text:

Found devices ( VID: 0x403, PID: 0x6010 )
...
FTDI (0x86984b8): , ,  (Open FAILED)

then give the ftdi device elevated rights with adding an udev rule. Look here or here for examples. Also here for reference to a plugdev group. Apparently a user should be member to that group.
Find which groups there are with the following command:

groups

Which shows in my case:

aida adm cdrom sudo dip plugdev lpadmin sambashare

After changing udev rules, reinitialize them with the following command:

sudo udevadm control --reload-rules

About udev rules, mind the following: In the original udev rule on openmoko.org the rule contained the meanwhile outdated SYSFS attribute. This will not work anymore and gives an error during troubleshooting the rule. Changing the SYSFS attribute into ATTR attribute is sufficient to make it work.

OpenMoko debug board udev rule

For the OpenMoko debug board this is: /etc/udev/rules.d/099_neo1973_debugboard.rules

# udev rules file for Neo1973 Debug Board v2
#
 
ACTION!="add", GOTO="neo1973_dbg_rules_end"
SUBSYSTEM!="usb", GOTO="neo1973_dbg_rules_end"
 
ATTR{idVendor}=="1457", ATTR{idProduct}=="5118", MODE="664", GROUP="plugdev"
 
LABEL="neo1973_dbg_rules_end"

TIAO USB Multi Protocol adapter udev rule

For the TIAO USB Multi Protocol adapter this is: /etc/udev/rules.d/098_tiao_usb_multi_protocol_adapter.rules

# udev rules file for TIAO USB Multi Protocol adapter 
#
 
ACTION!="add", GOTO="tiao_usb_multi_protocol_interface_end"
SUBSYSTEM!="usb", GOTO="tiao_usb_multi_protocol_interface_end"
 
ATTR{idVendor}=="0403", ATTR{idProduct}=="8a98", MODE="664", GROUP="plugdev"
 
LABEL="tiao_usb_multi_protocol_interface_end"

Testing ttyUSB*

When trying the serial port with cu, it may throw a “Line in use” at you:

sudo cu -eo -s 115200 -l /dev/ttyUSB0
cu: open (/dev/ttyUSB0): Permission denied
cu: /dev/ttyUSB0: Line in use

A solution for this is to assign ttyUSB0 to the uucp group:

sudo chown uucp /dev/ttyUSB0

Then cu will work. To exit from a cu session, type the following: ~.

To send or receive a file via the /dev/ttyUSB0, it must be writable. Change this accordingly:

sudo chmod 666 /dev/ttyUSB0

Activity on the TxD pin can be measured at the TIAO USB Multi-Protocol Adapter when issuing this command:

sudo cat testfile.txt > /dev/ttyUSB0

The OpenMoko Debug board fails here. No activity can be seen on the TxD line. The command on the terminal seems to hang.

Testing JTAG with flash memory

An easy method to make a connection to the flash memory, which is in a 16-pin SOIC 300-mil housing, to the JTAG interface is to solder the corner points to a solid pin and use thin wires to connect to the other IC legs:

adapter to DIP

See further below for pinout from the flash memory to the corresponding JTAG interface.

apt-get installation of flashrom

With flashrom the JTAG interface is tested while being connected to flash memory. Install flashrom either with apt-get or manually (see further below).

sudo apt-get install flashrom

Manual installation of flashrom

flashrom installation depends on subversion, libftdi (has been installed already) and libftdi-dev (to be installed with sudo apt-get install libftdi-dev) to have support for ft2232_spi devices. Once installed, do:

  mkdir -p ~/devel/
  cd ~/devel
  svn co svn://flashrom.org/flashrom/trunk flashrom
  cd flashrom
  make
  sudo make install

OpenMoko JTAG

With using the OpenMoko Debug board wire the flash memory as explained here to the OpenMoko JTAG port. Connections are: (pin-OpenMoko,pin-W25Q128)

  • 1-VCC3→2-VCC NB. pin 2 at the flash memory is also connected to pin 1 (/hold) and pin 9 (/WP)
  • 5-TDI→15-DI
  • 7-TMS→7-/CS
  • 9-TCK→16-CLK
  • 13-TDO→8-DO
OpenMoko with flash eeprom

Then issue the following command:

./flashrom -p ft2232_spi:type=openmoko

This should communicate with the flash memory. If it would be reading the actual memory this may take a while for large memories:

flashrom v0.9.6.1-r1657 on Linux 3.5.0-25-generic (i686)
flashrom is free software, get the source code at http://www.flashrom.org
 
Calibrating delay loop... OK.
Found Winbond flash chip "W25Q128" (16384 kB, SPI) on ft2232_spi.
 
This flash part has status UNTESTED for operations: READ ERASE WRITE
The test status of this chip may have been updated in the latest development
version of flashrom. If you are running the latest development version,
please email a report to flashrom@flashrom.org if any of the above operations
work correctly for you with this flash part. Please include the flashrom
output with the additional -V option for all operations you tested (-V, -Vr,
-VE, -Vw), and mention which mainboard or programmer you tested.
Please mention your board in the subject line. Thanks for your help!
No operations were specified.

TIAO USB Multi Protocol adapter JTAG

The 20PIN ARM JTAG connector does not work in the same way as it does for the OpenMoko JTAG connector. One of the differences is that pin 1, VTAR should be supplied from an external power supply at 3.3v. Jumper VT-SEL should be set to position 2-3, to enable this power to the buffer IC. Furthermore, using flashrom with the following command should use this default port A:

flashrom -p ft2232_spi:type=tumpa

Unfortunately the output of this shows no success as it does at the OpenMoko board:

Found Generic flash chip "unknown SPI chip (RDID)" (0 kB, SPI).

Instead use SPI2 at the TIAO tumpa board, which is mapped to port B. This works fine. Connections are:

SPI2 EEPROM
MISO DO
VCC VCC+/HOLD+/WP
SCK CLK
MOSI DI
CS /CS
GND GND
TIAO adapter with flash eeprom

And using this command:

./flashrom -p ft2232_spi:type=tumpa,port=B

will show the same result from OpenMoko:

...
Found Winbond flash chip "W25Q128" (16384 kB, SPI) on ft2232_spi.
...

Since the only difference between port A and port B is that port A has a 74LVC16T245 buffer IC driving the signals MOSI, CLK and CS via a 56 Ohm resistor, I started bypassing this buffer IC and tested if port A could behave like port B. I noticed then that for proper communication the only signal that had to be bypassed was the CLK signal. By connecting CLK directly to pin 16 (TCLK) of the FT2232HL, the communication worked fine. But as soon as the CLK signal would go via the buffer IC, the CLK output (LVC16T245, pin 2) signal would be degraded to such an extend that communication with the memory chip could not be established properly. After this I understood there is nothing wrong with the TIAO JTAG board.nor with the drivers. The root cause for this is a mismatch between the output impedance of the JTAG board and the relatively long (>20cm) cables. This effect plays a substantial role at high frequency signals, which this interface is running at. I measured a CLK signal of 30Mhz. A simple solution is to shorten the cables. Instead of 20cm I strongly advise to use not more than 10cm.
As an alternative, one could try to match the output impedance of the JTAG board by adding a resistor at the MOSI, CLK and CS signals of the memory IC, presuming the cable impedance has a identical value. There are several effects which cause the delay of the CLK signal. The buffer IC gives a delay of about 4ns, the 56 Ohm resistor causes a less steep transition and an extra signal delay through 20cm cable of about 1ns. This all must be taken into account.
Another good explanation and design guidelines for (ac) termination and cabling can be found here.

Lowering the bus frequency, resulted in successful communication. This is clearly a hint that there are issues with signal integrity. With the following command there is success:

./flashrom -p ft2232_spi:divisor=4,type=tumpa,port=A

The frequency of the CLK signal lowered, but not as expected. According to Application Note 135, MPSSE Basics of the FTDI documentation the frequency can be set with the following formula:

frequency = 60MHz /((1 + divisor)*2)

The divisor is a 16-bit hex value between 0x0000 and 0xFFFF and represent the amount of 2 divisors which are chained. With a 60Mhz base clock, data rates range between 30MHz and ~460Hz and applies to the FT2232H, according to page 9 of AN 135. This formule will give the 16-bit divisor:

dwClockDivisor=(30000000/SCL_Frequency) - 1; // With SCL_Frequency in Hz. For example, an SCL_Frequency of 1 MHz will give a dwClockDivisor of 29.

And code in Application note 114, page 7 and 8 to set the registers:

...
OutputBuffer[dwNumBytesToSend++] = '\x86'; //Command to set clock divisor
OutputBuffer[dwNumBytesToSend++] = BYTE(dwClockDivisor & '\xFF'); //Set 0xValueL of clock divisor
OutputBuffer[dwNumBytesToSend++] = BYTE(dwClockDivisor >> 8); //Set 0xValueH of clock divisor
ftStatus = FT_Write(ftHandle, OutputBuffer, dwNumBytesToSend, &dwNumBytesSent); // Send out the commands
dwNumBytesToSend = 0; //Clear output buffer
...

This is rather confusing implemented in flashrom since May 16th 2012. Measurements when using divisor=2 or with no divisor arguments, show a CLK signal of 30 MHz (The comments in the code say 2 is a default value). The code seems differently written than FTDI did.

To make measurements easier one can use the following one-liner, which repeats the command and activity on the bus. With this it is easier to analyze the cabling, termination and buffer circuit:

cd $HOME/devel/flashrom; while true; do ./flashrom -p ft2232_spi:divisor=4,type=tumpa,port=A; done

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=82, RL=100 RS=82, RL=∞ RS=82, RL=90 RS=75, RL=90
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=105, RL=105 RS=90, RL=105 RS=90, RL=105 RS=90, RL=105
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
Vccb Buffer IC: 10uF additional
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, RL=∞
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:

RS=105, RL=∞
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
software/linux/jtag.txt · Last modified: 2015/10/11 20:03 by admin