openocd-devel — Discuss development of OpenOCD

Re: [Openocd-development] Build problems with xscale/debug_handler.bin

[David B. <da...@pa...>]

On Monday 12 October 2009, Øyvind Harboe wrote:
> I doesn't help if I specify the absolute path to configure.
> 
> It says "current location", not "current directory". I"current location"
> the same as "present working directory" or the location of the .S file?
> 
> It builds fine when build dir == src dir. It's the
> build dir != src dir whcih is broken.

Something needs to add a "-I$(SRCDIR)", or equivalent, to
the options used to invoke the assembler.

- dave

Re: [Openocd-development] Build problems with xscale/debug_handler.bin

[Øyvind H. <oyv...@zy...>]

On Mon, Oct 12, 2009 at 8:44 PM, David Brownell <da...@pa...> wrote:
> On Monday 12 October 2009, Øyvind Harboe wrote:
>> > Maybe a "-I..." would help.  I tested with "--disable-shared" when
>> > I configured, FWIW, and don't recall those ".." components.
>>
>> I'm configuring using
>>
>> cd build
>> ../openocd/configure XXXX
>>
>>
>> Could that be the problem?
>
> I didn't know that was even supported!  :)
>
> Could be.  It seems that the ".incbin" directive [1] lost context.
> I don't know *why* it lost those cookies; but "-I" [2] is likely the
> way out... docs say current working directory is always in the search
> path, and your ".../configure" changed that from the usual case.

I doesn't help if I specify the absolute path to configure.

It says "current location", not "current directory". I"current location"
the same as "present working directory" or the location of the .S file?

It builds fine when build dir == src dir. It's the
build dir != src dir whcih is broken.



-- 
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer

Re: [Openocd-development] Build problems with xscale/debug_handler.bin

[David B. <da...@pa...>]

On Monday 12 October 2009, Øyvind Harboe wrote:
> > Maybe a "-I..." would help.  I tested with "--disable-shared" when
> > I configured, FWIW, and don't recall those ".." components.
> 
> I'm configuring using
> 
> cd build
> ../openocd/configure XXXX
> 
> 
> Could that be the problem?

I didn't know that was even supported!  :)

Could be.  It seems that the ".incbin" directive [1] lost context.
I don't know *why* it lost those cookies; but "-I" [2] is likely the
way out... docs say current working directory is always in the search
path, and your ".../configure" changed that from the usual case.

- Dave


[1] http://www.redhat.com/docs/manuals/enterprise/RHEL-3-Manual/gnu-assembler/incbin.html
[2] http://www.redhat.com/docs/manuals/enterprise/RHEL-3-Manual/gnu-assembler/i.html

Re: [Openocd-development] Default behavior when detaching GDB

[Øyvind H. <oyv...@zy...>]

How's this patch?




-- 
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer

Re: [Openocd-development] NS9360 Unknown EmbeddedICE version and halt problem

[Henry M. <hen...@gm...>]

> > > Error: ns9360.cpu: IR capture error; saw 0x09 not 0x01
> > > 
> > > So I either change the irLen to 3 or the mask to 0x7 or the
> > > irCaputure to 0x9. 
> > 
> > It's an ARM926 you say?  If so, irlen == 4.  You shouldn't
> > actually neet to specify the IR mask or capture values, by
> > the way ...
> 
> Thanks, I removed irCapture and mask and I got no additional error (but
> still have the wrong EmbeddedICE version).
> 

By the way, I just found the BSDL file for the NS9360 CPU. Not sure if that is helping, but it says (things like):

-- Specifies the number of bits in the instruction register.
   
   attribute INSTRUCTION_LENGTH of cooper: entity is 3;

-- Specifies the bit pattern that is loaded into the instruction register when 
-- the TAP controller passes through the Capture-IR state. The standard mandates 
-- that the two LSBs must be "01". The remaining bits are design specific.
   
   attribute INSTRUCTION_CAPTURE of cooper: entity is "001";


It also lists the part number and manufacturer ID, which is correctly detected by OpenOCD. It also mentions the boundary scan registers. Now I have read in the OpenOCD documentation about JTAG router controllers and boundary scan tap controllers (although OpenOCD only reports one tap controller). Is it possible that the boundary scan registers are kind of in the way of reading the EmbeddedICE version? Since I don't know anything about EmbeddedICE or Boundary Scans Registers, I'm slightly lost here :) 


The URL for the BSDL file is: http://ftp1.digi.com/support/documentation/hwtoolkit_ns9360.bsdl



Thanks in advance,


Henry


-- 
Hi! I'm a .signature virus! Copy me into your
~/.signature to help me spread!

Re: [Openocd-development] NS9360 Unknown EmbeddedICE version and halt problem

[Henry M. <hen...@gm...>]

Hi,

> > Error: ns9360.cpu: IR capture error; saw 0x09 not 0x01
> > 
> > So I either change the irLen to 3 or the mask to 0x7 or the
> > irCaputure to 0x9. 
> 
> It's an ARM926 you say?  If so, irlen == 4.  You shouldn't
> actually neet to specify the IR mask or capture values, by
> the way ...

Thanks, I removed irCapture and mask and I got no additional error (but still have the wrong EmbeddedICE version).

> Maybe your clock speed is too fast.  I saw a case not long
> ago where a too-fast JTAG clock caused bit patterns to shift
> a few bits in either direction.  A divide-by-ten of the
> clock the CPU was using seemed to behave.

I also tried changing the speed. OpenOCD normally runs (the JTagkey) with 6MHz, but changing the speed to 1, 2, 3, 4Mhz or even 10kHz does not change anything.

> You've got some kind of communication error; I'm rather
> certain an ARM9926 chip will say "version 6" when all is
> acting fine.

I was also wondering about the reset lines. When I start OpenOCD and it reads the EmbeddedICE version (and idCode and all), it does not reset the tap controller (TRST?) or anything, does it?

If that is true, then the problem seems not to be related to a reset line misconfiguration? (btw: the board is waiting in u-boot prompt)



-- 
Hi! I'm a .signature virus! Copy me into your
~/.signature to help me spread!

Re: [Openocd-development] Default behavior when detaching GDB

[Luca O. <lot...@de...>]

Øyvind Harboe ha scritto:
> On Mon, Oct 12, 2009 at 4:29 PM, Luca Ottaviano <lot...@de...> wrote:
>> Finishing my original email...
>>
>> Øyvind Harboe ha scritto:
>>> I think I'd like to remove gdb_detach command.
>> You mean the event gdb-detach?
> 
> No. The events stay. This is the gdb_detach command. In fact you
> raise a good point, if gdb_detach causes something to happen,
> then the events can't "undo" that necessarily,  i.e. another argument
> to retire gdb_detach. It would leave the events 100% in control
> over what happens.

Ah, I didn't remember there was also a gdb_detach command. :)

I'd say to remove the command, since it duplicates functionality that we 
already expose to the user through the gdb-detach hook.
-- 
Luca Ottaviano <lot...@de...>
BeRTOS developer -> http://dev.bertos.org

Re: [Openocd-development] Default behavior when detaching GDB

[Øyvind H. <oyv...@zy...>]

On Mon, Oct 12, 2009 at 4:29 PM, Luca Ottaviano <lot...@de...> wrote:
> Finishing my original email...
>
> Øyvind Harboe ha scritto:
>> I think I'd like to remove gdb_detach command.
>
> You mean the event gdb-detach?

No. The events stay. This is the gdb_detach command. In fact you
raise a good point, if gdb_detach causes something to happen,
then the events can't "undo" that necessarily,  i.e. another argument
to retire gdb_detach. It would leave the events 100% in control
over what happens.

gdb_detach should be 100% equivalent to writing some code
in the gdb-detach handler, i.e. superfluous.


-- 
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer

Re: [Openocd-development] Default behavior when detaching GDB

[Luca O. <lot...@de...>]

Finishing my original email...

Øyvind Harboe ha scritto:
> I think I'd like to remove gdb_detach command.

You mean the event gdb-detach?
I'm using it to shutdown openocd when done debugging. In particular, I
have a GUI and launch openocd on request; I find it cleaner (and easier)
to shut down openocd into the hook instead of killing the process.

> 
> The current default behavior when attaching GDB is to do
> nothing. The GDB init script can e.g. reset or halt the
> target as need be.
> 
> Similarly, I'd like to make gdb detach do nothing. If need
> be the user can do nothing, halt, rest, etc. if he wants
> to, no need for a special command or option that I can see...

The hooks are interesting, even if the default action is to do nothing.
Unless they *really* mess up the code, my vote is for keeping both of 
the hooks.
-- 
Luca Ottaviano <lot...@de...>
BeRTOS developer -> http://dev.bertos.org

[Openocd-development] iMX3x arm11 progress

[Øyvind H. <oyv...@zy...>]

I'm working on iMX351 here and making a fair bit of progress,
fixed and committed a handful of fixes today.

I can now kinda load & debug RedBoot from the Freescale kits, but
I'm struggling with reset. It seems that the arm11 code does
not assert srst. When I try to do so, things go pear-shaped
(error messages include "JTAG communication error SCREG
SCAN OUT 0x07").

Anyone out there with iMX3x hardware and experience?

Comments and hints welcome!


-- 
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer

Re: [Openocd-development] Config file for xilinx xcr3256

[Øyvind H. <oyv...@zy...>]

Committed to tcl/cpld.




-- 
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer

[Openocd-development] Default behavior when detaching GDB

[Øyvind H. <oyv...@zy...>]

I think I'd like to remove gdb_detach command.

The current default behavior when attaching GDB is to do
nothing. The GDB init script can e.g. reset or halt the
target as need be.

Similarly, I'd like to make gdb detach do nothing. If need
be the user can do nothing, halt, rest, etc. if he wants
to, no need for a special command or option that I can see...

Comments?

-- 
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer

Re: [Openocd-development] Build problems with xscale/debug_handler.bin

[Øyvind H. <oyv...@zy...>]

On Mon, Oct 12, 2009 at 1:11 PM, David Brownell <da...@pa...> wrote:
> On Monday 12 October 2009, Øyvind Harboe wrote:
>> I'm not sure why I get this error.
>>
>> If I modify xscale_debug.S to use absolute path,
>> then it builds fine.
>>
>> make[3]: Entering directory `/home/oyvind/workspace/build/src/target'
>> /bin/sh ../../libtool --mode=compile gcc -std=gnu99  -g -O2 -c -o
>> xscale_debug.lo ../../../openocd/src/target/xscale_debug.S
>> libtool: compile:  gcc -std=gnu99 -g -O2 -c
>> ../../../openocd/src/target/xscale_debug.S -o xscale_debug.o
>> ../../../openocd/src/target/xscale_debug.S: Assembler messages:
>> ../../../openocd/src/target/xscale_debug.S:6: Error: file not found:
>> xscale/debug_handler.bin
>
> Maybe a "-I..." would help.  I tested with "--disable-shared" when
> I configured, FWIW, and don't recall those ".." components.

I'm configuring using

cd build
../openocd/configure XXXX


Could that be the problem?


-- 
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer

Re: [Openocd-development] Build problems with xscale/debug_handler.bin

[David B. <da...@pa...>]

On Monday 12 October 2009, Øyvind Harboe wrote:
> I'm not sure why I get this error.
> 
> If I modify xscale_debug.S to use absolute path,
> then it builds fine.
> 
> make[3]: Entering directory `/home/oyvind/workspace/build/src/target'
> /bin/sh ../../libtool --mode=compile gcc -std=gnu99  -g -O2 -c -o
> xscale_debug.lo ../../../openocd/src/target/xscale_debug.S
> libtool: compile:  gcc -std=gnu99 -g -O2 -c
> ../../../openocd/src/target/xscale_debug.S -o xscale_debug.o
> ../../../openocd/src/target/xscale_debug.S: Assembler messages:
> ../../../openocd/src/target/xscale_debug.S:6: Error: file not found:
> xscale/debug_handler.bin

Maybe a "-I..." would help.  I tested with "--disable-shared" when
I configured, FWIW, and don't recall those ".." components.

Re: [Openocd-development] reset_config in target and board scripts

[Øyvind H. <oyv...@zy...>]

On Mon, Oct 12, 2009 at 12:10 PM, David Brownell <da...@pa...> wrote:
> On Sunday 11 October 2009, Øyvind Harboe wrote:
>> I would like to see reset_config's in the target config
>> scripts so that the target config scripts are useful
>> standalone against PCBs that use the part in unclever
>> ways.
>
> As a rule, that won't work...

But isn't the case where one wants something else
than the target default reset_config really the exception?




-- 
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer

[Openocd-development] Build problems with xscale/debug_handler.bin

[Øyvind H. <oyv...@zy...>]

I'm not sure why I get this error.

If I modify xscale_debug.S to use absolute path,
then it builds fine.

make[3]: Entering directory `/home/oyvind/workspace/build/src/target'
/bin/sh ../../libtool --mode=compile gcc -std=gnu99  -g -O2 -c -o
xscale_debug.lo ../../../openocd/src/target/xscale_debug.S
libtool: compile:  gcc -std=gnu99 -g -O2 -c
../../../openocd/src/target/xscale_debug.S -o xscale_debug.o
../../../openocd/src/target/xscale_debug.S: Assembler messages:
../../../openocd/src/target/xscale_debug.S:6: Error: file not found:
xscale/debug_handler.bin


-- 
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer

Re: [Openocd-development] reset_config in target and board scripts

[David B. <da...@pa...>]

On Sunday 11 October 2009, Øyvind Harboe wrote:
> I would like to see reset_config's in the target config
> scripts so that the target config scripts are useful
> standalone against PCBs that use the part in unclever
> ways.

As a rule, that won't work...

There are a few special cases where it could make
sense though ... e.g. targets designed so they just
don't work properly for JTAG debug without both SRST
and TRST signals.

Re: [Openocd-development] NS9360 Unknown EmbeddedICE version and halt problem

[R.Doss <do...@gm...>]

Øyvind Harboe schrieb:
> Would you mind creating a config script for OpenOCD head and
> submit for inclusion in the target config scripts library?
>
>   

I have no hardware.
T wrote this gdb file in my old company.

Rene



> Some comments below:
>
>   
>> # Reset the chip to get to a known state.
>>
>> monitor
>> monitor halt
>>     
>
> Add a reset init sequence and use "monitor reset init"
>
>   
>> monitor mww 0xA0700000  0x00000001
>>     
>
> All of these should go into the "reset init sequence". This
> cleans up the .gdbinit script and allows others to tap into
> the work you have put into reading the datasheets.
>
>
>   
>> # Setup GDB FOR FASTER DOWNLOADS
>> set remote memory-write-packet-size 1024
>> set remote memory-write-packet-size fixed
>>     
>
> This actually *slows down* transfer with the latest openocd
> version. The size of the packets are negotiated automatically
> so, just delete the two lines above and things will go faster.
>
>
>   

Re: [Openocd-development] Any ideas how OpenOCD should handle virtual addressing and cache coherency?

[Yauheni K. <yau...@gm...>]

Hi!

On Thu, Oct 1, 2009 at 9:41 PM, Magnus Lundin <lu...@ml...> wrote:

> Any ideas how OpenOCD should handle virtual addressing and cache coherency?
>

[..]


> I am planning to implement these for the ARMv7A/CortexA8 and I am
> interested in input on what you think should be the behaviour of these
> functions in terms of VA/PA translations and cache coherency operations.
>
> I am not interested in designing a super complicated framework, rather I
> would like some clear and reasonable simple rules when to use VA/PA
> translation, when to clear caches and when to invalidate caches and how
> this is mapped to user commands.
>

Any progress on it?

I have a simple "works for me" implementation of memory access with cpu
instead of AHB and virt2phys using cp15 for cortex_a8, but already got a
problem
with interfaces: there is only one set of functions on the high target level
and
if I switch them to mmu variants, I cannot enable debug on omap from tcl
config,
direct access is required there.

Re: [Openocd-development] [patch/rfc] simplify XScale debug handler installation

[David B. <da...@pa...>]

On Sunday 11 October 2009, Øyvind Harboe wrote:
> > On top of that, I've got the following more substantive change.
> > It should get rid of one regression ... comments?  I'm inclined
> > to just check it in.  Does anyone really need to support debug
> > hosts that aren't using ELF and GNU AS?
> 
> I'd say commit. Looks good. You update TODO though there
> is a bug you've fixed ;-)

Updated it *because* the bug is fixed.  The TODO list just
got a wee bit smaller!  :)

OK, I'll check that in soon.

I'll ask the folk using XScale to sanity check; I doubt this
set of XScale patches would have broken anything, but I can
only test on this one ancient PXA255 board I've got.

- Dave

Re: [Openocd-development] NS9360 Unknown EmbeddedICE version and halt problem

[David B. <da...@pa...>]

On Monday 12 October 2009, Henry Margies wrote:
> Error: unknown EmbeddedICE version (comms ctrl: 0x00000000)

That's quite wrong...

I saw wierdness out of an EmbeddedICE for quite a while
until I fixed a bunch of reset/init problems.  There were
basically two groups:

 - OpenOCD bugs.  The bugs I found are all fixed in the
   current code.  Are you using current code, from GIT?

 - A board setup bug ... I needed "srst_pulls_trst"
   since it was working around a bug in early silicon
   (by wiring MPU_RESET to PWRUP_RESET).

Strange EmbeddedICE behavior seemed to be caused by the
latter problem.  After fixing the first batch, it was
connecting to the board just fine ... and the problems
only came when I tried "reset".

- Dave

[Openocd-development] Retire arm11 no_increment

[Øyvind H. <oyv...@zy...>]

Can anyone come up with a reason why we should have the
"arm11 no_increment" option?

This seems simply to break memory writes.

At best this should be a compile time option used only temporarily by
openocd developers for testing purposes.

Does anyone know why this option is here?

I suspect that in the mists of time when arm11 code was
being debugged for the first time, it served some purpose...

-- 
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer

Re: [Openocd-development] NS9360 Unknown EmbeddedICE version and halt problem

[Øyvind H. <oyv...@zy...>]

Would you mind creating a config script for OpenOCD head and
submit for inclusion in the target config scripts library?

Some comments below:

> # Reset the chip to get to a known state.
>
> monitor
> monitor halt

Add a reset init sequence and use "monitor reset init"

> monitor mww 0xA0700000  0x00000001

All of these should go into the "reset init sequence". This
cleans up the .gdbinit script and allows others to tap into
the work you have put into reading the datasheets.


> # Setup GDB FOR FASTER DOWNLOADS
> set remote memory-write-packet-size 1024
> set remote memory-write-packet-size fixed

This actually *slows down* transfer with the latest openocd
version. The size of the packets are negotiated automatically
so, just delete the two lines above and things will go faster.


-- 
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer

Re: [Openocd-development] NS9360 Unknown EmbeddedICE version and halt problem

[R.Doss <do...@gm...>]

Hallo

I had work with openocd on NS9360.
It is an older config type you have to adapt it!
Also a have written a gdb init script. This is set in your register the
correct values.
You can also put it in you config script.

siehe Anhang.

Best regards Rene


Henry Margies schrieb:
> Hi list,
>
> I have some difficulties getting OpenOCD and a ns9360 based board working. The NS9360 has an Arm926EJS CPU.
>
> One problem is, that OpenOCD detects an unknown EmbeddedICE version:
>
> Debug: 74 230 openocd.c:142 handle_init_command(): jtag init complete
> Debug: 75 235 embeddedice.c:206 embeddedice_build_reg_cache(): Embedded ICE version 0
> Error: 76 235 embeddedice.c:270 embeddedice_build_reg_cache(): unknown EmbeddedICE version (comms ctrl: 0x00000000)
> Debug: 77 235 arm7_9_common.c:61 arm7_9_clear_watchpoints(): -
> Debug: 78 235 embeddedice.c:452 embeddedice_write_reg(): 12: 0x00000000
> Debug: 79 235 embeddedice.c:452 embeddedice_write_reg(): 20: 0x00000000
>
> Not sure if that is the reason why "halt" is not working.
>
> Debug: 90 20725 target.c:2024 handle_halt_command(): -
> Debug: 91 20725 arm7_9_common.c:1326 arm7_9_halt(): target->state: running
> Debug: 92 20725 embeddedice.c:452 embeddedice_write_reg(): 0: 0x00000000
> Debug: 93 20727 target.c:2003 target_wait_state(): waiting for target halted...
> Info : 95 21727 target.c:405 target_poll(): Halt timed out, wake up GDB.
> Debug: 96 21727 target.c:861 target_call_event_callbacks(): target event 4 (gdb-halt)
> Error: 105 25728 target.c:2014 target_wait_state(): timed out while waiting for target halted
> Debug: 106 25729 command.c:444 run_command(): Command failed with error code -4
>
>
> My configuration is "basically" this (based on the ConnectCore Wi-9C config):
> jtag newtap ns9360 cpu -irlen 4 -ircapture 0x9 -irmask 0x0f -expected-id 0x09105031
> target create ns9360.cpu arm926ejs -endian little -chain-position ns9360.cpu -variant arm926ejs
> reset_config trst_and_srst
>
> OpenOCD starts with this output:
>
> trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain
> Info : clock speed 6000 kHz
> Info : JTAG tap: ns9360.cpu tap/device found: 0x09105031 (mfg: 0x018, part: 0x9105, ver: 0x0)
> Error: unknown EmbeddedICE version (comms ctrl: 0x00000000)
>
> I tried version 0.1.0 and 0.2.0 and the latest GIT (0.3.0-dev-00345). The error is always the same. (btw: I'm using an Amontec JTAGkey, if that is of any relevance)
>
> I appreciate any help or hints, maybe it is just a tiny configuration problem after all?
>
>
> Thanks,
>
> Henry
>   

[Openocd-development] NS9360 Unknown EmbeddedICE version and halt problem

[Henry M. <hen...@gm...>]

Hi list,

I have some difficulties getting OpenOCD and a ns9360 based board working. The NS9360 has an Arm926EJS CPU.

One problem is, that OpenOCD detects an unknown EmbeddedICE version:

Debug: 74 230 openocd.c:142 handle_init_command(): jtag init complete
Debug: 75 235 embeddedice.c:206 embeddedice_build_reg_cache(): Embedded ICE version 0
Error: 76 235 embeddedice.c:270 embeddedice_build_reg_cache(): unknown EmbeddedICE version (comms ctrl: 0x00000000)
Debug: 77 235 arm7_9_common.c:61 arm7_9_clear_watchpoints(): -
Debug: 78 235 embeddedice.c:452 embeddedice_write_reg(): 12: 0x00000000
Debug: 79 235 embeddedice.c:452 embeddedice_write_reg(): 20: 0x00000000

Not sure if that is the reason why "halt" is not working.

Debug: 90 20725 target.c:2024 handle_halt_command(): -
Debug: 91 20725 arm7_9_common.c:1326 arm7_9_halt(): target->state: running
Debug: 92 20725 embeddedice.c:452 embeddedice_write_reg(): 0: 0x00000000
Debug: 93 20727 target.c:2003 target_wait_state(): waiting for target halted...
Info : 95 21727 target.c:405 target_poll(): Halt timed out, wake up GDB.
Debug: 96 21727 target.c:861 target_call_event_callbacks(): target event 4 (gdb-halt)
Error: 105 25728 target.c:2014 target_wait_state(): timed out while waiting for target halted
Debug: 106 25729 command.c:444 run_command(): Command failed with error code -4


My configuration is "basically" this (based on the ConnectCore Wi-9C config):
jtag newtap ns9360 cpu -irlen 4 -ircapture 0x9 -irmask 0x0f -expected-id 0x09105031
target create ns9360.cpu arm926ejs -endian little -chain-position ns9360.cpu -variant arm926ejs
reset_config trst_and_srst

OpenOCD starts with this output:

trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain
Info : clock speed 6000 kHz
Info : JTAG tap: ns9360.cpu tap/device found: 0x09105031 (mfg: 0x018, part: 0x9105, ver: 0x0)
Error: unknown EmbeddedICE version (comms ctrl: 0x00000000)

I tried version 0.1.0 and 0.2.0 and the latest GIT (0.3.0-dev-00345). The error is always the same. (btw: I'm using an Amontec JTAGkey, if that is of any relevance)

I appreciate any help or hints, maybe it is just a tiny configuration problem after all?


Thanks,

Henry
-- 
Hi! I'm a .signature virus! Copy me into your
~/.signature to help me spread!