Hello,

Looking at the information that is out there, it is clear that people are using OpenOCD with the LPC3180. I have looked for an OpenOCD config file but have not had any luck finding one. Through trial and error I did come up with one that appears to work but I suspect that there are errors in at least the jtag scan chain section of the config file.

My set up:
- Linux development PC running Eclipse, GDB, GCC and OpenOCD
- Olimex JTAG Wiggler
- Phytec LPC3180
- developing code to run from internal RAM

For the record, here is the OpenOCD config file I am using now:

#daemon configuration
telnet_port 4000
gdb_port 2000

#interface
interface parport
parport_port 0
parport_cable wiggler
jtag_speed 0

#use combined on interfaces or targets that can\'t set TRST/SRST separately
reset_config trst_and_srst

#jtag scan chain
#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
# From the LPC3180 User Manual: There are two JTAG-style scan chains within
# the ARM core. A JTAG-style Test Access Port Controller controls the scan
# chains. In addition to the scan chains, the debug architecture uses
# EmbeddedICE-RT logic which resides on chip with the ARM core. The
# EmbeddedICE-RT has its own scan chain that is used to insert watchpoints
# and breakpoints for the ARM core.
# TAP controller 1: two scan chains - one for debug (#1) and one (#2) for
# embedded ICE
# TAP controller 2: ?? can\'t find any details on it. OpenOCD needs to see
# two or it will exit with an error
#
# The configuration of the following 2 TAPs work but it is not clear why that is
# TAP 1 config is the standard ARM7/9 configuration
# TAP 2 config is trial and error. Any attempts with a capture mask that
# was odd resulted in OpenOCD crashing when attempting to enable
# s/w break points. Any attempts with a capture mask that was even
# but not 0 caused a watchdog timeout when a scan did not pass the
# requested check.
#
jtag_device 4 0x1 0xf 0xe
jtag_device 4 0x1 0x0 0x1e

#target configuration
daemon_startup reset

#target
#target arm966e
target arm926ejs little run_and_halt 1 arm926ejs
run_and_halt_time 0 30

working_area 0 0x08000000 16384 nobackup

If anyone has a config file that they would be interested in sharing, I would certainly appreciate it. Thanks.

Cheers,
Peter Start a New Thread

Hello Peter,

I've developed the ARM926EJ-S support in the OpenOCD using a LPC3180 board
from Phytec, find the config file I'm using attached to this mail. You'll
have to modify the interface part to match your Wiggler configuration.

The LPC3180 incorporates the ARM926EJ-S macrocell and the ETB (Embedded Trace
Buffer):
TDI -> ARM926EJ-S -> ETB -> TDO

The OpenOCD expects the jtag_devices to be listed from TDO (i.e. from the
right-most bit, when picturing the scan chain) to TDI (i.e. the left-most
bit):
jtag_device 4 0x1 0xf 0xe
jtag_device 4 0x1 0xf 0xe

In our case this doesn't matter, as both TAP controllers have the same
properties.

But for the target configuration, the order is important:
target arm926ejs little reset_halt 1

The last argument '1' (the variant "arm926ejs" from your .cfg file is no
longer necessary) denotes the chain position - the ARM926EJ-S is the second
device.

You should also make sure that you're using the latest version of OpenOCD
(R141), as this contains a fix that allows the LPC3180 to be debugged out of
reset (reset_halt, instead of run_and_halt). This is valuable if you're
debugging startup code that initializes PLLs and SDRAM.

The NAND support currently doesn't make use of a working_area, so I left that
out of my config file for now, but your setting should be correct. The NAND
support is also barely tested (afaik I'm the only user of it), and the OOB
handling is only rudimentary, but I've been able to erase the flash and to
write the first stage bootloader using the MLC controller.

You can also remove the "arm7_9 etm" and "etb" lines, as there's currently no
support for using them for anything productive.

Regards,

Dominic

On Thursday 19 April 2007 14:35:14 p...@akamina.com wrote:
> Hello,
>
> Looking at the information that is out there, it is clear that people are
> using OpenOCD with the LPC3180. I have looked for an OpenOCD config file
> but have not had any luck finding one. Through trial and error I did come
> up with one that appears to work but I suspect that there are errors in at
> least the jtag scan chain section of the config file.
>
> My set up:
> - Linux development PC running Eclipse, GDB, GCC and OpenOCD
> - Olimex JTAG Wiggler
> - Phytec LPC3180
> - developing code to run from internal RAM
>
> For the record, here is the OpenOCD config file I am using now:
>
> #daemon configuration
> telnet_port 4000
> gdb_port 2000
>
> #interface
> interface parport
> parport_port 0
> parport_cable wiggler
> jtag_speed 0
>
> #use combined on interfaces or targets that can\'t set TRST/SRST separately
> reset_config trst_and_srst
>
> #jtag scan chain
> #format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
> # From the LPC3180 User Manual: There are two JTAG-style scan chains within
> # the ARM core. A JTAG-style Test Access Port Controller controls the scan
> # chains. In addition to the scan chains, the debug architecture uses
> # EmbeddedICE-RT logic which resides on chip with the ARM core. The
> # EmbeddedICE-RT has its own scan chain that is used to insert watchpoints
> # and breakpoints for the ARM core.
> # TAP controller 1: two scan chains - one for debug (#1) and one (#2) for
> # embedded ICE
> # TAP controller 2: ?? can\'t find any details on it. OpenOCD needs to see
> # two or it will exit with an error
> #
> # The configuration of the following 2 TAPs work but it is not clear why
> that is # TAP 1 config is the standard ARM7/9 configuration
> # TAP 2 config is trial and error. Any attempts with a capture mask that
> # was odd resulted in OpenOCD crashing when attempting to enable
> # s/w break points. Any attempts with a capture mask that was even
> # but not 0 caused a watchdog timeout when a scan did not pass the
> # requested check.
> #
> jtag_device 4 0x1 0xf 0xe
> jtag_device 4 0x1 0x0 0x1e
>
> #target configuration
> daemon_startup reset
>
> #target
> #target arm966e
> target arm926ejs little run_and_halt 1 arm926ejs
> run_and_halt_time 0 30
>
> working_area 0 0x08000000 16384 nobackup
>
> If anyone has a config file that they would be interested in sharing, I
> would certainly appreciate it. Thanks.
>
> Cheers,
> Peter

----------

#daemon configuration
telnet_port 4444
gdb_port 3333

#interface
interface ft2232
#ft2232_device_desc "Olimex OpenOCD JTAG"
#ft2232_layout olimex-jtag
#ft2232_vid_pid 0x15ba 0x0003
ft2232_device_desc "Amontec JTAGkey"
ft2232_serial AMTJKV31
#ft2232_serial T1P3S2W8
ft2232_layout jtagkey
ft2232_vid_pid 0x0403 0xcff8
jtag_speed 20
#use combined on interfaces or targets that can't set TRST/SRST separately
reset_config trst_and_srst

#jtag scan chain
#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
jtag_device 4 0x1 0xf 0xe
jtag_device 4 0x1 0xf 0xe

jtag_nsrst_delay 200
jtag_ntrst_delay 200

#target configuration
daemon_startup attach
#target
target arm926ejs little reset_halt 1
#arm7_9 etm
arm7_9 etm 0
#arm7_9 etb
arm7_9 etb 0 0

#target_script 0 reset csb337_init.script
#working_area 0 0x20000000 0x4000 nobackup

#flash configuration
#flash bank [driver_options ...]
#flash bank cfi 0x60000000 0x1000000 2 2 0
#flash bank cfi 0xe0000000 0x1000000 2 2 0
nand device lpc3180 0 13000 Start a New Thread

On Thursday 19 April 2007 14:59:47 Dominic Rath wrote:
> I've developed the ARM926EJ-S support in the OpenOCD using a LPC3180 board
> from Phytec, find the config file I'm using attached to this mail. You'll
> have to modify the interface part to match your Wiggler configuration.

Okay, no attachments here, so get it from
http://mmd.ath.cx/openocd/phycore_lpc3180_ft2232.cfg

Regards,

Dominic Start a New Thread

On Thursday 19 April 2007 14:59:47 Dominic Rath wrote:
>> I've developed the ARM926EJ-S support in the OpenOCD using a LPC3180 board
>> from Phytec, find the config file I'm using attached to this mail. You'll
>> have to modify the interface part to match your Wiggler configuration.
>
>Okay, no attachments here, so get it from
>http://mmd.ath.cx/openocd/phycore_lpc3180_ft2232.cfg
>
>Regards,
>
>Dominic

Thank you for the quick responses Dominic. I appreciate the information and the work that you have done with OpenOCD. I'll make the changes that you recommend, test it and then update the sample project that I'll release for others who are interested in getting started with the 3180.

Cheers,

Peter Start a New Thread

On Thursday 19 April 2007 21:09:02 p...@akamina.com wrote:
> On Thursday 19 April 2007 14:59:47 Dominic Rath wrote:
> >> I've developed the ARM926EJ-S support in the OpenOCD using a LPC3180
> >> board from Phytec, find the config file I'm using attached to this mail.
> >> You'll have to modify the interface part to match your Wiggler
> >> configuration.
> >
> >Okay, no attachments here, so get it from
> >http://mmd.ath.cx/openocd/phycore_lpc3180_ft2232.cfg
> >
> >Regards,
> >
> >Dominic
>
> Thank you for the quick responses Dominic. I appreciate the information and
> the work that you have done with OpenOCD. I'll make the changes that you
> recommend, test it and then update the sample project that I'll release for
> others who are interested in getting started with the 3180.
>
> Cheers,
>
> Peter

Hello Peter,

I also have a simple GCC led-blinking example that initializes the PLL, SDRAM
etc., then calls a C main that does the blinking. Currently it's very
specific to the Phytec Board, so you'll probably have to adjust some timings
etc. if your board uses different parts. Let me know if you want to have the
code. This includes a headerfile for the LPC3180 that I've written completely
from scratch, i.e. without any Keil/IAR copyright.

Regards,

Dominic Start a New Thread

On Thursday 19 April 2007 21:09:02 p...@akamina.com wrote:
>> On Thursday 19 April 2007 14:59:47 Dominic Rath wrote:
>> > > I've developed the ARM926EJ-S support in the OpenOCD using a LPC3180
>> > > board from Phytec, find the config file I'm using attached to this mail.
>> > > You'll have to modify the interface part to match your Wiggler
>> > > configuration.
>> >
>> > Okay, no attachments here, so get it from
>> > http://mmd.ath.cx/openocd/phycore_lpc3180_ft2232.cfg
>> >
>> > Regards,
>> >
>> > Dominic
>>
>> Thank you for the quick responses Dominic. I appreciate the information and
>> the work that you have done with OpenOCD. I'll make the changes that you
>> recommend, test it and then update the sample project that I'll release for
>> others who are interested in getting started with the 3180.
>>
>> Cheers,
>>
>> Peter
>
>Hello Peter,
>
>I also have a simple GCC led-blinking example that initializes the PLL, SDRAM
>etc., then calls a C main that does the blinking. Currently it's very
>specific to the Phytec Board, so you'll probably have to adjust some timings
>etc. if your board uses different parts. Let me know if you want to have the
>code. This includes a headerfile for the LPC3180 that I've written completely
>from scratch, i.e. without any Keil/IAR copyright.
>
>Regards,
>
>Dominic

Hello Dominic,

Thanks for the offer. I am indeed interested in seeing what you have done. Since I too am working with the Phytec board the differences in the code would not be an issue.

I have moved my code into a zip file and put it onto my server. If you are interested, you can get find it at: http://www.akamina.com/files/ARM/3180IRAM.zip

The zip file includes my old openocd config file since I am still having problems with the revisions that you suggested (see below). The header file that I have included is the file that is available from the Keil website. The copyright information in the file indicates that the header file was developed by Philips. I have assumed that Philips would be ok with this file being distributed for use with their part.

I am still revising the document that descibes the set up and use of the software (IDE, OpenOCD, ...) to include the work on the 3180. The version that I have so far is available at: http://akamina.com/Reports/GnuArm_Setup_Guide.pdf. It includes the Olimex 2148 and the Keil MCB STR9 and a draft of the 3180 section.

<====>

Here is a log of my attempts to use the correct OpenOCD configuration. I have updated OpenOCD to the latest version and have used gdb directly to control the interaction between gdb and OpenOCD.

My config file (with your recommendations):
#daemon configuration
telnet_port 4000
gdb_port 2000

#interface
interface parport
parport_port 0
parport_cable wiggler
jtag_speed 0

#use combined on interfaces or targets that can't set TRST/SRST separately
reset_config trst_and_srst

#jtag scan chain
jtag_device 4 0x1 0xf 0xe
jtag_device 4 0x1 0xf 0xe

jtag_nsrst_delay 200
jtag_ntrst_delay 200

#target configuration
daemon_startup attach

#target
target arm926ejs little reset_halt 1
#arm7_9 etm
arm7_9 etm 0
#arm7_9 etb
arm7_9 etb 0 0

working_area 0 0x08000000 16384 nobackup

#nand configuration
#nand device [controller specific arguments]
nand device lpc3180 0 13000

The log below combines my gdb commands with the response from OpenOCD.
1) Start OpenOCD (openocd -f openocd.cfg)
Info: openocd.c:86 main(): Open On-Chip Debugger (2007-04-11 16:20
CEST)

2) Start gdb session (arm-elf-gdb)

Output from the OpenOCD window:
Info: server.c:67 add_connection(): accepted 'gdb' connection from 0
Warning: gdb_server.c:246 gdb_get_packet(): acknowledgment received,
but no packet pending
Warning: jtag.c:1068 jtag_read_buffer(): value captured during scan
didn't pass the requested check: captured: 0x0f check_value:
0x01 check_mask: 0x0f

3) Via the gdb interface, enter the command: target remote localhost:2000.

When gdb indicates that there is a program already being debugged,
enter y to kill it.

Output from the OpenOCD window:
Info: server.c:367 server_loop(): dropped 'gdb' connection
Warning: arm7_9_common.c:877 arm7_9_halt(): target was already halted
Info: server.c:67 add_connection(): accepted 'gdb' connection from 0
Warning: gdb_server.c:246 gdb_get_packet(): acknowledgment received,
but no packet pending

4) Via the gdb window, enter the commands:
monitor soft_reset_halt
monitor arm7_9 sw_bkpts enable

Output from the OpenOCD window:
Warning: jtag.c:1068 jtag_read_buffer(): value captured during scan
didn't pass the requested check: captured: 0x00 check_value:
0x01 check_mask: 0x0f
Error: arm7_9_common.c:503 arm7_9_enable_sw_bkpts(): error writing
EmbeddedICE registers to enable sw breakpoints

At this point, OpenOCD terminates and I return the the shell prompt
[peter@LxMain 3180_blink_int_ram]$
The only way that I seem to be able to avoid this problem is by setting the mask value to 0 for the 2nd JTAG TAP. I am sure that this creates a situation where critical errors will be masked but I am not sure how to avoid it. Perhaps I need to move to another JTAG device such as the Amontec.

Cheers,
Peter Start a New Thread

Hello Peter,

On Friday 20 April 2007 16:15:40 p...@akamina.com wrote:
> Hello Dominic,
>
> Thanks for the offer. I am indeed interested in seeing what you have done.
> Since I too am working with the Phytec board the differences in the code
> would not be an issue.
>
I'll do some cleanup and put it online during the weekend.

> The header file
> that I have included is the file that is available from the Keil website.
> The copyright information in the file indicates that the header file was
> developed by Philips. I have assumed that Philips would be ok with this
> file being distributed for use with their part.
>
Heh, I'm a bit suspicious when a header file starts with
* Copyright(C) 2006, Philips Semiconductor
* All rights reserved.
Of course I doubt they'll sue you for using it, but I've put my example code
under the terms of the GPL, and decided to better be on the safe side.
Putting the header file under a BSD style license might make it interesting
for a wider variety of applications, so I'll probably make that change before
putting it online.

> I am still revising the document that descibes the set up and use of the
> software (IDE, OpenOCD, ...) to include the work on the 3180. The version
> that I have so far is available at:
> http://akamina.com/Reports/GnuArm_Setup_Guide.pdf. It includes the Olimex
> 2148 and the Keil MCB STR9 and a draft of the 3180 section.
>
Nice tutorial. Something describing a setup for a Linux environment really has
been missing.

> <====> Here is a log of my attempts to use the correct OpenOCD configuration. I
> have updated OpenOCD to the latest version and have used gdb directly to
> control the interaction between gdb and OpenOCD.
>
> My config file (with your recommendations):
> #daemon configuration
> telnet_port 4000
> gdb_port 2000
>
> #interface
> interface parport
> parport_port 0
> parport_cable wiggler
> jtag_speed 0
>
> #use combined on interfaces or targets that can't set TRST/SRST separately
> reset_config trst_and_srst
>
> #jtag scan chain
> jtag_device 4 0x1 0xf 0xe
> jtag_device 4 0x1 0xf 0xe
>
> jtag_nsrst_delay 200
> jtag_ntrst_delay 200
>
> #target configuration
> daemon_startup attach
>
> #target
> target arm926ejs little reset_halt 1
> #arm7_9 etm
> arm7_9 etm 0
> #arm7_9 etb
> arm7_9 etb 0 0
>
> working_area 0 0x08000000 16384 nobackup
>
> #nand configuration
> #nand device [controller specific arguments]
> nand device lpc3180 0 13000
>
> The log below combines my gdb commands with the response from OpenOCD.
> 1) Start OpenOCD (openocd -f openocd.cfg)
> Info: openocd.c:86 main(): Open On-Chip Debugger (2007-04-11 16:20
> CEST)
>
> 2) Start gdb session (arm-elf-gdb)
>
> Output from the OpenOCD window:
> Info: server.c:67 add_connection(): accepted 'gdb' connection from 0

This is really strange - Just starting a GDB session shouldn't open a
connection to the OpenOCD. Do you have a .gdbinit file that automatically
executes some commands?

> Warning: gdb_server.c:246 gdb_get_packet(): acknowledgment received,
> but no packet pending
This shouldn't be a problem. I haven't seen this message for some time, but
IIRC some version of GDB sent an acknowledgment on the initial connection.

> Warning: jtag.c:1068 jtag_read_buffer(): value captured during scan
> didn't pass the requested check: captured: 0x0f check_value:
> 0x01 check_mask: 0x0f
I'm not completely sure why this happens, and I'm seeing it on my LPC3180,
too, but it didn't harm debugging yet. There is a problem when accessing the
ETB before accessing the ARM926 core (I'm currently developing support for
the ETB), so maybe I'll look into this next week or so, if it proves to be a
real problem.

> 3) Via the gdb interface, enter the command: target remote localhost:2000.
>
> When gdb indicates that there is a program already being debugged,
> enter y to kill it.
>
> Output from the OpenOCD window:
> Info: server.c:367 server_loop(): dropped 'gdb' connection
> Warning: arm7_9_common.c:877 arm7_9_halt(): target was already halted
> Info: server.c:67 add_connection(): accepted 'gdb' connection from 0
> Warning: gdb_server.c:246 gdb_get_packet(): acknowledgment received,
> but no packet pending
>
Guess the same explanation as above applies here, too.

> 4) Via the gdb window, enter the commands:
> monitor soft_reset_halt
> monitor arm7_9 sw_bkpts enable
>
> Output from the OpenOCD window:
> Warning: jtag.c:1068 jtag_read_buffer(): value captured during scan
> didn't pass the requested check: captured: 0x00 check_value:
> 0x01 check_mask: 0x0f
> Error: arm7_9_common.c:503 arm7_9_enable_sw_bkpts(): error writing
> EmbeddedICE registers to enable sw breakpoints
>
> At this point, OpenOCD terminates and I return the the shell prompt
> [peter@LxMain 3180_blink_int_ram]$
>
These two commands shouldn't cause any JTAG activity...

> The only way that I seem to be able to avoid this problem is by setting the
> mask value to 0 for the 2nd JTAG TAP. I am sure that this creates a
> situation where critical errors will be masked but I am not sure how to
> avoid it. Perhaps I need to move to another JTAG device such as the
> Amontec.
>
I'll try with a Wiggler, to see if there's a problem in the JTAG layer.

> Cheers,
> Peter

Regards,

Dominic Start a New Thread

Thanks Dominic.

Here is my .gdbinit file:
set remoteaddresssize 64
set remotetimeout 999999
target remote localhost:2000

The last statement clearly opens a connection to OpenOCD. When I re-enter the command via gdb, gdb naturally complains. The right place to do this is within the gdb session itself, so I have simplified my gdbinit file by removing the target line. This change cleans up the situation but the eventual fatal error caused by entering "monitor arm7_9 sw_bkpts enable" remains.

Let me know if you find anything odd with your Wiggler tests.

Cheers,

Peter

Hello Peter,
>
>On Friday 20 April 2007 16:15:40 p...@akamina.com wrote:
>> Hello Dominic,
>>
>> Thanks for the offer. I am indeed interested in seeing what you have done.
>> Since I too am working with the Phytec board the differences in the code
>> would not be an issue.
>>
>I'll do some cleanup and put it online during the weekend.
>
>> The header file
>> that I have included is the file that is available from the Keil website.
>> The copyright information in the file indicates that the header file was
>> developed by Philips. I have assumed that Philips would be ok with this
>> file being distributed for use with their part.
>>
>Heh, I'm a bit suspicious when a header file starts with
> * Copyright(C) 2006, Philips Semiconductor
> * All rights reserved.
>Of course I doubt they'll sue you for using it, but I've put my example code
>under the terms of the GPL, and decided to better be on the safe side.
>Putting the header file under a BSD style license might make it interesting
>for a wider variety of applications, so I'll probably make that change before
>putting it online.
>
>> I am still revising the document that descibes the set up and use of the
>> software (IDE, OpenOCD, ...) to include the work on the 3180. The version
>> that I have so far is available at:
>> http://akamina.com/Reports/GnuArm_Setup_Guide.pdf. It includes the Olimex
>> 2148 and the Keil MCB STR9 and a draft of the 3180 section.
>>
>Nice tutorial. Something describing a setup for a Linux environment really has
>been missing.
>
>> Here is a log of my attempts to use the correct OpenOCD configuration. I
>> have updated OpenOCD to the latest version and have used gdb directly to
>> control the interaction between gdb and OpenOCD.
>>
>> My config file (with your recommendations):
>> #daemon configuration
>> telnet_port 4000
>> gdb_port 2000
>>
>> #interface
>> interface parport
>> parport_port 0
>> parport_cable wiggler
>> jtag_speed 0
>>
>> #use combined on interfaces or targets that can't set TRST/SRST separately
>> reset_config trst_and_srst
>>
>> #jtag scan chain
>> jtag_device 4 0x1 0xf 0xe
>> jtag_device 4 0x1 0xf 0xe
>>
>> jtag_nsrst_delay 200
>> jtag_ntrst_delay 200
>>
>> #target configuration
>> daemon_startup attach
>>
>> #target
>> target arm926ejs little reset_halt 1
>> #arm7_9 etm
>> arm7_9 etm 0
>> #arm7_9 etb
>> arm7_9 etb 0 0
>>
>> working_area 0 0x08000000 16384 nobackup
>>
>> #nand configuration
>> #nand device [controller specific arguments]
>> nand device lpc3180 0 13000
>>
>> The log below combines my gdb commands with the response from OpenOCD.
>> 1) Start OpenOCD (openocd -f openocd.cfg)
>> Info: openocd.c:86 main(): Open On-Chip Debugger (2007-04-11 16:20
>> CEST)
>>
>> 2) Start gdb session (arm-elf-gdb)
>>
>> Output from the OpenOCD window:
>> Info: server.c:67 add_connection(): accepted 'gdb' connection from 0
>
>This is really strange - Just starting a GDB session shouldn't open a
>connection to the OpenOCD. Do you have a .gdbinit file that automatically
>executes some commands?
>
>> Warning: gdb_server.c:246 gdb_get_packet(): acknowledgment received,
>> but no packet pending
>This shouldn't be a problem. I haven't seen this message for some time, but
>IIRC some version of GDB sent an acknowledgment on the initial connection.
>
>> Warning: jtag.c:1068 jtag_read_buffer(): value captured during scan
>> didn't pass the requested check: captured: 0x0f check_value:
>> 0x01 check_mask: 0x0f
>I'm not completely sure why this happens, and I'm seeing it on my LPC3180,
>too, but it didn't harm debugging yet. There is a problem when accessing the
>ETB before accessing the ARM926 core (I'm currently developing support for
>the ETB), so maybe I'll look into this next week or so, if it proves to be a
>real problem.
>
>> 3) Via the gdb interface, enter the command: target remote localhost:2000.
>>
>> When gdb indicates that there is a program already being debugged,
>> enter y to kill it.
>>
>> Output from the OpenOCD window:
>> Info: server.c:367 server_loop(): dropped 'gdb' connection
>> Warning: arm7_9_common.c:877 arm7_9_halt(): target was already halted
>> Info: server.c:67 add_connection(): accepted 'gdb' connection from 0
>> Warning: gdb_server.c:246 gdb_get_packet(): acknowledgment received,
>> but no packet pending
>>
>Guess the same explanation as above applies here, too.
>
>> 4) Via the gdb window, enter the commands:
>> monitor soft_reset_halt
>> monitor arm7_9 sw_bkpts enable
>>
>> Output from the OpenOCD window:
>> Warning: jtag.c:1068 jtag_read_buffer(): value captured during scan
>> didn't pass the requested check: captured: 0x00 check_value:
>> 0x01 check_mask: 0x0f
>> Error: arm7_9_common.c:503 arm7_9_enable_sw_bkpts(): error writing
>> EmbeddedICE registers to enable sw breakpoints
>>
>> At this point, OpenOCD terminates and I return the the shell prompt
>> [peter@LxMain 3180_blink_int_ram]$
>>
>These two commands shouldn't cause any JTAG activity...
>
>> The only way that I seem to be able to avoid this problem is by setting the
>> mask value to 0 for the 2nd JTAG TAP. I am sure that this creates a
>> situation where critical errors will be masked but I am not sure how to
>> avoid it. Perhaps I need to move to another JTAG device such as the
>> Amontec.
>>
>I'll try with a Wiggler, to see if there's a problem in the JTAG layer.
>
>> Cheers,
>> Peter
>
>Regards,
>
>Dominic Start a New Thread

Hello Peter,

On Friday 20 April 2007 20:49:02 p...@akamina.com wrote:
> This change cleans up the situation but the
> eventual fatal error caused by entering "monitor arm7_9 sw_bkpts enable"
> remains.
>
I was wrong when I thought that soft_reset_halt and enable_sw_bkpts wouldn't
cause JTAG activity. The former is supposed to turn off the caches, so it's
fine that it accesses the JTAG interface, but the latter one should be a NOP
on ARM926EJ-S, as it implements the ARMv5TE architecture which includes the
BKPT instruction. I've fixed that bug locally, and will commit it with the
next set of changes.

> Let me know if you find anything odd with your Wiggler tests.
>
I'm basically seeing the same behaviour you're seeing - the OpenOCD exits
because of a fatal communication error. I'll have to look into this a bit
further.

Meanwhile, you can find my LPC3180 example code at http://mmd.ath.cx/lpc/

Best regards,

Dominic Start a New Thread

Hello Peter,

following up on my last mail, here's what I found out about the problem you're
seeing:

There seems to be a problem specific to the ARM926EJ-S (I've been able to
verify the problem exists on a AT91SAM9260, too) that causes the TAP
controller to fail after accessing the CP15 coprocessor via JTAG. Just
selecting and deselecting the CP15 scan-chain (15) doesn't cause a problem,
but executing a CP15 operation like reading the ID register results in wrong
data (all bits '1' or '0') being output on TDO during the next IR scan. The
ARM manual doesn't contain any information on this problem.

Notwithstanding the wrong output, the data input through TDI is correctly read
and the desired instruction gets selected. This can be verified by examining
the value returned during a SCAN_N data register scan - the fixed pattern
b10000 is returned fine.

The reason why this didn't cause problems using a FT2232 based dongle but
caused the Wiggler to fail is that the JTAG queue handling code was slightly
different. The FT2232 just reported the error, and continued, whereas the
Wiggler aborted queue execution after a check failed.

Currently this seems to be the ARM926EJ-S' fault, as the underlying JTAG
operations are very basic, and the failure is easily reproducable. I've
written a workaround that executes a dummy IR scan on every CP15 operation,
but of course this isn't an ideal solution. I'll see if I can find more
information on this problem, but until then the workaround has to be enough.

Unfortunately the Berlios system is down at the moment, so I can't commit my
changes to the SVN server. You can find a patch against R141 at
http://mmd.ath.cx/openocd/openocd_20070423_0.patch
This should allow you to work with both Wigglers and FT2232 based dongles.

Regards,

Dominic Rath

On Saturday 21 April 2007 11:52:00 Dominic Rath wrote:
> Hello Peter,
>
> On Friday 20 April 2007 20:49:02 p...@akamina.com wrote:
> > This change cleans up the situation but the
> > eventual fatal error caused by entering "monitor arm7_9 sw_bkpts enable"
> > remains.
>
> I was wrong when I thought that soft_reset_halt and enable_sw_bkpts
> wouldn't cause JTAG activity. The former is supposed to turn off the
> caches, so it's fine that it accesses the JTAG interface, but the latter
> one should be a NOP on ARM926EJ-S, as it implements the ARMv5TE
> architecture which includes the BKPT instruction. I've fixed that bug
> locally, and will commit it with the next set of changes.
>
> > Let me know if you find anything odd with your Wiggler tests.
>
> I'm basically seeing the same behaviour you're seeing - the OpenOCD exits
> because of a fatal communication error. I'll have to look into this a bit
> further.
>
> Meanwhile, you can find my LPC3180 example code at http://mmd.ath.cx/lpc/
>
> Best regards,
>
> Dominic Start a New Thread