I'd like to understand jtag_add_end_state(). As some readers
may know, I want to remove it after 0.2(plan posted).
Q: If we didn't have jtag_add_end_state() today, why would we
add it?
Q: what does it achieve that a global variable doesn't?
Q: isn't jtag_add_end_state() overused? I.e. if I *onl
On Sat, May 30, 2009 at 10:22 AM, Xiaofan Chen wrote:
> Not so sure if this helps.
> http://www.nonpolynomial.com/archives/2008/04/libusb-libftdi-latency-and-my-own-stupid.php
>
> But is all depends on the usage inside OpenOCD.
>
The key is to queue large bulk transfer for libusb based applicatio
On Sat, May 30, 2009 at 12:40 AM, Magnus Lundin wrote:
> Hello list
>
> The accepted wisdom seems to be that libftdi is slower than ftd2xx,
> and when performance is low change to ftd2xx. Is this true or a myth ?
>
> Two years ago, or three, this was true, today I am not so sure.
>
> I have made
On Fri, 2009-05-29 at 17:50 -0700, David Brownell wrote:
> Provide basic documentation on the ARM ETM and ETB trace commands.
>
> Fix minor goofs in registration of the ETM commands; and whitespace
> issues in the proof-of-concept oocd_trace code. (Plus include a
> ref to Dominic's email saying t
On Fri, 2009-05-29 at 12:51 -0700, David Brownell wrote:
> Make it so the magic "reset_config" keywords can be provided in any
> order. This eliminates needless error paths, and makes it easier
> to define things at the right level (adapter, board, target).
> It also includes two other behavioral
On Friday 29 May 2009, Zach Welch wrote:
> I will apply unless there are objections.
Clean code is happy code.
Are you *sure* you want to see happy code? :)
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlio
Hi all,
The following patch encapsulates the global JTAG interface pointer,
adding a wrapper routine for the only out-of-module user.
I will apply unless there are objections.
Cheers,
Zach
==
Encapsulate the global "jtag" jtag_interface pointer:
- Add jtag_interface_quit, factored from exi
Provide basic documentation on the ARM ETM and ETB trace commands.
Fix minor goofs in registration of the ETM commands; and whitespace
issues in the proof-of-concept oocd_trace code. (Plus include a
ref to Dominic's email saying that it's just proof-of-concept code.)
Note that I'm still not sure
On Sat, May 30, 2009 at 2:32 AM, Peter Denison wrote:
>> what jlink firmware version is this?
>> mine reports:
>> J-Link ARM V6 compiled Nov 5 2008 20:49:58
>
> J-Link ARM V6 compiled Mar 3 2008 18:04:42
>
> I don't think much of their revision control, to be honest. The
> capabilities of a lot
On Fri, 2009-05-29 at 12:30 -0300, Alan Carvalho de Assis wrote:
> Hi David,
>
> On 5/29/09, David Brownell wrote:
> > On Friday 29 May 2009, Alan Carvalho de Assis wrote:
> >> Did I forget other BSDL links? Show me the link ;-)
> >
> > TI links theirs right off the generic page for each chip.
>
Make it so the magic "reset_config" keywords can be provided in any
order. This eliminates needless error paths, and makes it easier
to define things at the right level (adapter, board, target).
It also includes two other behavioral changes:
(1) When "handle_reset_config" sees a parameter err
On Fri, 29 May 2009, Spencer Oliver wrote:
>>> Still it would be very good to know if this is the problem for (at
>>> least some of) the V6 adapters.
>>
>> Unfortunately not mine... I still get a 1 returned (instead
>> of a zero) as the error code from EMU_CMD_HW_JTAG3, when I
>> send 8 bits:
>>
>
> > Still it would be very good to know if this is the problem for (at
> > least some of) the V6 adapters.
>
> Unfortunately not mine... I still get a 1 returned (instead
> of a zero) as the error code from EMU_CMD_HW_JTAG3, when I
> send 8 bits:
>
> Debug: 191 667 jlink.c:1032 jlink_usb_write
On May 29, 2009, at 19:40, Magnus Lundin wrote:
> The accepted wisdom seems to be that libftdi is slower than ftd2xx,
> and when performance is low change to ftd2xx. Is this true or a myth ?
I don't think OpenOCD's USB usage is such that the used driver has any
noticeable effect. In another p
On Fri, 29 May 2009, Magnus Lundin wrote:
>> I have attached logs of both rev, as you can see the line of interest for
>> r1508 is
>> Debug: 119 218 jlink.c:963 jlink_debug_buffer(): cf 00 08 00 ff 00
>> and r1509
>> Debug: 119 249 jlink.c:963 jlink_debug_buffer(): cf 00 07 00 7f 00
>>
>
Hello list
The accepted wisdom seems to be that libftdi is slower than ftd2xx,
and when performance is low change to ftd2xx. Is this true or a myth ?
Two years ago, or three, this was true, today I am not so sure.
I have made some small tests , single stepping arm7, uploading medium
sized fi
On Fri, 29 May 2009, Spencer Oliver wrote:
>> Spencer Oliver wrote:
> The strange thing is if i then connect using r1943 it will work !!
> Replug the jlink and it will fail with r1943, run r1192
> then all is ok again.
>>>
>>> Tracing further in.
>>> For me the break is @ r1509 (tms pa
Hi
> a bit more debugging
> The issue seesms to be in the function jlink_tap_execute
>
> the change in r1509 that causes the issue is:
> // number of full bytes (plus one if some would be left over)
> byte_length = tap_length / 8 + !!(tap_length % 8);
>
> instead of r1508
>
> /* Pad last byte
> -Original Message-
> From: Magnus Lundin [mailto:lun...@mlu.mine.nu]
> Sent: 29 May 2009 16:42
> To: Spencer Oliver
> Cc: 'Dylan Reid'; openocd-development@lists.berlios.de
> Subject: Re: [Openocd-development] jlink issues
>
> Spencer Oliver wrote:
> >>> svn head (currently r1943) fa
Spencer Oliver wrote:
>>> svn head (currently r1943) fails when connecting using a
>>>
>> v6/v5.3 jlink
>>
>>> and
>>> stm32 target.
>>> Connecting using r1192 is ok, just a little slow.
>>>
>>> The strange thing is if i then connect using r1943 it will work !!
>>> Replug the jlink an
On Fri, May 29, 2009 at 11:19 PM, David Brownell wrote:
> On Friday 29 May 2009, Alan Carvalho de Assis wrote:
>> Did I forget other BSDL links? Show me the link ;-)
>
> TI links theirs right off the generic page for each chip.
> They're like most vendors in that, so far as I can tell;
> so I'm no
> > svn head (currently r1943) fails when connecting using a
> v6/v5.3 jlink
> > and
> > stm32 target.
> > Connecting using r1192 is ok, just a little slow.
> >
> > The strange thing is if i then connect using r1943 it will work !!
> > Replug the jlink and it will fail with r1943, run r1192
> th
Hi David,
On 5/29/09, David Brownell wrote:
> On Friday 29 May 2009, Alan Carvalho de Assis wrote:
>> Did I forget other BSDL links? Show me the link ;-)
>
> TI links theirs right off the generic page for each chip.
> They're like most vendors in that, so far as I can tell;
> so I'm not sure why
On Friday 29 May 2009, Alan Carvalho de Assis wrote:
> Did I forget other BSDL links? Show me the link ;-)
TI links theirs right off the generic page for each chip.
They're like most vendors in that, so far as I can tell;
so I'm not sure why you'd want a collection of links...
So for example:
D
> svn head (currently r1943) fails when connecting using a v6/v5.3 jlink and
> stm32 target.
> Connecting using r1192 is ok, just a little slow.
>
> The strange thing is if i then connect using r1943 it will work !!
> Replug the jlink and it will fail with r1943, run r1192 then all is ok
> again.
>
On 5/29/09, Alan Carvalho de Assis wrote:
> Hi all,
>
> Follow below links to some BSDL files:
>
> NXP LPC:
> http://www.standardics.nxp.com/support/models/lpc2000/
>
> Freescale PowerPC:
> http://www.freescale.com/webapp/sps/site/overview.jsp?code=DRPPCBSDLFLS
>
> Freescale i.MX1 (too old):
> htt
Hi all,
Follow below links to some BSDL files:
NXP LPC:
http://www.standardics.nxp.com/support/models/lpc2000/
Freescale PowerPC:
http://www.freescale.com/webapp/sps/site/overview.jsp?code=DRPPCBSDLFLS
Freescale i.MX1 (too old):
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.M
On Thu, May 28, 2009 at 7:27 AM, Xiaofan Chen wrote:
> On Thu, May 28, 2009 at 6:06 AM, Peter Denison wrote:
>> The offending lines that cause it to break were added in jlink.c by Oyvind
>> in r1498. However, according to the docs (RM08001-02, dated June 30, 2008 at
>> www.segger.com), they shoul
Hi,
I have been running a few tests with regards to jlink support (win32)
svn head (currently r1943) fails when connecting using a v6/v5.3 jlink and
stm32 target.
Connecting using r1192 is ok, just a little slow.
The strange thing is if i then connect using r1943 it will work !!
Replug the jlink
Hi Duane,
On 5/28/09, Duane Ellis wrote:
>
> Imagine
> (1) being able to plug OpenOCD/JTAG into the board.
> (2) using some gerber view program - view the PCB
> (3) Double click on a pin, or a trace with a mouse
> (4) The trace starts blinking
> (5) And openocd makes the trac
On Fri, May 29, 2009 at 12:46 PM, Magnus Lundin wrote:
>>> arm7_9 dcc_downloads enable
>> dcc downloads are enabled
>>> arm7_9 fast_memory_access enable
>> fast memory access is enabled
>>> flash write_image erase firmware.bin 0x10 bin
>> auto erase enabled
>> wrote 44616 byte from file firmwa
Hi
>> arm7_9 dcc_downloads enable
>>
> dcc downloads are enabled
>
>> arm7_9 fast_memory_access enable
>>
> fast memory access is enabled
>
>> flash write_image erase firmware.bin 0x10 bin
>>
> auto erase enabled
> wrote 44616 byte from file firmware.bin in 11.045264s (3.9
On Fri, May 29, 2009 at 11:29 AM, Zach Welch wrote:
> Did you use the patch that I just posted, or did you use another fix?
> If you used mine, I will commit it; otherwise, please post the solution
> that you use.
the patch doesn't help, obtain the same error.
I have compiled openocd by hand chan
On Friday 29 May 2009 11:43:37 you wrote:
>
> Does the attached patch solve this problem?
>
Hi Zach,
No, the patch does not help, at least for me. I receive the same errors as
before.
/bin/sh ../libtool --tag=CC --mode=link
gcc -std=gnu99 -g -O2
-I/home/vylu/downloads/ftd2xx/extracted/lib
Xiaofan Chen wrote:
> Back to the basic, how can OpenOCD to wiggle a pin (forget
> about the PCB Gerber View integration part)? Is this possible?
> I am not so familiar with JTAG. But intuitively I think this is
> already difficult. Without downloading a small program to
> the chips, how do you tog
On Fri, May 29, 2009 at 2:45 PM, Rick Altherr wrote:
>> - longer usb timeouts (or non-blocking I/O?)
>
> longer timeouts are OK for 0.2.0, but I don't think they really resolve the
> issue. Non-blocking I/O is definitely not for 0.2.0 as it would require
> some major restructuring.
>
Yes I agree
On Fri, 2009-05-29 at 11:23 +0200, massimiliano cialdi wrote:
> On Fri, May 29, 2009 at 10:01 AM, Vytautas Lukenskas
> wrote:
> > On Friday 29 May 2009 10:31:25 massimiliano cialdi wrote:
> >> but make stops whit an error:
> >> libtool: link: gcc -std=gnu99 -g -O2
> >> -I/home/POWERSOFT/massimilia
On Fri, May 29, 2009 at 10:01 AM, Vytautas Lukenskas
wrote:
> On Friday 29 May 2009 10:31:25 massimiliano cialdi wrote:
>> but make stops whit an error:
>> libtool: link: gcc -std=gnu99 -g -O2
>> -I/home/POWERSOFT/massimiliano/download/openocd/libftd2xx0.4.16_x86_64
>> -Wall -Wstrict-prototypes -W
On Fri, 2009-05-29 at 13:02 +0800, Xiaofan Chen wrote:
> On Fri, May 29, 2009 at 10:04 AM, Zach Welch wrote:
> > The following tasks appear to be pending for the 0.2.0 release:
> > - fix OMAP3 problems reported by Dick Behme (or did these get resolved?)
> > - final packaging fix-ups (RPM file layo
On Fri, 2009-05-29 at 11:01 +0300, Vytautas Lukenskas wrote:
> On Friday 29 May 2009 10:31:25 massimiliano cialdi wrote:
> > but make stops whit an error:
> > libtool: link: gcc -std=gnu99 -g -O2
> > -I/home/POWERSOFT/massimiliano/download/openocd/libftd2xx0.4.16_x86_64
> > -Wall -Wstrict-prototype
On Friday 29 May 2009 10:31:25 massimiliano cialdi wrote:
> but make stops whit an error:
> libtool: link: gcc -std=gnu99 -g -O2
> -I/home/POWERSOFT/massimiliano/download/openocd/libftd2xx0.4.16_x86_64
> -Wall -Wstrict-prototypes -Wformat-security -Wextra
> -Wno-unused-parameter -Wbad-function-cast
On Thu, May 28, 2009 at 10:05 PM, Vytautas Lukenskas
wrote:
> On Thursday 28 May 2009 12:57:38 massimiliano cialdi wrote:
>> Maybe the opensource libftdi? Do I need to try with ftd2xx driver
>> provided by Amontec? I don't think that is for 64bit systems, isn't
>> it?
> You could try ftd2xx lib di
42 matches
Mail list logo
