On Wed, Jul 8, 2009 at 8:50 AM, Dominic wrote:
> On Wednesday 08 July 2009 08:42:23 Øyvind Harboe wrote:
>> On Tue, Jul 7, 2009 at 8:57 AM, Dominic wrote:
>> > On Monday 06 July 2009 23:31:47 Øyvind Harboe wrote:
>> >> Hmmm
>> >>
>> >> 838 - 729 covers a *lot* of changes but nothing
>> >> t
On Wednesday 08 July 2009 08:42:23 Øyvind Harboe wrote:
> On Tue, Jul 7, 2009 at 8:57 AM, Dominic wrote:
> > On Monday 06 July 2009 23:31:47 Øyvind Harboe wrote:
> >> Hmmm
> >>
> >> 838 - 729 covers a *lot* of changes but nothing
> >> that stands out as a suspect.
> >>
> >> If you have time
On Tue, Jul 7, 2009 at 8:57 AM, Dominic wrote:
> On Monday 06 July 2009 23:31:47 Øyvind Harboe wrote:
>> Hmmm
>>
>> 838 - 729 covers a *lot* of changes but nothing
>> that stands out as a suspect.
>>
>> If you have time to narrow this down further then that would be
>> *great*.
>>
>> 788 ha
Magnus Lundin wrote:
> Hi list,
>
> I know there is a lot of fixing to get a stable 0.2.0 so this is
> clearly for next release.
> But I also know that some folks wants to get going with CortexA8, so
> here it comes.
Great! Many thanks!
Dave, Sergey: This does look like a really *good* starti
> However, there does need to be a limit to the number of resets
> that we allow for new issues.
Agreed.
Though I believe that it is a hypothetical situation where
we discover major flaws every few days. *If* we did, then
we *should* hold off the release.
Have we discovered anything but the rese
On Wed, Jul 8, 2009 at 12:54 AM, David Brownell wrote:
> On Tuesday 07 July 2009, Ųyvind Harboe wrote:
>> The problem is that GDB will assume that the target
>> is in the halted state and query for registers.
>>
>> I'd like to see a model where OpenOCD allows a
>> connect and enters a state where i
On Wed, Jul 8, 2009 at 12:55 AM, David Brownell wrote:
> On Tuesday 07 July 2009, Ųyvind Harboe wrote:
>> This option is not used by the code. I'd like to remove it unless
>> someone can explain why we would need it in the next year or
>> so when it has *never* been used in the past.
>
> Sounds goo
Before, the ./configure --help used to list --enable-parport-ppdev
instead of the current --disable-parport-ppdev. The later suggests that
parport-ppdev is now set by default when using --enable-parport (which
would be a good thing I think) but this is apparently not the case.
Nicolas
__
On Wed, Jul 8, 2009 at 11:18 AM, Gary Carlson wrote:
> Your statement is correct. Underlying the fancy GUI of Mac OS X is really a
> variant of the BSD UNIX operating system. So it is not terribly surprising
> that both Linux and Mac behave similar in this case. Based on past
> development exper
Xiaofan,
Your statement is correct. Underlying the fancy GUI of Mac OS X is really a
variant of the BSD UNIX operating system. So it is not terribly surprising
that both Linux and Mac behave similar in this case. Based on past
development experiences I have generally observed a problem cross-ov
Hi Xiaofan,
The second part of the patch is most certainly critical to Linux and Mac OS
X systems. I am less sure about Windows since I don't have anything to
test. If the usb_reset instruction is removed, you will find that the
intermittent start-up failures that went away with the patch will b
On Wed, Jul 8, 2009 at 10:59 AM, Gary Carlson wrote:
> Hi Xiaofan,
>
> The second part of the patch is most certainly critical to Linux and Mac OS
> X systems. I am less sure about Windows since I don't have anything to
> test. If the usb_reset instruction is removed, you will find that the
> int
On Wed, Jul 8, 2009 at 12:06 AM, Gary Carlson wrote:
> I actually do development on Mac OS X rather then windows. The particular
> problem I am seeing after generating a "reset" is:
>
> jlink_usb_message failed with result=1)
> jlink_tap_execute, wrong result -107 (expected 1)
> JTAG tap: at91sam9
To all,
I posted this question on luminaries forum, and
someone said maybe my compiler optimzations were causing the problem
with breakpoints.
Quote: =
Re:HW breakpoints LM3S parts gnu/openOCD
My little group are good appliance operators - using a paid version of
IAR. And we have - li
http://www.nabble.com/Possibility-to-release-the-current-SVN-version-as-0.1.12.2-td24141073.html
The author has accepted my suggestion released the latest svn
of libusb-win32 0.1 branch as 0.1.12.2.
Download:
http://sourceforge.net/projects/libusb-win32/files/
This version solved the problem of c
On Tuesday 07 July 2009, Øyvind Harboe wrote:
> This option is not used by the code. I'd like to remove it unless
> someone can explain why we would need it in the next year or
> so when it has *never* been used in the past.
Sounds good.
___
Openocd-dev
On Tuesday 07 July 2009, Spencer Oliver wrote:
> No this reset delay is in your str7 startup code, eg.
>
> ...
>
> #*
> # Reset Handler Entry Point
> #*
On Tuesday 07 July 2009, Øyvind Harboe wrote:
> The problem is that GDB will assume that the target
> is in the halted state and query for registers.
>
> I'd like to see a model where OpenOCD allows a
> connect and enters a state where it returns dummy
> values for register queries(this happens to
On Tuesday 07 July 2009, Øyvind Harboe wrote:
> > You must be *trying* to make it sound complex. There is
> > no "negotiation" involved at all. Or "overriding" either...
> >
> > (a) there are four control knobs to diddle, and
> > (b) changing one knob doesn't change *ANY* other knob.
>
> Only
On Wed, 2009-07-08 at 00:14 +0200, Øyvind Harboe wrote:
> > We need to find some balance. Right now, the presses are too heavily
> > biased toward "development" to the extent that "release" suffers badly.
>
> I definitely want to see a reset of the release timeout counter
> when we discover such
On Tuesday 07 July 2009, Øyvind Harboe wrote:
> > It's very rare that any chip config file needs to say anything
> > about resetting ... since most of the time it's a function of
> > board wiring.
>
> Except lots of these chips have srst_pulls_trst wired on
> the *inside* of the CPU part
In w
On Tuesday 07 July 2009, Øyvind Harboe wrote:
> OpenOCD has no way of expressing srst_pulls_trst per TAP
> controller...
As I observed a while back, it has no way to express a
whole bunch of observed-in-the-real-world constraints
with different levels of resets.
In that case, it seems more like t
Is there a way we could *robustly* detect srst_pulls_trst for
an ARM7/9 part?
Thoughts anyone?
If srst_pulls_trst is required for a target/board and it is not
there, it will cause all sorts of confusion. There is some evidence
of that in the last few days
--
Øyvind Harboe
Embedded software
On Wed, Jul 8, 2009 at 12:12 AM, David Brownell wrote:
> On Tuesday 07 July 2009, Ųyvind Harboe wrote:
>> What I'm arguing is that "none" should be default
>
> It is. Though it's never meant what you seem to think it means.
I've tried to read up on the documentation and the
code of reset_config.
> We need to find some balance. Right now, the presses are too heavily
> biased toward "development" to the extent that "release" suffers badly.
I definitely want to see a reset of the release timeout counter
when we discover such problems as we have seen in
the last week.
The "step" bug alone w
On Tue, 2009-07-07 at 15:01 -0700, David Brownell wrote:
> [ GRR "send" pressed itself somehow ]
>
> On Tuesday 07 July 2009, Zach Welch wrote:
> >
> > I would intuitively expect to be able to write:
> >
> > reset_config none srst_only srst_pulls_trst
> >
> > The key bit is the 'none', which
On Tuesday 07 July 2009, Øyvind Harboe wrote:
> What I'm arguing is that "none" should be default
It is. Though it's never meant what you seem to think it means.
> and that any clever overriding & negotiation between board/target
> scripts should happen in tcl.
You must be *trying* to make it
On Tue, 2009-07-07 at 23:46 +0200, Øyvind Harboe wrote:
> On Tue, Jul 7, 2009 at 11:02 PM, David Brownell wrote:
> > On Tuesday 07 July 2009, Ųyvind Harboe wrote:
[snip]
> Create a release timeout counter which is reset upon
> acknowledged regressions reported?
We might not release until X-mas.
>
What about cutting the release and waiting a
week to see if something worthwhile appears that
makes you want to cut the release from a newer
svn version?
Allowing commits meanwhile, but encouraging postponements
of more crazy stuff + commits for collaboration purposes.
Cutting the release from an
To convince me of the value of the current implementation,
explain to me why this "negotiation" belongs in the
low level reset_config command and not in
some higher level tcl utility proc.
This "negotiation" is a mechanism that a target/board
config script should be able to use if it wants to.
My
[ GRR "send" pressed itself somehow ]
On Tuesday 07 July 2009, Zach Welch wrote:
>
> I would intuitively expect to be able to write:
>
> reset_config none srst_only srst_pulls_trst
>
> The key bit is the 'none', which blows it back to a cleared state.
No, that should be an error. The "what
On Tuesday 07 July 2009, Zach Welch wrote:
>
> I would intuitively expect to be able to write:
>
> reset_config none srst_only srst_pulls_trst
>
> The key bit is the 'none', which blows it back to a cleared state.
No, that should be an error. The "what signals" options
are (quoting the manua
On Tue, 2009-07-07 at 14:02 -0700, David Brownell wrote:
> On Tuesday 07 July 2009, Øyvind Harboe wrote:
> > My current feeling about 0.2 is that we should allow at least
> > a week of work on the outstanding reset problems before we cut
> > the release.
>
> That seems reasonable. Likewise some o
On Tue, Jul 7, 2009 at 11:50 PM, David Brownell wrote:
> On Tuesday 07 July 2009, Ųyvind Harboe wrote:
>> > Is there some problem the current scheme has?
>>
>> Yes.
>
> Not according to what you say below ...
>
>
>> Lets say I have no idea what the default target script does,
>> but I know *precise
> AFAIK, it was designed to allow a target file to specify chip-level
> behavior and a board file to specify board-level behavior. Without the
> current functionality, there is no way to create such layered support.
This is wrong. Clearly you can implement the reset_config
board/target negotiatio
I'll test i.MX27 w/"reset_config srst_pulls_trst " tomorrow. It
seems more correct to try to use trst if it is there.
> But there can
> also be board-level behaviors ... consider a board with
> an i.MX27 plus another chip that doesn't couple those
> behaviors internally. Issue SRST ... and one c
On Tuesday 07 July 2009, Øyvind Harboe wrote:
> > Is there some problem the current scheme has?
>
> Yes.
Not according to what you say below ...
> Lets say I have no idea what the default target script does,
> but I know *precisely* what my board needs: srst_only
> srst_pulls_trst.
There's no
On Tue, Jul 7, 2009 at 11:02 PM, David Brownell wrote:
> On Tuesday 07 July 2009, Ųyvind Harboe wrote:
>> My current feeling about 0.2 is that we should allow at least
>> a week of work on the outstanding reset problems before we cut
>> the release.
>
> That seems reasonable. Likewise some of the
On Tuesday 07 July 2009, Øyvind Harboe wrote:
> > I can believe the chip requires "reset_config srst_pulls_trst".
> >
> > But I have a hard time believing "srst_only" is anything but
> > a board-specific constraint.
>
> The TRST is tied to SRST on the *inside* of the chip if I understood
> correct
On Tue, 2009-07-07 at 23:39 +0200, Øyvind Harboe wrote:
> > I would intuitively expect to be able to write:
> >
> > reset_config none srst_only srst_pulls_trst
> >
> > The key bit is the 'none', which blows it back to a cleared state.
>
> What I'm arguing is that "none" should be default
> and th
This option is not used by the code. I'd like to remove it unless
someone can explain why we would need it in the next year or
so when it has *never* been used in the past.
trst_pulls_srst dilutes the crucial and imporant srst_pulls_trst.
--
Øyvind Harboe
Embedded software and hardware consultin
> >
> > This is why people often put a small reset delay in the
> startup file
> > for the
> > str7 to compensate for this.
>
> Last I checked there was a str710.cfg file which we use. How
> do you set his "small reset delay" you speak of? Would this
> be jtag_n[st]rst_delay? Should this be
> I would intuitively expect to be able to write:
>
> reset_config none srst_only srst_pulls_trst
>
> The key bit is the 'none', which blows it back to a cleared state.
What I'm arguing is that "none" should be default
and that any clever overriding & negotiation between board/target
scripts shou
(Post 0.2 if anyone wondered...)
I've been thinking a bit about what should happen when
GDB connects & disconnects to OpenOCD and my
conclusion is: nothing.
Nothing should happen. Just like connecting/disconnecting
a telnet session.
We may want to keep some of the existing behavior or add
conn
On Tue, 2009-07-07 at 23:18 +0200, Øyvind Harboe wrote:
> >> How about modifying reset_config to simply *set* the
> >> state based *only* on the arguments to reset_config,
> >> ignoring the current reset_config state?
> >
> > That makes it impossible to combine constraints that come
> > from differ
On Tue, Jul 7, 2009 at 11:18 PM, David Brownell wrote:
> On Tuesday 07 July 2009, Ųyvind Harboe wrote:
>> --- C:/workspace/openocd/tcl/target/imx27.cfg (revision 2491)
>> +++ C:/workspace/openocd/tcl/target/imx27.cfg (working copy)
>> @@ -1,5 +1,6 @@
>> -#use combined on interfaces or targets that
Spencer Oliver wrote:
>> We have an STR712 board by Olimex but (actually, an IAR
>> kickstart board). We can do the "halt reset" with no errors
>> but it does not do a clean reset (the PC does not go to
>> zero). With soft_reset_halt it does go back to zero. There
>> are no errors logged in ei
On Tuesday 07 July 2009, Øyvind Harboe wrote:
> --- C:/workspace/openocd/tcl/target/imx27.cfg (revision 2491)
> +++ C:/workspace/openocd/tcl/target/imx27.cfg (working copy)
> @@ -1,5 +1,6 @@
> -#use combined on interfaces or targets that can't set TRST/SRST separately
> -reset_config trst_and_srst
>> How about modifying reset_config to simply *set* the
>> state based *only* on the arguments to reset_config,
>> ignoring the current reset_config state?
>
> That makes it impossible to combine constraints that come
> from different spots, so I don't like that notion.
That assumption is false. T
On Tue, 2009-07-07 at 22:31 +0800, Xiaofan Chen wrote:
> On Tue, Jul 7, 2009 at 8:02 PM, Zach Welch wrote:
> >> > I will try it. But the start of the configure output says this.
> >> >
> >> > mc...@ubuntu904:~/Desktop/build/openocd/build-win32-ftd2xx$ sh
> >> > myconfig-win32-ftd2xx.sh
> >> > conf
On Tuesday 07 July 2009, Øyvind Harboe wrote:
> reset_config currently manipulates the current state rather
> than just sets the state by some scheme which I'm not
> able to decipher immediately.
It's what's documented. There are several categories of
options, and what you pass changes *only* the
On Tue, 2009-07-07 at 17:42 +0200, Øyvind Harboe wrote:
> Here is a patch of suggested modification, no longer
> take current reset_config state into account.
Do not apply. This would directly regress work that was done by David
Brownell for 0.2.0. Specifically, look at r1944.
Zach
On Tuesday 07 July 2009, Øyvind Harboe wrote:
> My current feeling about 0.2 is that we should allow at least
> a week of work on the outstanding reset problems before we cut
> the release.
That seems reasonable. Likewise some of the issues turning
up with different JTAG adapters.
It's funny how
>
> We have an STR712 board by Olimex but (actually, an IAR
> kickstart board). We can do the "halt reset" with no errors
> but it does not do a clean reset (the PC does not go to
> zero). With soft_reset_halt it does go back to zero. There
> are no errors logged in either case.
> soft_reset
I actually do development on Mac OS X rather then windows. The particular
problem I am seeing after generating a "reset" is:
jlink_usb_message failed with result=1)
jlink_tap_execute, wrong result -107 (expected 1)
JTAG tap: at91sam9260.cpu tap/device found: 0x0792603f (mfg: 0x01f, part:
0x7926,
Spencer Oliver wrote:
>> With jlink on cortex M3 boards (ST Mic), "halt reset" works
>> OK. But with
>> STR712 board (ARM7TDMI) it doesn't work and I have to do
>> "soft_reset_halt". I don't remember the exact failure with
>> "halt reset"
>> with ARM7 since I don't have anything setup right now
I had this problem before , but to see if I could shake it out, I did
the following things
1) Switch hardware JTAG debugger from olimex ARM-USB-TINY to Segger/IAR Jlink
2) Rebuild pretty much the latest posible version of openocd svn2459.
But my problem still exists.
I need the ability to use at
Hi Oyvind,
I tried your patch. Unfortunately for at least my particular situation it
didn't solve my problem. I did notice that the latest subversion has more
logging information, however. The error output shows a few more message
details then the version I was using earlier:
Info : J-Link JT
Committed.
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
Index: C:/workspace/openocd/tcl/target/imx27.cfg
===
--- C:/workspace/openocd/tcl/target/imx27.cfg (revision 2491)
+++ C:/workspac
> >
> > strangely however the str912 fails the reset halt using jlink.
> > But works fine using amontec/olimex - the saga continues.
>
> Some devices (str912??) need CLK=0 in idle for reset halt to work.
>
Thanks, i remember that from before.
Thought this was sorted for jlink?
Cheers
Spen
On Tue, Jul 7, 2009 at 5:53 PM, Spencer Oliver wrote:
>> > With jlink on cortex M3 boards (ST Mic), "halt reset" works OK. But
>> > with
>> > STR712 board (ARM7TDMI) it doesn't work and I have to do
>> > "soft_reset_halt". I don't remember the exact failure with "halt
>> > reset"
>> > with ARM7 sin
> > With jlink on cortex M3 boards (ST Mic), "halt reset" works OK. But
> > with
> > STR712 board (ARM7TDMI) it doesn't work and I have to do
> > "soft_reset_halt". I don't remember the exact failure with "halt
> > reset"
> > with ARM7 since I don't have anything setup right now.
> >
>
> just
> With jlink on cortex M3 boards (ST Mic), "halt reset" works
> OK. But with
> STR712 board (ARM7TDMI) it doesn't work and I have to do
> "soft_reset_halt". I don't remember the exact failure with
> "halt reset"
> with ARM7 since I don't have anything setup right now.
>
just tested with a jl
Here is a patch of suggested modification, no longer
take current reset_config state into account.
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/jtag/tcl.c
==
It appears that srst pulls trst on my target.
When I changed to "reset_config srst_pulls_trst", then things immediately
worked *MUCH* better. All error messages vanished. :-)
Now, my next step is to take the axe to reset_config and change
the behaviour of reset_config to *set* rather than *modify
reset_config currently manipulates the current state rather
than just sets the state by some scheme which I'm not
able to decipher immediately.
There isn't a way to *read* the current state.
How about modifying reset_config to simply *set* the
state based *only* on the arguments to reset_config,
Gary Carlson wrote:
> I am getting a bug message when I issue a ³reset halt² instruction from a
> telnet client using a j-link dongle. Has this instruction worked for anyone
> else before on other targets? Before I go off an hunt this down, I was
> hoping to see whether it is a problem isolated t
On Tue, Jul 7, 2009 at 10:51 PM, Gene Smith wrote:
> Gary Carlson wrote:
>> I am getting a bug message when I issue a ³reset halt² instruction from a
>> telnet client using a j-link dongle. Has this instruction worked for anyone
>> else before on other targets? Before I go off an hunt this down,
On Tue, Jul 7, 2009 at 8:02 PM, Zach Welch wrote:
>> > I will try it. But the start of the configure output says this.
>> >
>> > mc...@ubuntu904:~/Desktop/build/openocd/build-win32-ftd2xx$ sh
>> > myconfig-win32-ftd2xx.sh
>> > configure: WARNING: If you wanted to set the --build type, don't use
>>
On Tue, Jul 7, 2009 at 3:34 PM, Brian Hutchinson wrote:
> I have two arm926ejs boards. One is a AT91SAM9260 based board and the other
> is a picoChip PC205 based board.
>
> I'm currently using svn 1940 with a Numonyx write buffer hack (buffer writes
> wouldn't work with my flash) as the last time
The current J-Link code and OpenOCD will only allow one instance of
J-Link to function. It is actually possible to add one parameter
to differentiate different unit of J-Link (say through the serial number)
so that multiple instances of OpenOCD can be run with different
J-Link units.
This is proba
I have two arm926ejs boards. One is a AT91SAM9260 based board and the other
is a picoChip PC205 based board.
I'm currently using svn 1940 with a Numonyx write buffer hack (buffer writes
wouldn't work with my flash) as the last time I tried a newer version (about
a month ago) the head wouldn't wor
On Tue, Jul 7, 2009 at 7:59 PM, Spencer Oliver wrote:
>> Are you saying you have problems under Windows but not Linux?
>>
>
> yes, linux works win32 is broken.
> The attached patch fixes the problem, but i do not like waiting for the
> re-enumeration under win32 -
> linux does not suffer the same f
Hi Zach,
thanks for a good post & followup on this.
I'll try to adjust to the new rules of engagement and stop committing
willy nilly.
W.r.t. when 0.2 should go out of the door, I'm thinking that we
should have a few days without finding and fixing regressions
before we say it's time to release.
On Mon, 2009-07-06 at 15:16 +0200, Øyvind Harboe wrote:
> I've determined that single stepping is busted for
> svn head arm926ejs using parport against wi-9c.cfg
> (bisecting this now).
This does not meet my standard for "explaining" the changes that went
into the OpenOCD tree, in so far as I sti
I hope I'm closing in a bit on the problem with "reset run" on i.MX27.
- "reset run" will fail with the error messages below
- the problem appears to be that OpenOCD believes that the target is
halted when it is in fact running. It could be that MOE=0xe is simply
what is returned when the target i
> Do you have GraphViz installed?
I've tried to install it, but same result.
Do you have another apt-get I can try? :-)
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
___
Openocd-development mailing list
Openo
On Tue, 2009-07-07 at 19:41 +0800, Xiaofan Chen wrote:
> On Tue, Jul 7, 2009 at 7:36 PM, Xiaofan Chen wrote:
> > On Tue, Jul 7, 2009 at 7:34 PM, Zach Welch wrote:
> >> On Tue, 2009-07-07 at 19:06 +0800, Xiaofan Chen wrote:
> >>> On Tue, Jul 7, 2009 at 7:01 PM, Xiaofan Chen
> >> [snip]
> >>> ../trun
> >> > For info this breaks my v5 and v6 jlinks (tested stm32).
> >> > Not sure if any one else is having trouble?
> >>
> >> How does it break?
> >>
> >
> > All read/writes fail as the usb handle is invalid after the
> usb_reset
> > is performed.
> > Perhaps the win32 libusb does a reset whereas
On Tue, 2009-07-07 at 13:41 +0200, Øyvind Harboe wrote:
> I've applied your patch for moving bug + references to the right section.
>
>
> I took Doxygen for a spin. Fixed a small spelling in readme + added a
> note to check that Doxygen is installed.
>
> I'm getting lots of error when building D
On Tue, Jul 7, 2009 at 7:41 PM, Xiaofan Chen wrote:
> On Tue, Jul 7, 2009 at 7:36 PM, Xiaofan Chen wrote:
>> On Tue, Jul 7, 2009 at 7:34 PM, Zach Welch wrote:
>>> What happens if you add '--build=i686-pc-linux-gnu' to this?
>>>
>>
>> I will try it. But the start of the configure output says this.
>
On Tue, Jul 7, 2009 at 7:36 PM, Xiaofan Chen wrote:
> On Tue, Jul 7, 2009 at 7:34 PM, Zach Welch wrote:
>> On Tue, 2009-07-07 at 19:06 +0800, Xiaofan Chen wrote:
>>> On Tue, Jul 7, 2009 at 7:01 PM, Xiaofan Chen
>> [snip]
>>> ../trunk/configure --host=i586-mingw32msvc --enable-maintainer-mode
>>> --
I've applied your patch for moving bug + references to the right section.
I took Doxygen for a spin. Fixed a small spelling in readme + added a
note to check that Doxygen is installed.
I'm getting lots of error when building Doxygen docs:
Error opening map file structworking__area__s__coll__gra
On Tue, Jul 7, 2009 at 7:34 PM, Zach Welch wrote:
> On Tue, 2009-07-07 at 19:06 +0800, Xiaofan Chen wrote:
>> On Tue, Jul 7, 2009 at 7:01 PM, Xiaofan Chen
> [snip]
>> ../trunk/configure --host=i586-mingw32msvc --enable-maintainer-mode
>> --disable-shared --enable-ft2232_libftdi
>
> What happens if
On Tue, 2009-07-07 at 19:06 +0800, Xiaofan Chen wrote:
> On Tue, Jul 7, 2009 at 7:01 PM, Xiaofan Chen
[snip]
> ../trunk/configure --host=i586-mingw32msvc --enable-maintainer-mode
> --disable-shared --enable-ft2232_libftdi
What happens if you add '--build=i686-pc-linux-gnu' to this?
--Z
__
On Tue, Jul 7, 2009 at 5:04 PM, Spencer Oliver wrote:
>
>> >
>> > For info this breaks my v5 and v6 jlinks (tested stm32).
>> > Not sure if any one else is having trouble?
>>
>> How does it break?
>>
>
> All read/writes fail as the usb handle is invalid after the usb_reset is
> performed.
> Perhaps
There is no error message if I type "make doxygen" when
Doxygen is installed. The doxygen.log reveals the
culprit.
oyv...@titan:~/workspace/build$ make doxygen
cd . && /bin/sh ./config.status Makefile
config.status: creating Makefile
make Doxyfile
make[1]: Entering directory `/home/oyvind/workspa
> mc...@ubuntu904:~/Desktop/build/openocd/build-win32-libftdi$
> cat myconfig-win32-libftdi.sh ../trunk/configure
> --host=i586-mingw32msvc --enable-maintainer-mode
> --disable-shared --enable-ft2232_libftdi
>
> Log file is attached.
>
In both your cases a cross compiler is not being detecte
On Tue, Jul 7, 2009 at 7:22 AM, Gary Carlson wrote:
> I am getting a bug message when I issue a ³reset halt² instruction from a
> telnet client using a j-link dongle. Has this instruction worked for anyone
> else before on other targets? Before I go off an hunt this down, I was
> hoping to see wh
On Tue, 2009-07-07 at 12:33 +0200, Øyvind Harboe wrote:
> Committed to TODO:
>
> - i.MX27 reset run problems. Notice below that even if the target is running,
> a EICE_DBG_STATUS_DBGACK(I think...) is detected and OpenOCD wrongly
> believes that the target is halted. Polling the target afterwards
fix return value for "reset" and "runtest" command. Found by code inspection.
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/jtag/tcl.c
===
Committed to TODO:
- i.MX27 reset run problems. Notice below that even if the target is running,
a EICE_DBG_STATUS_DBGACK(I think...) is detected and OpenOCD wrongly
believes that the target is halted. Polling the target afterwards
reveals that the
target is running.
> reset run
JTAG tap: imx27.b
On Tue, Jul 7, 2009 at 5:04 PM, Spencer Oliver wrote:
>> > For info this breaks my v5 and v6 jlinks (tested stm32).
>> > Not sure if any one else is having trouble?
>>
>> How does it break?
>
> All read/writes fail as the usb handle is invalid after the
> usb_reset is performed.
> Perhaps the win32
>
> I run bootstrap in the trunk directory before running
> configure in different build directories. I use separate
> directory for different build options (native Linux build for
> J-Link, cross build for J-Link, native build for FTD2xx,
> cross build for FTD2xx, etc). But this should not m
On Tue, Jul 7, 2009 at 4:49 PM, Spencer Oliver wrote:
>
>>
>> > you should see the following message:
>> > whether ftd2xx library works... Skipping as we are cross-compiling
>>
>> This does not happen unfortunately.
>>
>
> try running bootstrap or autoreconf.
> what do you get when svnversion is ru
> >
> > For info this breaks my v5 and v6 jlinks (tested stm32).
> > Not sure if any one else is having trouble?
>
> How does it break?
>
All read/writes fail as the usb handle is invalid after the usb_reset is
performed.
Perhaps the win32 libusb does a reset whereas the linux one does not?
Ch
On Tue, Jul 7, 2009 at 4:30 PM, Spencer Oliver wrote:
>
>> Author: zwelch
>> Date: 2009-07-06 12:34:33 +0200 (Mon, 06 Jul 2009) New Revision: 2471
>>
>> Modified:
>> trunk/src/jtag/jlink.c
>> Log:
>> Gary Carlson :
>>
>> Fix intermittent J-Link interface startup failures:
>> - Use usb_reset to e
>
> > you should see the following message:
> > whether ftd2xx library works... Skipping as we are cross-compiling
>
> This does not happen unfortunately.
>
try running bootstrap or autoreconf.
what do you get when svnversion is run ?
> > I have tested ubuntu 9.04 (64 and 32bit) here and it i
On Tue, Jul 7, 2009 at 4:39 PM, Spencer Oliver wrote:
> make sure you have updated to svn head as this should not happen.
Yes I have done that.
> you should see the following message:
> whether ftd2xx library works... Skipping as we are cross-compiling
This does not happen unfortunately.
> I ha
> >>> Somehow cross build with ftd2xx and libftdi do not work
> for me yet.
> >>> I just tried the process under Ubuntu 9.04.
> >>>
> >>> 1) With libftdi, it chocked at the test program building.
> >>> With normal build under Linux, it works.
> >>> ../trunk/configure --host=i586-mingw32msvc
> -
1 - 100 of 102 matches
Mail list logo
