> I would first check the board schematic and make sure all the JTAG lines are
> hooked up appropriately and have correct pull-up/downs where necessary.
> From there, you would need someone more familiar with the ARM7/9 JTAG
> commands to figure out what it is trying to do.
Well, the pins are pro
On Thu, Nov 20, 2008 at 7:47 AM, Kees Jongenburger
<[EMAIL PROTECTED]> wrote:
> On Wed, Nov 19, 2008 at 10:42 PM, Øyvind Harboe <[EMAIL PROTECTED]> wrote:
>> I don't think we should solve this as a target, but rather a
>> more generic scheme for JTAG TAP devices that come
>> and go/get reordered.
>
>> once the system is up, i issue the irscan/drscan to add the arm tap into the
>> chain and then > >change the length from 0(inactive) to 4.
While a neat trick, I'm favouring this approach:
https://lists.berlios.de/pipermail/openocd-development/2008-October/003416.html
I'd hate to work with t
On Wed, Nov 19, 2008 at 11:24 PM, David Anders <[EMAIL PROTECTED]> wrote:
>
> based on the fact that the order is fixed and they are simply inactive, i
> started testing with defining the entries in the config based on the
> discussion that had been posted using the example of the davinci on a dm
On Wed, Nov 19, 2008 at 10:42 PM, Øyvind Harboe <[EMAIL PROTECTED]> wrote:
> I don't think we should solve this as a target, but rather a
> more generic scheme for JTAG TAP devices that come
> and go/get reordered.
>
>
> Did you read up on what I/Duane designed on devices being enable/disabled?
Ye
>
> 99% of this can be done with a config file and the -c option. Something
> like:
>
> openocd -f interface/olimex-jtag-tiny-a.cfg -f target/lpc2129.cfg -c 'flash
> write_image $(TARGET).elf'
>
> That would use the included olimex interface config and the lpc2129 target
> config and simply run th
On Nov 19, 2008, at 4:13 PM, Steve Franks wrote:
openocd -interface ft2232 -ft2232_layout "olimex-jtag" -reset_config
none -jtag_device 4 0x1 0xf 0xe -target create target0 arm7tdmi -
endian little -chain-position 0 -variant arm7tdmi-s_r4 -flash bank
lpc2000 0x0 0x7d000 0 0 0 lpc2000_v2 147
>
> Our ZY1000 product uses OpenOCD like a library and builds on it.
>
> We could certainly build on a library that catered for non-MCU
> devices too :-)
>
> Could you be a bit more specific as to what you imagine this would
> entail on either end?
>
If you are talking about openocd vs. urjtag, I
Øyvind,
> I don't think we should solve this as a target, but
> rather a
> more generic scheme for JTAG TAP devices that come
> and go/get reordered.
>
>
> Did you read up on what I/Duane designed on devices being
> enable/disabled?
>
> https://lists.berlios.de/pipermail/openocd-development/200
I don't think we should solve this as a target, but rather a
more generic scheme for JTAG TAP devices that come
and go/get reordered.
Did you read up on what I/Duane designed on devices being enable/disabled?
https://lists.berlios.de/pipermail/openocd-development/2008-October/003416.html
--
Ø
On Nov 19, 2008, at 12:42 PM, Kees Jongenburger wrote:
On Wed, Nov 19, 2008 at 9:41 PM, Kees Jongenburger
<[EMAIL PROTECTED]> wrote:
On Sat, Nov 8, 2008 at 7:10 PM, David Anders
<[EMAIL PROTECTED]> wrote:
any changes/development we do to support JRC's can be tested
currently with the DM-355
On Wed, Nov 19, 2008 at 9:41 PM, Kees Jongenburger
<[EMAIL PROTECTED]> wrote:
> On Sat, Nov 8, 2008 at 7:10 PM, David Anders <[EMAIL PROTECTED]> wrote:
>> any changes/development we do to support JRC's can be tested currently with
>> the DM-355 and >related davinci boards, as they already have deb
On Sat, Nov 8, 2008 at 7:10 PM, David Anders <[EMAIL PROTECTED]> wrote:
> any changes/development we do to support JRC's can be tested currently with
> the DM-355 and related davinci boards, as they already have debug support in
> the main tree >of openocd. this gives you a reference for testing.
> I like the lib approach, as I can envision
> a front-end that pushes all the scripts into a single command-line for
> utilizing make variables without creating intermediate files.
Me too :-)
Our ZY1000 product uses OpenOCD like a library and builds on it.
We could certainly build on a library
On Mon, Nov 17, 2008 at 11:43 PM, Øyvind Harboe <[EMAIL PROTECTED]>wrote:
> > I agree totally with this, I think this would be a *GREAT* idea.
>
> So what would this mean technically?
>
I think that would have to evolve. Urjtag is certainly more aimed at logic
devices (CPLD, FPGA), and OpenOcd s
On Nov 18, 2008, at 11:58 PM, Brian Wang wrote:
Debug: 71 12592 command.c:91 script_command(): script_command - halt
Debug: 72 12592 command.c:108 script_command(): script_command -
halt, argv[0]=ocd_halt
Debug: 73 12592 target.c:1807 handle_halt_command(): -
Debug: 74 12592 arm7_9_comm
Committed.
jtag_get_device() now propagates an error instead of invoking exit()
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/target/mips_ejtag.c
===
--- src/target/mips_ejtag.c (revision 1173)
+++ src/target/mips_ejtag.
17 matches
Mail list logo
