Discussion:
[Openocd-development] Windows 7 & J-Link Problems
Eric Wetzel
2011-07-06 14:02:18 UTC
Permalink
I'm having a pile of bad times here getting J-Link to work with
OpenOCD under Windows 7 for use on the AM1808 EVM. I've learned a few
lessons; at least, I hope they're lessons, or I may have done many
things very wrong.
1. In Windows 7, I had to set the LibUSB-Win32-0.1 installer to run in
Windows XP compatibility mode or it would completely disable my USB
ports: mouse, keyboard, all non-functional.
2. I have an aversion to depending on cygwin1.dll, but when Cygwin 1.7
was released, the -mno-cygwin flag didn't work. mingw-gcc-core is a
gcc4 compiler that can make non-Cygwin executables. (Maybe this is old
news, but it's news to me)
3. I copied the installed LibUSB-Win32-0.1 usb.h and libusb.a to
include and lib, respectively, under /usr/i686-pc-mingw32/sys-root.
4. The configure options I used were: --enable-maintainer-mode
--enable-dummy --enable-jlink --enable-ft2232_ftd2xx
--with-ftd2xx-win32-zipdir=$HOME/local/src/ftd2xx --prefix=$HOME/local
CC="i686-pc-mingw32-gcc"
note 4a: I'd rather be using libftdi, but I didn't want to fight with
it in Windows
note 4b: I also wanted Bus Pirate support, but it requires termios.h
which the MinGW-targeted gcc didn't provide

This built cleanly, and I got an openocd.exe that doesn't segfault
immediately and ldd says doesn't depend on cygwin1.dll. Those seem
like positive things. The trouble comes when I try to use it. I'm
using the target/omapl138.cfg because they're comparable chips (the
OMAP-L138 is an AM1808 with a sequencer and a DSP), and I need
something to get ICEpick to enable the debug ports. The same thing
happens with no target specified and J-Link disconnected from the
board.

openocd.exe -c "source [find interface/jlink.cfg]" -c "source [find
target/omapl138.cfg]"
Open On-Chip Debugger 0.5.0-dev-00941-gff640f1 (2011-06-28-10:38)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
Warn : Adapter driver 'jlink' did not declare which transports it
allows; assuming legacy JTAG-only
Info : only one transport option; autoselect 'jtag'
RCLK - adaptive
fast memory access is enabled
dcc downloads are enabled
force hard breakpoints
use of EmbeddedICE dbgrq instead of breakpoint for target halt enabled
Info : J-Link initialization started / target CPU reset initiated
Info : J-Link ARM V8 compiled Apr 27 2011 20:42:35
Info : J-Link caps 0xb9ff7bbf
Info : J-Link hw version 80000
Info : J-Link hw type J-Link
Info : J-Link max mem block 8384
Info : J-Link configuration
Info : USB-Address: 0x0
Info : Kickstart power on JTAG-pin 19: 0x0
Info : Vref = 3.319 TCK = 1 TDI = 0 TDO = 1 TMS = 0 SRST = 0 TRST = 0
Info : J-Link JTAG Interface ready
Info : RCLK (adaptive clock speed)
Error: usb_bulk_read failed (requested=1, result=0)
Error: jlink_tap_execute, wrong result -107 (expected 1)
Error: usb_bulk_read failed (requested=1, result=0)
Error: jlink_tap_execute, wrong result -107 (expected 1)
in procedure 'transport'
in procedure 'init'

It's clearly able to communicate with the J-Link to get the hardware
information, version string, pin states (including Vref on the
target). But then some USB reads fail. Afterwards, the J-Link becomes
unresponsive for about 2 minutes; its LED is off, but it is still
present in Device Manager, and repeated openocd attempts fail to get
J-Link info:

openocd.exe -c "source [find interface/jlink.cfg]" -c "source [find
target/omapl138.cfg]"
Open On-Chip Debugger 0.5.0-dev-00941-gff640f1 (2011-06-28-10:38)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
Warn : Adapter driver 'jlink' did not declare which transports it
allows; assuming legacy JTAG-only
Info : only one transport option; autoselect 'jtag'
RCLK - adaptive
fast memory access is enabled
dcc downloads are enabled
force hard breakpoints
use of EmbeddedICE dbgrq instead of breakpoint for target halt enabled
Info : J-Link initialization started / target CPU reset initiated
Error: J-Link command 0x01 failed (-116)
Error: J-Link command EMU_CMD_VERSION failed (0)
Info : J-Link JTAG Interface ready
Info : RCLK (adaptive clock speed)
Error: J-Link command 0xdf failed (-116)
Error: usb_bulk_write failed (requested=6, result=-116)
Error: jlink_tap_execute, wrong result -107 (expected 1)
Error: usb_bulk_write failed (requested=6, result=-116)
Error: jlink_tap_execute, wrong result -107 (expected 1)
in procedure 'transport'
in procedure 'init'

Is anyone else having problems with J-Link under Windows 7? Or just
Windows 7? Or just J-Link?

Thanks,
~Eric
Xiaofan Chen
2011-07-06 14:38:02 UTC
Permalink
Post by Eric Wetzel
I'm having a pile of bad times here getting J-Link to work with
OpenOCD under Windows 7 for use on the AM1808 EVM. I've learned a few
lessons; at least, I hope they're lessons, or I may have done many
things very wrong.
1. In Windows 7, I had to set the LibUSB-Win32-0.1 installer to run in
Windows XP compatibility mode or it would completely disable my USB
ports: mouse, keyboard, all non-functional.
No no no! Please do not use the 0.1.x version of libusb-win32!

Please use libusb-win32 1.2.4.0 release. It supports Windows 7 32bit
and 64bit. Please remove the 0.1.12.x filter drivers before you install the
1.2.4.0 release.
http://sourceforge.net/apps/trac/libusb-win32/wiki

Then you can use the inf-wizard to replace the FTDI driver with
libusb-win32. Or you can keep the FTDI driver but use the
GUI Filter Wizard to install the device filter for the FTDI device.

The device filter is safe to use, but not the class filter. If you
use the GUI Filter Driver Wizard, you can attach the filter to
the specific device which will not affect your other USB device.
Post by Eric Wetzel
2. I have an aversion to depending on cygwin1.dll, but when Cygwin 1.7
was released, the -mno-cygwin flag didn't work. mingw-gcc-core is a
gcc4 compiler that can make non-Cygwin executables. (Maybe this is old
news, but it's news to me)
If you want to compile under Cygwin, you can use the latest
MinGW cross compiler.
Post by Eric Wetzel
3. I copied the installed LibUSB-Win32-0.1 usb.h and libusb.a to
include and lib, respectively, under /usr/i686-pc-mingw32/sys-root.
4. The configure options I used were: --enable-maintainer-mode
--enable-dummy --enable-jlink --enable-ft2232_ftd2xx
--with-ftd2xx-win32-zipdir=$HOME/local/src/ftd2xx --prefix=$HOME/local
CC="i686-pc-mingw32-gcc"
 note 4a: I'd rather be using libftdi, but I didn't want to fight with
it in Windows
You can use libftdi. You can use Freddie's pre-built binary.

Or if you prefer to build by yourself, I provide the libusbftdi-0.19
binaries for MinGW here.
http://code.google.com/p/picusb/downloads/list
Post by Eric Wetzel
 note 4b: I also wanted Bus Pirate support, but it requires termios.h
which the MinGW-targeted gcc didn't provide
This built cleanly, and I got an openocd.exe that doesn't segfault
immediately and ldd says doesn't depend on cygwin1.dll. Those seem
like positive things. The trouble comes when I try to use it. I'm
using the target/omapl138.cfg because they're comparable chips (the
OMAP-L138 is an AM1808 with a sequencer and a DSP), and I need
something to get ICEpick to enable the debug ports. The same thing
happens with no target specified and J-Link disconnected from the
board.
--
Xiaofan
Xiaofan Chen
2011-07-06 14:41:32 UTC
Permalink
Post by Xiaofan Chen
Post by Eric Wetzel
3. I copied the installed LibUSB-Win32-0.1 usb.h and libusb.a to
include and lib, respectively, under /usr/i686-pc-mingw32/sys-root.
4. The configure options I used were: --enable-maintainer-mode
--enable-dummy --enable-jlink --enable-ft2232_ftd2xx
--with-ftd2xx-win32-zipdir=$HOME/local/src/ftd2xx --prefix=$HOME/local
CC="i686-pc-mingw32-gcc"
 note 4a: I'd rather be using libftdi, but I didn't want to fight with
it in Windows
You can use libftdi. You can use Freddie's pre-built binary.
http://www.freddiechopin.info/index.php/pl/download/category/10-openocd-dev
Post by Xiaofan Chen
Or if you prefer to build by yourself, I provide the libusbftdi-0.19
binaries for MinGW here.
http://code.google.com/p/picusb/downloads/list
Reference: it is talking about cross under Linux. But you can
do similar thing under Cygwin (much slower than Linux, say
10 times slower).
https://lists.berlios.de/pipermail/openocd-development/2011-July/019923.html
--
Xiaofan
Spencer Oliver
2011-07-06 15:06:20 UTC
Permalink
Post by Xiaofan Chen
Post by Xiaofan Chen
Post by Eric Wetzel
3. I copied the installed LibUSB-Win32-0.1 usb.h and libusb.a to
include and lib, respectively, under /usr/i686-pc-mingw32/sys-root.
4. The configure options I used were: --enable-maintainer-mode
--enable-dummy --enable-jlink --enable-ft2232_ftd2xx
--with-ftd2xx-win32-zipdir=$HOME/local/src/ftd2xx --prefix=$HOME/local
CC="i686-pc-mingw32-gcc"
 note 4a: I'd rather be using libftdi, but I didn't want to fight with
it in Windows
You can use libftdi. You can use Freddie's pre-built binary.
http://www.freddiechopin.info/index.php/pl/download/category/10-openocd-dev
Post by Xiaofan Chen
Or if you prefer to build by yourself, I provide the libusbftdi-0.19
binaries for MinGW here.
http://code.google.com/p/picusb/downloads/list
Reference: it is talking about cross under Linux. But you can
do similar thing under Cygwin (much slower than Linux, say
10 times slower).
https://lists.berlios.de/pipermail/openocd-development/2011-July/019923.html
just to help a little under cygwin, they have only just moved onto the
mingw cross compiler so make sure you update your cygwin tools.

./configure --enable-maintainer-mode --build=i686-pc-cygwin
--host=i686-pc-mingw32 --enable-jlink

Cheers
Spen
Xiaofan Chen
2011-07-06 15:05:59 UTC
Permalink
Post by Eric Wetzel
This built cleanly, and I got an openocd.exe that doesn't segfault
immediately and ldd says doesn't depend on cygwin1.dll. Those seem
like positive things. The trouble comes when I try to use it. I'm
using the target/omapl138.cfg because they're comparable chips (the
OMAP-L138 is an AM1808 with a sequencer and a DSP), and I need
something to get ICEpick to enable the debug ports. The same thing
happens with no target specified and J-Link disconnected from the
board.
openocd.exe -c "source [find interface/jlink.cfg]" -c "source [find
target/omapl138.cfg]"
Open On-Chip Debugger 0.5.0-dev-00941-gff640f1 (2011-06-28-10:38)
Licensed under GNU GPL v2
For bug reports, read
       http://openocd.berlios.de/doc/doxygen/bugs.html
Warn : Adapter driver 'jlink' did not declare which transports it
allows; assuming legacy JTAG-only
Info : only one transport option; autoselect 'jtag'
RCLK - adaptive
fast memory access is enabled
dcc downloads are enabled
force hard breakpoints
use of EmbeddedICE dbgrq instead of breakpoint for target halt enabled
Info : J-Link initialization started / target CPU reset initiated
Info : J-Link ARM V8 compiled Apr 27 2011 20:42:35
Info : J-Link caps 0xb9ff7bbf
Info : J-Link hw version 80000
Info : J-Link hw type J-Link
Info : J-Link max mem block 8384
Info : J-Link configuration
Info : USB-Address: 0x0
Info : Kickstart power on JTAG-pin 19: 0x0
Info : Vref = 3.319 TCK = 1 TDI = 0 TDO = 1 TMS = 0 SRST = 0 TRST = 0
Info : J-Link JTAG Interface ready
Info : RCLK (adaptive clock speed)
Error: usb_bulk_read failed (requested=1, result=0)
Error: jlink_tap_execute, wrong result -107 (expected 1)
Error: usb_bulk_read failed (requested=1, result=0)
Error: jlink_tap_execute, wrong result -107 (expected 1)
in procedure 'transport'
in procedure 'init'
It's clearly able to communicate with the J-Link to get the hardware
information, version string, pin states (including Vref on the
target). But then some USB reads fail. Afterwards, the J-Link becomes
unresponsive for about 2 minutes; its LED is off, but it is still
present in Device Manager, and repeated openocd attempts fail to get
openocd.exe -c "source [find interface/jlink.cfg]" -c "source [find
target/omapl138.cfg]"
Open On-Chip Debugger 0.5.0-dev-00941-gff640f1 (2011-06-28-10:38)
Licensed under GNU GPL v2
For bug reports, read
       http://openocd.berlios.de/doc/doxygen/bugs.html
Warn : Adapter driver 'jlink' did not declare which transports it
allows; assuming legacy JTAG-only
Info : only one transport option; autoselect 'jtag'
RCLK - adaptive
fast memory access is enabled
dcc downloads are enabled
force hard breakpoints
use of EmbeddedICE dbgrq instead of breakpoint for target halt enabled
Info : J-Link initialization started / target CPU reset initiated
Error: J-Link command 0x01 failed (-116)
Error: J-Link command EMU_CMD_VERSION failed (0)
Info : J-Link JTAG Interface ready
Info : RCLK (adaptive clock speed)
Error: J-Link command 0xdf failed (-116)
Error: usb_bulk_write failed (requested=6, result=-116)
Error: jlink_tap_execute, wrong result -107 (expected 1)
Error: usb_bulk_write failed (requested=6, result=-116)
Error: jlink_tap_execute, wrong result -107 (expected 1)
in procedure 'transport'
in procedure 'init'
Is anyone else having problems with J-Link under Windows 7? Or just
Windows 7? Or just J-Link?
Try to update the libusb-win32 version to see if that helps.

On the other hand, this may have something to do with either
your J-Link version or your target.

I just tried J-Link V7 and LPC-2148 target under Windows 7 32bit
and it is okay. I am using libusb-win32 1.2.4.7 snapshot
edition and Freddie's latest development version binary.
So it is not the latest git version but you can try it.

I also tried the same binary under Windows 7 64bit a few
days ago without an issue.
--
Xiaofan
Jean-Christophe PLAGNIOL-VILLARD
2011-07-06 17:27:00 UTC
Permalink
Post by Xiaofan Chen
Post by Eric Wetzel
This built cleanly, and I got an openocd.exe that doesn't segfault
immediately and ldd says doesn't depend on cygwin1.dll. Those seem
like positive things. The trouble comes when I try to use it. I'm
using the target/omapl138.cfg because they're comparable chips (the
OMAP-L138 is an AM1808 with a sequencer and a DSP), and I need
something to get ICEpick to enable the debug ports. The same thing
happens with no target specified and J-Link disconnected from the
board.
openocd.exe -c "source [find interface/jlink.cfg]" -c "source [find
target/omapl138.cfg]"
Open On-Chip Debugger 0.5.0-dev-00941-gff640f1 (2011-06-28-10:38)
Licensed under GNU GPL v2
For bug reports, read
       http://openocd.berlios.de/doc/doxygen/bugs.html
Warn : Adapter driver 'jlink' did not declare which transports it
allows; assuming legacy JTAG-only
Info : only one transport option; autoselect 'jtag'
RCLK - adaptive
fast memory access is enabled
dcc downloads are enabled
force hard breakpoints
use of EmbeddedICE dbgrq instead of breakpoint for target halt enabled
Info : J-Link initialization started / target CPU reset initiated
Info : J-Link ARM V8 compiled Apr 27 2011 20:42:35
Info : J-Link caps 0xb9ff7bbf
Info : J-Link hw version 80000
Info : J-Link hw type J-Link
Info : J-Link max mem block 8384
Info : J-Link configuration
Info : USB-Address: 0x0
Info : Kickstart power on JTAG-pin 19: 0x0
Info : Vref = 3.319 TCK = 1 TDI = 0 TDO = 1 TMS = 0 SRST = 0 TRST = 0
Info : J-Link JTAG Interface ready
Info : RCLK (adaptive clock speed)
Error: usb_bulk_read failed (requested=1, result=0)
Error: jlink_tap_execute, wrong result -107 (expected 1)
Error: usb_bulk_read failed (requested=1, result=0)
Error: jlink_tap_execute, wrong result -107 (expected 1)
in procedure 'transport'
in procedure 'init'
It's clearly able to communicate with the J-Link to get the hardware
information, version string, pin states (including Vref on the
target). But then some USB reads fail. Afterwards, the J-Link becomes
unresponsive for about 2 minutes; its LED is off, but it is still
present in Device Manager, and repeated openocd attempts fail to get
openocd.exe -c "source [find interface/jlink.cfg]" -c "source [find
target/omapl138.cfg]"
Open On-Chip Debugger 0.5.0-dev-00941-gff640f1 (2011-06-28-10:38)
Licensed under GNU GPL v2
For bug reports, read
       http://openocd.berlios.de/doc/doxygen/bugs.html
Warn : Adapter driver 'jlink' did not declare which transports it
allows; assuming legacy JTAG-only
Info : only one transport option; autoselect 'jtag'
RCLK - adaptive
fast memory access is enabled
dcc downloads are enabled
force hard breakpoints
use of EmbeddedICE dbgrq instead of breakpoint for target halt enabled
Info : J-Link initialization started / target CPU reset initiated
Error: J-Link command 0x01 failed (-116)
Error: J-Link command EMU_CMD_VERSION failed (0)
Info : J-Link JTAG Interface ready
Info : RCLK (adaptive clock speed)
Error: J-Link command 0xdf failed (-116)
Error: usb_bulk_write failed (requested=6, result=-116)
Error: jlink_tap_execute, wrong result -107 (expected 1)
Error: usb_bulk_write failed (requested=6, result=-116)
Error: jlink_tap_execute, wrong result -107 (expected 1)
in procedure 'transport'
in procedure 'init'
Is anyone else having problems with J-Link under Windows 7? Or just
Windows 7? Or just J-Link?
Try to update the libusb-win32 version to see if that helps.
On the other hand, this may have something to do with either
your J-Link version or your target.
I just tried J-Link V7 and LPC-2148 target under Windows 7 32bit
and it is okay. I am using libusb-win32 1.2.4.7 snapshot
edition and Freddie's latest development version binary.
So it is not the latest git version but you can try it.
I also tried the same binary under Windows 7 64bit a few
days ago without an issue.
Check the firmware version
maybe too recent

Best Regards,
J.
Xiaofan Chen
2011-07-07 00:51:10 UTC
Permalink
On Thu, Jul 7, 2011 at 1:27 AM, Jean-Christophe PLAGNIOL-VILLARD
Post by Jean-Christophe PLAGNIOL-VILLARD
Post by Xiaofan Chen
Try to update the libusb-win32 version to see if that helps.
On the other hand, this may have something to do with either
your J-Link version or your target.
I just tried J-Link V7 and LPC-2148 target under Windows 7 32bit
and it is okay. I am using libusb-win32 1.2.4.7 snapshot
edition and Freddie's latest development version binary.
So it is not the latest git version but you can try it.
I also tried the same binary under Windows 7 64bit a few
days ago without an issue.
Check the firmware version
maybe too recent
Indeed. I do not have a V8 for testing right now. I will try
to borrow one. We have many J-Links at work, some of
them V6, some of them V8, and there is a J-Link Pro.

Info : J-Link initialization started / target CPU reset initiated
Info : J-Link ARM V8 compiled Apr 27 2011 20:42:35
Info : J-Link caps 0xb9ff7bbf
Info : J-Link hw version 80000
Info : J-Link hw type J-Link
Info : J-Link max mem block 8384
--
Xiaofan
Eric Wetzel
2011-07-07 12:23:59 UTC
Permalink
Post by Xiaofan Chen
On Thu, Jul 7, 2011 at 1:27 AM, Jean-Christophe PLAGNIOL-VILLARD
Post by Jean-Christophe PLAGNIOL-VILLARD
Post by Xiaofan Chen
Try to update the libusb-win32 version to see if that helps.
On the other hand, this may have something to do with either
your J-Link version or your target.
I just tried J-Link V7 and LPC-2148 target under Windows 7 32bit
and it is okay. I am using libusb-win32 1.2.4.7 snapshot
edition and Freddie's latest development version binary.
So it is not the latest git version but you can try it.
I also tried the same binary under Windows 7 64bit a few
days ago without an issue.
Check the firmware version
maybe too recent
Indeed. I do not have a V8 for testing right now. I will try
to borrow one. We have many J-Links at work, some of
them V6, some of them V8, and there is a J-Link Pro.
Info : J-Link initialization started / target CPU reset initiated
Info : J-Link ARM V8 compiled Apr 27 2011 20:42:35
Info : J-Link caps 0xb9ff7bbf
Info : J-Link hw version 80000
Info : J-Link hw type J-Link
Info : J-Link max mem block 8384
--
Xiaofan
Alright, I uninstalled libusb-win32 0.1 and installed 1.2.4.0, and
installed filters for the J-Link device. Still the same result.

I tried Freddie's binary. Still the same result.

It is beginning to look like a firmware version problem. I guess I'm
disappointed, but not actually surprised, that it's not compliant with
Segger's J-Link documentation:
http://www.segger.com/cms/admin/uploads/productDocs/RM08001_JLinkUSBProtocol.pdf

Thanks,
~Eric
Xiaofan Chen
2011-07-07 12:27:49 UTC
Permalink
Post by Eric Wetzel
Alright, I uninstalled libusb-win32 0.1 and installed 1.2.4.0, and
installed filters for the J-Link device. Still the same result.
I tried Freddie's binary. Still the same result.
It is beginning to look like a firmware version problem. I guess I'm
disappointed, but not actually surprised, that it's not compliant with
http://www.segger.com/cms/admin/uploads/productDocs/RM08001_JLinkUSBProtocol.pdf
You should be able downgrade the firmware with Segger J-Link
utilities. Then you can try again.
http://www.segger.com/cms/j-link-older-versions.html
--
Xiaofan
Eric Wetzel
2011-07-08 13:21:49 UTC
Permalink
Post by Xiaofan Chen
Post by Eric Wetzel
Alright, I uninstalled libusb-win32 0.1 and installed 1.2.4.0, and
installed filters for the J-Link device. Still the same result.
I tried Freddie's binary. Still the same result.
It is beginning to look like a firmware version problem. I guess I'm
disappointed, but not actually surprised, that it's not compliant with
http://www.segger.com/cms/admin/uploads/productDocs/RM08001_JLinkUSBProtocol.pdf
You should be able downgrade the firmware with Segger J-Link
utilities. Then you can try again.
http://www.segger.com/cms/j-link-older-versions.html
--
Xiaofan
I downloaded the oldest version available (v4.00) from the page
Xiaofan provided, and downgraded the firmware. I had to reinstall my
libusb filter for the J-Link, but I'm not getting the same USB read
problems. Actually, it looks like it's working.

$ openocd.exe
Open On-Chip Debugger 0.5.0-dev (2011-07-07-08:00)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
Warn : Adapter driver 'jlink' did not declare which transports it
allows; assuming legacy JTAG-only
Info : only one transport option; autoselect 'jtag'
RCLK - adaptive
fast memory access is enabled
dcc downloads are enabled
force hard breakpoints
use of EmbeddedICE dbgrq instead of breakpoint for target halt enabled
Info : J-Link initialization started / target CPU reset initiated
Info : J-Link ARM V8 compiled DEC 16 2008 20:15:16
Info : J-Link caps 0x39ff7bbf
Info : J-Link hw version 80000
Info : J-Link hw type J-Link
Info : J-Link max mem block 9224
Info : J-Link configuration
Info : USB-Address: 0x0
Info : Kickstart power on JTAG-pin 19: 0x0
Info : Vref = 3.313 TCK = 1 TDI = 0 TDO = 1 TMS = 0 SRST = 0 TRST = 0
Info : J-Link JTAG Interface ready
Info : RCLK (adaptive clock speed)
Info : JTAG tap: omapl138.jrc tap/device found: 0x0b7d102f (mfg:
0x017, part: 0xb7d1, ver: 0x0)
Info : JTAG tap: omapl138.etb enabled
Info : JTAG tap: omapl138.arm enabled
Info : Embedded ICE version 6
Info : omapl138.arm: hardware has 2 breakpoint/watchpoint units
Info : ETM v1.3

Thanks,
~Eric
Xiaofan Chen
2011-07-08 14:00:30 UTC
Permalink
Post by Eric Wetzel
I downloaded the oldest version available (v4.00) from the page
Xiaofan provided, and downgraded the firmware. I had to reinstall my
libusb filter for the J-Link, but I'm not getting the same USB read
problems. Actually, it looks like it's working.
$ openocd.exe
Open On-Chip Debugger 0.5.0-dev (2011-07-07-08:00)
Licensed under GNU GPL v2
For bug reports, read
       http://openocd.berlios.de/doc/doxygen/bugs.html
Warn : Adapter driver 'jlink' did not declare which transports it
allows; assuming legacy JTAG-only
Info : only one transport option; autoselect 'jtag'
RCLK - adaptive
fast memory access is enabled
dcc downloads are enabled
force hard breakpoints
use of EmbeddedICE dbgrq instead of breakpoint for target halt enabled
Info : J-Link initialization started / target CPU reset initiated
Info : J-Link ARM V8 compiled DEC 16 2008 20:15:16
Info : J-Link caps 0x39ff7bbf
Info : J-Link hw version 80000
Info : J-Link hw type J-Link
Info : J-Link max mem block 9224
Info : J-Link configuration
Info : USB-Address: 0x0
Info : Kickstart power on JTAG-pin 19: 0x0
Info : Vref = 3.313 TCK = 1 TDI = 0 TDO = 1 TMS = 0 SRST = 0 TRST = 0
Info : J-Link JTAG Interface ready
Info : RCLK (adaptive clock speed)
0x017, part: 0xb7d1, ver: 0x0)
Info : JTAG tap: omapl138.etb enabled
Info : JTAG tap: omapl138.arm enabled
Info : Embedded ICE version 6
Info : omapl138.arm: hardware has 2 breakpoint/watchpoint units
Info : ETM v1.3
Yes I can reproduce the issue with Luminary EK-LM3S1968 board, with the
latest firmware it failed just like your previous post. Then if I downgrade the
firmware to 4.08i and OpenOCD will work.

For those who want to downgrade the firmware, here is the doc.
http://www.segger.com/cms/admin/uploads/productDocs/UM08001_JLinkARM.pdf
(Section 9.5)

This is a known problem.
http://www.segger2.com/index.php?page=Thread&threadID=869
http://comments.gmane.org/gmane.comp.debugging.openocd.devel/16831
http://www.segger2.com/index.php?page=Thread&threadID=707
(4.10i works, 4.22 failed)
--
Xiaofan
Xiaofan Chen
2011-07-08 14:27:38 UTC
Permalink
Post by Xiaofan Chen
Post by Eric Wetzel
I downloaded the oldest version available (v4.00) from the page
Xiaofan provided, and downgraded the firmware. I had to reinstall my
libusb filter for the J-Link, but I'm not getting the same USB read
problems. Actually, it looks like it's working.
Yes once you upgrade/downgrade the J-Link firmware, it will re-enumerate
and therefore you will need to re-install the libusb-win32 device filter.
But it is quite convenient with the GUI filter wizard.
Post by Xiaofan Chen
Yes I can reproduce the issue with Luminary EK-LM3S1968 board, with the
latest firmware it failed just like your previous post. Then if I downgrade the
firmware to 4.08i and OpenOCD will work.
For those who want to downgrade the firmware, here is the doc.
http://www.segger.com/cms/admin/uploads/productDocs/UM08001_JLinkARM.pdf
(Section 9.5)
This is a known problem.
http://www.segger2.com/index.php?page=Thread&threadID=869
http://comments.gmane.org/gmane.comp.debugging.openocd.devel/16831
http://www.segger2.com/index.php?page=Thread&threadID=707
(4.10i works, 4.22 failed)
BTW, this seems to only affect V8 J-Link, I tried a V7 with the
latest J-Link firmware and it works with OpenOCD.
--
Xiaofan
Eric Wetzel
2011-08-01 13:45:30 UTC
Permalink
Post by Xiaofan Chen
Post by Xiaofan Chen
Post by Eric Wetzel
I downloaded the oldest version available (v4.00) from the page
Xiaofan provided, and downgraded the firmware. I had to reinstall my
libusb filter for the J-Link, but I'm not getting the same USB read
problems. Actually, it looks like it's working.
Yes once you upgrade/downgrade the J-Link firmware, it will re-enumerate
and therefore you will need to re-install the libusb-win32 device filter.
But it is quite convenient with the GUI filter wizard.
Post by Xiaofan Chen
Yes I can reproduce the issue with Luminary EK-LM3S1968 board, with the
latest firmware it failed just like your previous post. Then if I downgrade the
firmware to 4.08i and OpenOCD will work.
For those who want to downgrade the firmware, here is the doc.
http://www.segger.com/cms/admin/uploads/productDocs/UM08001_JLinkARM.pdf
(Section 9.5)
This is a known problem.
http://www.segger2.com/index.php?page=Thread&threadID=869
http://comments.gmane.org/gmane.comp.debugging.openocd.devel/16831
http://www.segger2.com/index.php?page=Thread&threadID=707
(4.10i works, 4.22 failed)
BTW, this seems to only affect V8 J-Link, I tried a V7 with the
latest J-Link firmware and it works with OpenOCD.
--
Xiaofan
I did a rather tedious bisection on the J-Link firmwares released by
Segger. Here is where the defect is introduced:
V4.14h: Bad (tested) J-Link ARM V8 compiled Aug 4 2010 19:16:19

The last good version was:
V4.14g: Good (tested) J-Link ARM V8 compiled Dec 1 2009 11:42:48

Their Release Notes aren't very consistent in these packages, being
labelled "Release notes for J-Flash ARM V4.08a" and having version
information only up until V4.12. But who knows what they could have
changed in 8 months.

And I tested the latest version (V4.32) to ensure that the problem
wasn't corrected on their end, and it was not.

I only tested this on my V8 J-Link, but Xiaofan said that the V7 works fine.

~Eric
Xiaofan Chen
2011-08-02 06:25:49 UTC
Permalink
Post by Eric Wetzel
I did a rather tedious bisection on the J-Link firmwares released by
V4.14h: Bad  (tested) J-Link ARM V8 compiled Aug  4 2010 19:16:19
V4.14g: Good (tested) J-Link ARM V8 compiled Dec  1 2009 11:42:48
Their Release Notes aren't very consistent in these packages, being
labeled "Release notes for J-Flash ARM V4.08a" and having version
information only up until V4.12. But who knows what they could have
changed in 8 months.
And I tested the latest version (V4.32) to ensure that the problem
wasn't corrected on their end, and it was not.
I only tested this on my V8 J-Link, but Xiaofan said that the V7 works fine.
I just tried V6 and it seems to work as well.

SEGGER J-Link Commander V4.32 ('?' for help)
Compiled Jul 29 2011 18:38:14
DLL version V4.32, compiled Jul 29 2011 18:37:55
Firmware: J-Link ARM V6 compiled Feb 1 2011 14:28:14
Hardware: V6.00
S/N: xxxxxxxxxx
OEM: IAR
J-Link>f
Firmware: J-Link ARM V6 compiled Feb 1 2011 14:28:14
Hardware: V6.00
J-Link>st
VTarget=3.274V
ITarget=109mA
TCK=1 TDI=0 TDO=1 TMS=0 TRES=1 TRST=1
Supported JTAG speeds:
- 48 MHz/n, (n>=4). => 12000kHz, 9600kHz, 8000kHz, ...
- Adaptive clocking
J-Link>i
JTAG Id: 0x4F1F0F0F Version: 0x4 Part no: 0xf1f0 Man. Id: 0787
J-Link>testrspeed
Speed test: Reading 8 * 8kb from address 0x00000000 Info: RTCK reaction time is
approx. 126ns
Info: Auto JTAG speed: Adaptive
........
8 kByte read in 82ms ! (99.8 KByte/sec)
J-Link>testrspeed
Speed test: Reading 8 * 128kb from address 0x00000000 ........
128 kByte read in 1197ms ! (109.5 KByte/sec)

C:\temp\openocd-0.5rc1\bin>openocd-0.5.0-rc1.exe -f
interface\jlink.cfg -f target\lpc2468.cfg
(note: this is not proper config, I am testing with an IAR LPC-2468 KS board).
Open On-Chip Debugger 0.5.0-dev (2011-07-11-21:12)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
Warn : Adapter driver 'jlink' did not declare which transports it allows; assumi
ng legacy JTAG-only
Info : only one transport option; autoselect 'jtag'
init_targets
Warning - assuming default core clock 4MHz! Flashing may fail if
actual core clock is different.
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
500 kHz
Info : J-Link initialization started / target CPU reset initiated
Info : J-Link ARM V6 compiled Feb 1 2011 14:28:14
Info : J-Link caps 0x99ff7bbf
Info : J-Link hw version 60000
Info : J-Link hw type J-Link
Info : J-Link max mem block 8864
Info : J-Link configuration
Info : USB-Address: 0xff
Info : Kickstart power on JTAG-pin 19: 0xffffff01
Info : Vref = 3.274 TCK = 1 TDI = 0 TDO = 1 TMS = 0 SRST = 1 TRST = 0
Info : J-Link JTAG Interface ready
Info : clock speed 500 kHz
Info : JTAG tap: lpc2468.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787,
part: 0xf1f0, ver: 0x4)
Info : Embedded ICE version 7
Error: EmbeddedICE v7 handling might be broken
Info : lpc2468.cpu: hardware has 2 breakpoint/watchpoint units

Just wondering who has a nice board file for IAR LPC-2468 KS?
--
Xiaofan
Loading...