Debug Board v3

From Openmoko

(Difference between revisions)
Jump to: navigation, search
m (Added note about SUBSYSTEM change (usb_device->usb) for udev rule. TODO: upload newer udev rule)
(http://www.oocdlink.com is back again)
 
(15 intermediate revisions by 11 users not shown)
Line 1: Line 1:
 +
{{Languages|Debug Board v3}}
 +
 
{{Dboard}}
 
{{Dboard}}
  
 
[[Image:Neo1973 debugboard v3 top.jpg|thumb|Debug Board v3, PCB photograph]]
 
[[Image:Neo1973 debugboard v3 top.jpg|thumb|Debug Board v3, PCB photograph]]
  
The Debug Board v3 is the most recent version of the Debug Board for [[Neo 1973]] and [[Neo FreeRunner]]. It is sold seperately from the phones.  
+
The Debug Board v3 is the most recent version of the Debug Board for [[Neo 1973]] and [[Neo FreeRunner]]. It is sold seperately from the phones.
  
 
You need the debug board to have a serial console and for JTAG.
 
You need the debug board to have a serial console and for JTAG.
Line 12: Line 14:
 
* use JTAG to halt the processor anytime and analyze the system state (this can also be used with the gdb debugger)
 
* use JTAG to halt the processor anytime and analyze the system state (this can also be used with the gdb debugger)
  
* enable write access to the NOR
+
* enable write access to the [[NOR Flash|NOR]]
  
 
Serial console and JTAG are very useful (actually, indispensable) for kernel debugging.
 
Serial console and JTAG are very useful (actually, indispensable) for kernel debugging.
Line 25: Line 27:
 
* [[Debug Board#JTAG using FT2232 | JTAG using FT2232]]
 
* [[Debug Board#JTAG using FT2232 | JTAG using FT2232]]
 
* [[Debug Board#Serial Port | Serial Port]]
 
* [[Debug Board#Serial Port | Serial Port]]
 +
 +
=== Schematics ===
 +
 +
The Schematics of this board can be found at http://people.openmoko.org/joerg/schematics/debug_board/OpenMoKo_Debug_Board_V3_MP.pdf
  
 
=== USB Hub ===
 
=== USB Hub ===
  
This bus-powered hub  
+
This bus-powered hub
 
* attaches to the laptop using its upstream port
 
* attaches to the laptop using its upstream port
 
* attaches to the FT2232D for JTAG and serial console on downstream port 1
 
* attaches to the FT2232D for JTAG and serial console on downstream port 1
Line 36: Line 42:
 
Using the hub, you can have access to the phone, JTAG and serial simultaneously, through a single USB cable.
 
Using the hub, you can have access to the phone, JTAG and serial simultaneously, through a single USB cable.
  
You can actually even charge the phone (100mA slow charge) using that downstream port.
+
You can charge the phone (100mA slow charge) using that downstream port.
  
For the ISB hub function, we use the TUSB2046B chip.
+
For the USB hub function, we use the TUSB2046B chip.
  
 
=== JTAG using FT2232 ===
 
=== JTAG using FT2232 ===
  
Basically, we integrate a USB-JTAG adaptor similar to the [Amontec JTAGkey-tiny].  The actual reference design that we used (Thanks to Joern!) can be found at http://www.oocdlink.com
+
Basically, we integrate a USB-JTAG adaptor similar to the [Amontec JTAGkey-tiny].  The actual reference design that we used (Thanks to Joern!) was found at http://www.oocdlink.com.
  
 
This provides us full JTAG debugging, at about 150times the speed of the [[wiggler]]
 
This provides us full JTAG debugging, at about 150times the speed of the [[wiggler]]
Line 49: Line 55:
 
* the phone (via debug flex cable)
 
* the phone (via debug flex cable)
 
* A separate 20-pin header using standard ARM-JTAG pinout
 
* A separate 20-pin header using standard ARM-JTAG pinout
** this allows the user to use this device as JTAG adaptor even for other arm-based devices
+
** Allows users to use this device as JTAG adaptor for other arm-based devices
  
 
=== Serial Port ===
 
=== Serial Port ===
  
 
Instead of replicating a true RS232 port, we wanted to use a USB serial converter chip,
 
Instead of replicating a true RS232 port, we wanted to use a USB serial converter chip,
such as the FT232 or the PL2303.  
+
such as the FT232 or the PL2303.
  
 
As it turns out, we can even use the second port of the FT2232 simultaneously with the JTAG.  So no extra FT232 or PL2303 is required.
 
As it turns out, we can even use the second port of the FT2232 simultaneously with the JTAG.  So no extra FT232 or PL2303 is required.
Line 79: Line 85:
 
{{note|FIC has done that for you, in case you have officially been supplied with the board.  However, if you are one of the early adopters, the configuration and USB vendorID / productID might have not yet been set correctly.}}
 
{{note|FIC has done that for you, in case you have officially been supplied with the board.  However, if you are one of the early adopters, the configuration and USB vendorID / productID might have not yet been set correctly.}}
  
In order to do so, you can use the ftdi_eeprom program from  
+
In order to do so, you can use the ftdi_eeprom program from
 
http://www.intra2net.com/de/produkte/opensource/ftdi/. Unfortunately, the latest version (0.2) doesn't yet contain support for our FT2232D, so you need the patch from http://people.openmoko.org/laforge/misc/debug_board_v2/ftdi_eeprom/ftdi_eeprom-0.2-moko.patch
 
http://www.intra2net.com/de/produkte/opensource/ftdi/. Unfortunately, the latest version (0.2) doesn't yet contain support for our FT2232D, so you need the patch from http://people.openmoko.org/laforge/misc/debug_board_v2/ftdi_eeprom/ftdi_eeprom-0.2-moko.patch
  
Line 90: Line 96:
  
 
Once you have compiled ftdi_eeprom, you can run
 
Once you have compiled ftdi_eeprom, you can run
ftdi_eeprom --flash-eeprom neo1973_debug_board_v2.ftdi
+
ftdi_eeprom --flash-eeprom neo1973_debug_board_v2.ftdi
  
 
{{warning|Make sure you don't have any other FTDI FT232 / FT2232 based devices attached to the USB while running ftdi_eeprom.  It might be wise to disconnect everything but the debug board}}
 
{{warning|Make sure you don't have any other FTDI FT232 / FT2232 based devices attached to the USB while running ftdi_eeprom.  It might be wise to disconnect everything but the debug board}}
Line 109: Line 115:
 
Once the flashing has finished, just disconnect and reconnect, and you should see
 
Once the flashing has finished, just disconnect and reconnect, and you should see
 
<pre>
 
<pre>
$ lsusb -v -d 0x1457:                                                                                                                                                                                              
+
$ lsusb -v -d 0x1457:
Bus 005 Device 009: ID 1457:5118
+
Bus 005 Device 009: ID 1457:5118
 
Device Descriptor:
 
Device Descriptor:
  bLength                18
+
bLength                18
  bDescriptorType        1
+
bDescriptorType        1
  bcdUSB              2.00
+
bcdUSB              2.00
  bDeviceClass            0 (Defined at Interface level)
+
bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass        0  
+
bDeviceSubClass        0
  bDeviceProtocol        0  
+
bDeviceProtocol        0
  bMaxPacketSize0        8
+
bMaxPacketSize0        8
  idVendor          0x1457  
+
idVendor          0x1457
  idProduct          0x5118  
+
idProduct          0x5118
  bcdDevice            5.00
+
bcdDevice            5.00
  iManufacturer          1 OpenMoko
+
iManufacturer          1 Openmoko
  iProduct                2 Debug Board for Neo1973
+
iProduct                2 Debug Board for Neo1973
  iSerial                0  
+
iSerial                0
  bNumConfigurations      1
+
bNumConfigurations      1
  [...]
+
[...]
 
</pre>
 
</pre>
  
Line 133: Line 139:
  
 
In order to do so, you can use the FTDI Mprog program from http://www.ftdichip.com/Resources/Utilities/MProg3.0_Setup.exe
 
In order to do so, you can use the FTDI Mprog program from http://www.ftdichip.com/Resources/Utilities/MProg3.0_Setup.exe
+
 
 
You will need
 
You will need
 
* The EEPROM Template http://people.openmoko.org/laforge/misc/debug_board_v2/mprog_template/neo1973_debugboard_v2.ept
 
* The EEPROM Template http://people.openmoko.org/laforge/misc/debug_board_v2/mprog_template/neo1973_debugboard_v2.ept
Line 147: Line 153:
 
====== ftdi_sio module option ======
 
====== ftdi_sio module option ======
  
rmmod ftdi_sio
+
rmmod ftdi_sio
modprobe ftdi_sio vendor=0x1457 product=0x5118
+
 
 +
modprobe ftdi_sio vendor=0x1457 product=0x5118
  
 
or the equivalent in your modules.conf
 
or the equivalent in your modules.conf
Line 166: Line 173:
 
* [[Connecting Neo1973 with Debug Board v2]] (shows how to connect the FPC)
 
* [[Connecting Neo1973 with Debug Board v2]] (shows how to connect the FPC)
  
The recommended connection sequence given in [[Debug Board v2#Hardware connection]] may not work for debug board v3 and the Freerunner. It seems impossible to turn on the Freerunner after plugging the Freerunner USB cable into the PC, but before plugging the debug board USB cable into the PC. After the debug board is powered by the PC, the Freerunner should start.
+
The recommended connection sequence given in [[Debug Board v2#Hardware connection]] may not work for debug board v3 and the FreeRunner. It seems impossible to turn on the FreeRunner after plugging the FreeRunner USB cable into the PC, but before plugging the debug board USB cable into the PC. After the debug board is powered by the PC, the FreeRunner should start.
 +
 
 +
=== Suggestions ===
 +
 
 +
* [[User:Cfriedt]] 20081021 The Debug Board v3 uses 3.3V signalling levels on J1 (the 20-pin ARM JTAG port). Many other ARM devices use 1.8V signalling. For the next Dboard hardware revision, I would suggest using the same level-shifter as the FlySwatter. The FlySwatter uses two SN74AVC4T245 ([http://elinux.org/upload/4/46/Flyswatter-schematic.pdf ref]) buffers to provide a signalling range of 1.2V to 3.6V ([http://elinux.org/Flyswatter ref]).
  
 
=== Actually using it ===
 
=== Actually using it ===
Line 174: Line 185:
 
===== Serial Port =====
 
===== Serial Port =====
  
The Linux kernel of your host system will create a virtual serial device called '''/dev/ttyUSBx''' where 'x' is a sequentially assigned number.  If you don't have any other USB serial converters attached to your machine, the device name will be '''/dev/ttyUSB0'''.
+
The Linux kernel of your host system will create a virtual serial device called '''/dev/ttyUSBx''' where 'x' is a sequentially assigned number.  If you don't have any other USB serial converters attached to your machine, the device name will be '''/dev/ttyUSB1'''
 +
(baud rate 115200 8N1).
  
 
You can use your favourite terminal emualtor (minicom, cu, zc, ...) just like for any other/real serial port. You may use gdb as well (eg. target remote /dev/ttya).
 
You can use your favourite terminal emualtor (minicom, cu, zc, ...) just like for any other/real serial port. You may use gdb as well (eg. target remote /dev/ttya).
Line 214: Line 226:
 
<span id="bottom"></span>
 
<span id="bottom"></span>
  
[[Category:Hardware]]
+
[[Category:Debug Board]]
 
[[Category:Neo1973 Hardware]]
 
[[Category:Neo1973 Hardware]]
 
[[Category:Neo1973 Hardware Debugging]]
 
[[Category:Neo1973 Hardware Debugging]]
 +
[[Category:Neo FreeRunner Hardware]]

Latest revision as of 12:13, 25 July 2010


Debug Board


Debug Board v3, PCB photograph

The Debug Board v3 is the most recent version of the Debug Board for Neo 1973 and Neo FreeRunner. It is sold seperately from the phones.

You need the debug board to have a serial console and for JTAG. The debug board lets you:

  • access the serial console, to get kernel debug messages the moment the respective events occur (or to get the kernel's last words when it crashes hard)
  • use JTAG to halt the processor anytime and analyze the system state (this can also be used with the gdb debugger)
  • enable write access to the NOR

Serial console and JTAG are very useful (actually, indispensable) for kernel debugging.

Contents

[edit] Overview

Architecture Diagram

The debug board provides these key components.

[edit] Schematics

The Schematics of this board can be found at http://people.openmoko.org/joerg/schematics/debug_board/OpenMoKo_Debug_Board_V3_MP.pdf

[edit] USB Hub

This bus-powered hub

  • attaches to the laptop using its upstream port
  • attaches to the FT2232D for JTAG and serial console on downstream port 1
  • attaches to a free USB-A connector using downstream port 2
  • attaches to the phone using downstream port 3

Using the hub, you can have access to the phone, JTAG and serial simultaneously, through a single USB cable.

You can charge the phone (100mA slow charge) using that downstream port.

For the USB hub function, we use the TUSB2046B chip.

[edit] JTAG using FT2232

Basically, we integrate a USB-JTAG adaptor similar to the [Amontec JTAGkey-tiny]. The actual reference design that we used (Thanks to Joern!) was found at http://www.oocdlink.com.

This provides us full JTAG debugging, at about 150times the speed of the wiggler

The actual JTAG port is connected with

  • the phone (via debug flex cable)
  • A separate 20-pin header using standard ARM-JTAG pinout
    • Allows users to use this device as JTAG adaptor for other arm-based devices

[edit] Serial Port

Instead of replicating a true RS232 port, we wanted to use a USB serial converter chip, such as the FT232 or the PL2303.

As it turns out, we can even use the second port of the FT2232 simultaneously with the JTAG. So no extra FT232 or PL2303 is required.

[edit] Tri-State Serial Port

On GTA01 the CPU UART serial port needed a multiplexer formed by a tri-state driver, since it was both connected to the GSM modem AND to the debug board. We drive the GTA01-tri-state driver mux by an inverted GSM_EN signal (pin 7 on FPC connector). For GTA02 the console serial port isn't multiplexed and connects directly to CPU UART.

[edit] Usage Instructions

[edit] Preconditions

[edit] FT2232D EEPROM

Your Debug Board contains a small serial EEPROM which should be flashed correctly during production. However, some boards have received incorrect/incomplete programming during production and thus you should verify this.

If the board shows up as USB ID 1457:5118, then everything is correct.

Only if your board shows up as USB ID 0403:6010, then you will need to flash the board!

[edit] Flashing with Linux
NOTE: FIC has done that for you, in case you have officially been supplied with the board. However, if you are one of the early adopters, the configuration and USB vendorID / productID might have not yet been set correctly.


In order to do so, you can use the ftdi_eeprom program from http://www.intra2net.com/de/produkte/opensource/ftdi/. Unfortunately, the latest version (0.2) doesn't yet contain support for our FT2232D, so you need the patch from http://people.openmoko.org/laforge/misc/debug_board_v2/ftdi_eeprom/ftdi_eeprom-0.2-moko.patch

You may also need to apply the following patch to libftdi: http://people.openmoko.org/werner/libftdi-c56-strings-dirty-hack.patch (See http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=321 for additional details.)

Furthermore, you will need the EEPROM config: http://people.openmoko.org/laforge/misc/debug_board_v2/ftdi_eeprom/neo1973_debug_board_v2.ftdi

Once you have compiled ftdi_eeprom, you can run ftdi_eeprom --flash-eeprom neo1973_debug_board_v2.ftdi

WARNING: Make sure you don't have any other FTDI FT232 / FT2232 based devices attached to the USB while running ftdi_eeprom. It might be wise to disconnect everything but the debug board


You should get something like the following printout if everything was successful:

FTDI eeprom generator v0.2
(c) Intra2net AG <opensource@intra2net.com>
FTDI init: 0
Unable to find FTDI devices under given vendor/product id: 0x1457/0x5118
Retrying with default FTDI id.
Used eeprom space: 102 bytes
FTDI write eeprom: 0
Writing to file: neo1973_debug_board_v2.eeprom
FTDI close: 0

Once the flashing has finished, just disconnect and reconnect, and you should see

$ lsusb -v -d 0x1457:
Bus 005 Device 009: ID 1457:5118
Device Descriptor:
bLength                18
bDescriptorType         1
bcdUSB               2.00
bDeviceClass            0 (Defined at Interface level)
bDeviceSubClass         0
bDeviceProtocol         0
bMaxPacketSize0         8
idVendor           0x1457
idProduct          0x5118
bcdDevice            5.00
iManufacturer           1 Openmoko
iProduct                2 Debug Board for Neo1973
iSerial                 0
bNumConfigurations      1
[...]
[edit] Flashing with Windows
NOTE: FIC has done that for you, in case you have officially been supplied with the board. However, if you are one of the early adopters, the configuration and USB vendorID / productID might have not yet been set correctly.


In order to do so, you can use the FTDI Mprog program from http://www.ftdichip.com/Resources/Utilities/MProg3.0_Setup.exe

You will need

[edit] Drivers

[edit] Linux

Please make sure you have libftdi-0.8 or later. Earlier versions are known to cause problems

Furthermore, you will need to do the following:

[edit] ftdi_sio module option

rmmod ftdi_sio

modprobe ftdi_sio vendor=0x1457 product=0x5118

or the equivalent in your modules.conf

[edit] udev rule

Please install the rules from http://people.openmoko.org/laforge/misc/debug_board_v2/udev_rules/

NOTE: Some distros no longer name their USB subsystem usb_device, but uses simply usb instead (e.g. Ubuntu 8.x). If so, you should change the line with SUBSYSTEM accordingly, otherwise the device will not be recognized by the udev rule.


[edit] Windows

Please use the driver from http://people.openmoko.org/laforge/misc/debug_board_v2/windows_drivers/

[edit] Hardware connection

The recommended connection sequence given in Debug Board v2#Hardware connection may not work for debug board v3 and the FreeRunner. It seems impossible to turn on the FreeRunner after plugging the FreeRunner USB cable into the PC, but before plugging the debug board USB cable into the PC. After the debug board is powered by the PC, the FreeRunner should start.

[edit] Suggestions

  • User:Cfriedt 20081021 The Debug Board v3 uses 3.3V signalling levels on J1 (the 20-pin ARM JTAG port). Many other ARM devices use 1.8V signalling. For the next Dboard hardware revision, I would suggest using the same level-shifter as the FlySwatter. The FlySwatter uses two SN74AVC4T245 (ref) buffers to provide a signalling range of 1.2V to 3.6V (ref).

[edit] Actually using it

[edit] On Linux

[edit] Serial Port

The Linux kernel of your host system will create a virtual serial device called /dev/ttyUSBx where 'x' is a sequentially assigned number. If you don't have any other USB serial converters attached to your machine, the device name will be /dev/ttyUSB1 (baud rate 115200 8N1).

You can use your favourite terminal emualtor (minicom, cu, zc, ...) just like for any other/real serial port. You may use gdb as well (eg. target remote /dev/ttya).

[edit] JTAG

Once you have installed libftdi >= 0.8 and configured OpenOCD with the correct openocd.cfg from OpenOCD#openocd.cfg, it should work just fine.

Please see OpenOCD#OpenOCD_and_Debug_Board for some more information.

[edit] History

We previously had Neo1973 Debug Board v1 (inherited from some weird engineers who must have seen Brazil too often). Version 1 was never shipped to phase-0 or phaes-1, and not sold to anyone.

[edit] Changes from v2 to v3

  • drastically reduce the effective load capacitance on the upstream USB port
  • use a load-limiting 3V LDO to further ensure USB spec electrical compliance
  • add a new 10pin header [footprint] to make the I2C/SPI/IRQ pins of the GTA01/GTA02 debug connector accessible
  • rotate the 20pin ARM-JTAG connector to be able to use standard 90degree-angled sockets
  • give LED's and connectors proper names on the silk
  • add openmoko logo to the bottom silk screen


[edit] Changes from v1 to v2

  • get rid of ethernet
    • we don't need it, and
    • we especially don't want a 40pin parallel 66MHz bus going between two pcb's
  • get rid of 7-segment LED displays
    • not really needed. We have a serial port
    • could be replaced by one or two GPIO LED's
  • get rid of built-in wiggler
    • nobody has a parallel port on the laptop these days
  • get rid of li-ion battery (including charger)
    • the device can be fully usb powered by the laptop

Personal tools
Debug Board


Debug Board v3, PCB photograph

The Debug Board v3 is the most recent version of the Debug Board for Neo 1973 and Neo FreeRunner. It is sold seperately from the phones.

You need the debug board to have a serial console and for JTAG. The debug board lets you:

  • access the serial console, to get kernel debug messages the moment the respective events occur (or to get the kernel's last words when it crashes hard)
  • use JTAG to halt the processor anytime and analyze the system state (this can also be used with the gdb debugger)
  • enable write access to the NOR

Serial console and JTAG are very useful (actually, indispensable) for kernel debugging.

Overview

Architecture Diagram

The debug board provides these key components.

USB Hub

This bus-powered hub

  • attaches to the laptop using its upstream port
  • attaches to the FT2232D for JTAG and serial console on downstream port 1
  • attaches to a free USB-A connector using downstream port 2
  • attaches to the phone using downstream port 3

Using the hub, you can have access to the phone, JTAG and serial simultaneously, through a single USB cable.

You can actually even charge the phone (100mA slow charge) using that downstream port.

For the ISB hub function, we use the TUSB2046B chip.

JTAG using FT2232

Basically, we integrate a USB-JTAG adaptor similar to the [Amontec JTAGkey-tiny]. The actual reference design that we used (Thanks to Joern!) can be found at http://www.oocdlink.com

This provides us full JTAG debugging, at about 150times the speed of the wiggler

The actual JTAG port is connected with

  • the phone (via debug flex cable)
  • A separate 20-pin header using standard ARM-JTAG pinout
    • this allows the user to use this device as JTAG adaptor even for other arm-based devices

Serial Port

Instead of replicating a true RS232 port, we wanted to use a USB serial converter chip, such as the FT232 or the PL2303.

As it turns out, we can even use the second port of the FT2232 simultaneously with the JTAG. So no extra FT232 or PL2303 is required.

Tri-State Serial Port

On GTA01 the CPU UART serial port needed a multiplexer formed by a tri-state driver, since it was both connected to the GSM modem AND to the debug board. We drive the GTA01-tri-state driver mux by an inverted GSM_EN signal (pin 7 on FPC connector). For GTA02 the console serial port isn't multiplexed and connects directly to CPU UART.

Usage Instructions

Preconditions

FT2232D EEPROM

Your Debug Board contains a small serial EEPROM which should be flashed correctly during production. However, some boards have received incorrect/incomplete programming during production and thus you should verify this.

If the board shows up as USB ID 1457:5118, then everything is correct.

Only if your board shows up as USB ID 0403:6010, then you will need to flash the board!

Flashing with Linux
NOTE: FIC has done that for you, in case you have officially been supplied with the board. However, if you are one of the early adopters, the configuration and USB vendorID / productID might have not yet been set correctly.


In order to do so, you can use the ftdi_eeprom program from http://www.intra2net.com/de/produkte/opensource/ftdi/. Unfortunately, the latest version (0.2) doesn't yet contain support for our FT2232D, so you need the patch from http://people.openmoko.org/laforge/misc/debug_board_v2/ftdi_eeprom/ftdi_eeprom-0.2-moko.patch

You may also need to apply the following patch to libftdi: http://people.openmoko.org/werner/libftdi-c56-strings-dirty-hack.patch (See http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=321 for additional details.)

Furthermore, you will need the EEPROM config: http://people.openmoko.org/laforge/misc/debug_board_v2/ftdi_eeprom/neo1973_debug_board_v2.ftdi

Once you have compiled ftdi_eeprom, you can run

ftdi_eeprom --flash-eeprom neo1973_debug_board_v2.ftdi
WARNING: Make sure you don't have any other FTDI FT232 / FT2232 based devices attached to the USB while running ftdi_eeprom. It might be wise to disconnect everything but the debug board


You should get something like the following printout if everything was successful:

FTDI eeprom generator v0.2
(c) Intra2net AG <opensource@intra2net.com>
FTDI init: 0
Unable to find FTDI devices under given vendor/product id: 0x1457/0x5118
Retrying with default FTDI id.
Used eeprom space: 102 bytes
FTDI write eeprom: 0
Writing to file: neo1973_debug_board_v2.eeprom
FTDI close: 0

Once the flashing has finished, just disconnect and reconnect, and you should see

$ lsusb -v -d 0x1457:                                                                                                                                                                                               
Bus 005 Device 009: ID 1457:5118  
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         8
  idVendor           0x1457 
  idProduct          0x5118 
  bcdDevice            5.00
  iManufacturer           1 OpenMoko
  iProduct                2 Debug Board for Neo1973
  iSerial                 0 
  bNumConfigurations      1
  [...]
Flashing with Windows
NOTE: FIC has done that for you, in case you have officially been supplied with the board. However, if you are one of the early adopters, the configuration and USB vendorID / productID might have not yet been set correctly.


In order to do so, you can use the FTDI Mprog program from http://www.ftdichip.com/Resources/Utilities/MProg3.0_Setup.exe

You will need

Drivers

Linux

Please make sure you have libftdi-0.8 or later. Earlier versions are known to cause problems

Furthermore, you will need to do the following:

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

or the equivalent in your modules.conf

udev rule

Please install the rules from http://people.openmoko.org/laforge/misc/debug_board_v2/udev_rules/

NOTE: Some distros no longer name their USB subsystem usb_device, but uses simply usb instead (e.g. Ubuntu 8.x). If so, you should change the line with SUBSYSTEM accordingly, otherwise the device will not be recognized by the udev rule.


Windows

Please use the driver from http://people.openmoko.org/laforge/misc/debug_board_v2/windows_drivers/

Hardware connection

The recommended connection sequence given in Debug Board v2#Hardware connection may not work for debug board v3 and the Freerunner. It seems impossible to turn on the Freerunner after plugging the Freerunner USB cable into the PC, but before plugging the debug board USB cable into the PC. After the debug board is powered by the PC, the Freerunner should start.

Actually using it

On Linux

Serial Port

The Linux kernel of your host system will create a virtual serial device called /dev/ttyUSBx where 'x' is a sequentially assigned number. If you don't have any other USB serial converters attached to your machine, the device name will be /dev/ttyUSB0.

You can use your favourite terminal emualtor (minicom, cu, zc, ...) just like for any other/real serial port. You may use gdb as well (eg. target remote /dev/ttya).

JTAG

Once you have installed libftdi >= 0.8 and configured OpenOCD with the correct openocd.cfg from OpenOCD#openocd.cfg, it should work just fine.

Please see OpenOCD#OpenOCD_and_Debug_Board for some more information.

History

We previously had Neo1973 Debug Board v1 (inherited from some weird engineers who must have seen Brazil too often). Version 1 was never shipped to phase-0 or phaes-1, and not sold to anyone.

Changes from v2 to v3

  • drastically reduce the effective load capacitance on the upstream USB port
  • use a load-limiting 3V LDO to further ensure USB spec electrical compliance
  • add a new 10pin header [footprint] to make the I2C/SPI/IRQ pins of the GTA01/GTA02 debug connector accessible
  • rotate the 20pin ARM-JTAG connector to be able to use standard 90degree-angled sockets
  • give LED's and connectors proper names on the silk
  • add openmoko logo to the bottom silk screen


Changes from v1 to v2

  • get rid of ethernet
    • we don't need it, and
    • we especially don't want a 40pin parallel 66MHz bus going between two pcb's
  • get rid of 7-segment LED displays
    • not really needed. We have a serial port
    • could be replaced by one or two GPIO LED's
  • get rid of built-in wiggler
    • nobody has a parallel port on the laptop these days
  • get rid of li-ion battery (including charger)
    • the device can be fully usb powered by the laptop