Hello Dominic,

I just finished testing the latest version of OpenOCD (143) with the OLimex Wiggler and the LPC3180. It works perfectly. Thank you for the update.

Cheers,
Peter
> 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

An Engineer's Guide to the LPC2100 Series

Hello Dominic,

Thank you for looking into the problem. I am pleased that you were able to identify a patch so quickly. I have not yet had a chance to patch R141 and test it but I should be able to get to it later on today. I just checked the revision number of the OpenOCD repository and I see that it is still at 141. I will let you know what I find.

I have completed my initial development on the internal RAM and external SDRAM projects for the 3180. Initializing the SDRAM controller using OpenOCD commands was an interesting exercise. I want to complete the testing and documentation today and post these. I have yet to have a close look at your sample code to see how the work can be pulled together. That too, will come today or shortly.

Thanks again.

Cheers,
Peter

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

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

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

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

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

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

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