Hello Thomas!
Thomas wrote:
There's a quirk (bug?) in OpenOCD that requires you to give the -f
option explicitly when using -c commands.
So openocd -f openocd.cfg -c erasemem should work.
Also, you have to call init-function first -- either on the command
line, or in your openocd.cfg.
Ah,
Nicolas Pitre wrote:
On Wed, 27 Jan 2010, Spencer Oliver wrote:
Cygwin would fail to reopen a previously written file if the mode is
not given.
What do you mean?
If we use a open on the target the first time cygwin host opens a new
file all is well. If we reset micro and try to reopen
On Wed, Jan 27, 2010 at 7:44 PM, David Brownell davi...@pacbell.net wrote:
On Wednesday 27 January 2010, Edgar Grimberg wrote:
On Tue, Jan 26, 2010 at 10:08 PM, David Brownell davi...@pacbell.net wrote:
On Tuesday 26 January 2010, David Brownell wrote:
No, I haven't checked the buffer. Do
Hi,
Can anyone verify that this interface is still functional in 0.4 ? Out of
0.4-rc1, 0.3.1 and an old rev.131 fetch only the old rev.131 fetch works to a
certain extent. In all cases the openocd was built from source on cygwin with
only amt_jtagaccell and parport_give_io enabled in
And the debug_level 3 log of the reset command:
reset
JTAG tap: imx31.etb tap/device found: 0x2b900f0f (mfg: 0x787, part:
0xb900, ver: 0x2)
JTAG tap: imx31.cpu tap/device found: 0x07b3601d (mfg: 0x00e, part:
0x7b36, ver: 0x0)
TAP imx31.whatchacallit does not have IDCODE
JTAG tap:
If I disable the write burst mode, I get a different error on reset:
Disableing the burst mode:
(gdb) moni arm11 memwrite burst disable
memory write burst mode is disabled
with the log:
Debug: 1109 1770274 gdb_server.c:2147 gdb_input_inner(): received
packet:
Can anyone verify that this interface is still functional in
0.4 ? Out of 0.4-rc1, 0.3.1 and an old rev.131 fetch only the
old rev.131 fetch works to a certain extent. In all cases the
openocd was built from source on cygwin with only
amt_jtagaccell and parport_give_io enabled in
Hi,
The information presented by flash info about the protection status
points to something faulty. My target is a HITEX STR710 evalboard.
I am using v0.4.0-rc1-154-g3172be8 . The configuration script is the
default one from target/str710.cfg
This is the test case:
flash protect_check 0
On Thursday 28 January 2010, Edgar Grimberg wrote:
The information presented by flash info about the protection status
points to something faulty.
This is on my list of regressions. Someone with an STR7
should come up with a fix ...
___
On Thursday 28 January 2010, Matthew Fletcher wrote:
There appears to be a certain amount of rot in the amt_jtagaccel driver,
That was my conclusion when I noticed, not long ago, that
it wouldn't even *build* with PPDEV enabled ... an issue
that's been around for quite some time.
Those
On Wednesday 27 January 2010, Thomas Kindler wrote:
There's a quirk (bug?) in OpenOCD that requires you to give the -f
option explicitly when using -c commands.
So openocd -f openocd.cfg -c erasemem should work.
Also, you have to call init-function first -- either on the command
line,
On Thursday 28 January 2010, David Brownell wrote:
On Thursday 28 January 2010, Edgar Grimberg wrote:
The information presented by flash info about the protection status
points to something faulty.
This is on my list of regressions. Someone with an STR7
should come up with a fix ...
Whoops, sorry -- that one isn't listed as regression[1],
nobody has confirmed that it was working in 0.3.1 code.
How about we try using a bug database of sorts? Mantis is the first
that comes to mind. It can be read-only for the general public and
only the maintainers (and official testers, if
On Thursday 28 January 2010, Edgar Grimberg wrote:
How about we try using a bug database of sorts? Mantis is the first
that comes to mind. It can be read-only for the general public and
only the maintainers (and official testers, if you like) can add
bugs into it. It's a way to gather all the
On Thu, Jan 28, 2010 at 5:49 PM, David Brownell davi...@pacbell.net wrote:
On Thursday 28 January 2010, Edgar Grimberg wrote:
How about we try using a bug database of sorts? Mantis is the first
that comes to mind. It can be read-only for the general public and
only the maintainers (and
On Thursday 28 January 2010, Dean Glazeski wrote:
You know, I'm sort of in love with Trac. I love the way their code is
designed and I love their system. I've been using for quite some time.
Hmm, so you're ahead of most of us! Might you then be interested
in helping this project at least
On Thu, Jan 28, 2010 at 7:45 PM, David Brownell davi...@pacbell.net wrote:
On Thursday 28 January 2010, Dean Glazeski wrote:
You know, I'm sort of in love with Trac. I love the way their code is
designed and I love their system. I've been using for quite some time.
Hmm, so you're ahead
The only significant anti- sentiment I have is that the Trac git plug-in
hasn't had an update since 28th of August of 2009. I'm going to play with
this a little bit with my sourceforge project that's hooked up to git and
I'll get back to you.
Alright, it's impossible to do it, for now.
On Thursday 28 January 2010, Dean Glazeski wrote:
The only significant anti- sentiment I have is that the Trac git plug-in
hasn't had an update since 28th of August of 2009. I'm going to play with
this a little bit with my sourceforge project that's hooked up to git and
I'll get back to
So, just for curiosity, I decided to try llvm-clang to build openocd.
I haven't actually run the build yet, but it's just over half the
size of the gcc build, and compiled just a touch faster, too. Any
comments? The time output is from make -j3 calls.
openocd-via-gcc:
real0m25.669s
user
On Thursday 28 January 2010, Austin, Alex wrote:
+#ifndef true
+#define true -1
ANSI-C defines true as 1 not -1 ... best
to use that for compatibility.
I suspect I'll merge this portability patch with that change...
+#define false 0
+#endif
By the way, were those object sizes size output
~/Projects $ size openocd.gcc
textdata bss dec hex filename
915920 11600 90668 1018188 f894c openocd.gcc
~/Projects $ size openocd.clang
textdata bss dec hex filename
902754 10684 90572 1004010 f51ea openocd.clang
-Original Message-
22 matches
Mail list logo
