On Sunday 31 January 2010, Nick wrote:
Error: usb_bulk_write failed (requested=1, result=-22)
At least on Linux -22 usually means -EINVAL ... as in,
something passed an invalid argument to a system call.
I don't know how much the arm-jtag-ew adapter is used
with OpenOCD, but I don't recall many
Øyvind Harboe wrote:
Include sys/stat.h according to
http://www.opengroup.org/onlinepubs/95399/functions/stat.html
Signed-off-by: Øyvind Harboe oyvind.har...@zylin.com
---
src/target/arm_semihosting.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git
On Mon, Feb 1, 2010 at 5:54 PM, David Brownell davi...@pacbell.net wrote:
On Sunday 31 January 2010, Nick wrote:
Error: usb_bulk_write failed (requested=1, result=-22)
At least on Linux -22 usually means -EINVAL ... as in,
something passed an invalid argument to a system call.
Same for
Edgar Grimberg wrote:
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:
Edgar Grimberg wrote:
On Fri, Jan 29, 2010 at 10:50 AM, Edgar Grimberg
edgar.grimb...@zylin.com wrote:
On Tue, Jan 26, 2010 at 5:38 AM, David Brownell davi...@pacbell.net wrote:
On Tuesday 19 January 2010, Øyvind Harboe wrote:
Run the following and it will fail to halt occasionally. This is
should this include not be going in helper/system.h ?
I generally try to avoid include everything everywhere... so I think it is
nice that it goes into that one .c file.
--
Øyvind Harboe
US toll free 1-866-980-3434 / International +47 51 63 25 00
http://www.zylin.com/zy1000.html
ARM7 ARM9
Hi Spen,
Have you another board to try, Hitex like to externally connect SRST and
TRST. This causes issues with openocd and the str7.
I have only the HITEX STR710 EVALBOARD with a STR710FZ2T6 on it.
Donations are always welcomed, of course :)
I have found with the str7 that even though the
Øyvind Harboe wrote:
should this include not be going in helper/system.h ?
I generally try to avoid include everything everywhere... so I think it is
nice that it goes into that one .c file.
I thought that the whole idea of creating the system.h is to stop
including system headers in
Hi Spen,
Could you provide a full debug log?
For the commands:
debug_level 3
debug_level: 3
flash protect 0 0 last off
cleared protection for sectors 0 through 7 on flash bank 0
flash protect_check 0
successfully checked protect state
flash info 0
#0 : str7x at 0x4000, size
Edgar Grimberg wrote:
Hi Spen,
Have you another board to try, Hitex like to externally connect SRST and
TRST. This causes issues with openocd and the str7.
I have only the HITEX STR710 EVALBOARD with a STR710FZ2T6 on it.
Donations are always welcomed, of course :)
I have found with the
Hi Spen,
I have tested two other vendor's boards that do not do this connection and
get no problems.
Another details is that I have an empty flash. The test case is reset
init on an empty flash.
Edgar
--
Edgar Grimberg
System Developer
Zylin AS
ZY1000 JTAG Debugger
On Mon, Feb 1, 2010 at 1:26 PM, Spencer Oliver s...@spen-soft.co.uk wrote:
Øyvind Harboe wrote:
should this include not be going in helper/system.h ?
I generally try to avoid include everything everywhere... so I think it is
nice that it goes into that one .c file.
I thought that the
Edgar Grimberg wrote:
Hi Spen,
I have tested two other vendor's boards that do not do this connection and
get no problems.
Another details is that I have an empty flash. The test case is reset
init on an empty flash.
just erased flash and performed full power cycle.
still working ok.
Tinkered a bit with progress/puts messages and committed.
--
Øyvind Harboe
US toll free 1-866-980-3434 / International +47 51 63 25 00
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
___
Edgar Grimberg wrote:
Hi Spen,
Could you provide a full debug log?
For the commands:
debug_level 3
debug_level: 3
flash protect 0 0 last off
cleared protection for sectors 0 through 7 on flash bank 0
flash protect_check 0
successfully checked protect state
flash info 0
#0 : str7x
Ah ok, I think this is an issue with the str7, rather than openocd.
The flash protection is being removed (until next reset) but we are reading
the non-volatile register (FLASH_NVWPAR).
This is read at reset and any write to this register only effects the
volatile version of FLASH_NVWPAR.
Edgar Grimberg wrote:
Ah ok, I think this is an issue with the str7, rather than openocd.
The flash protection is being removed (until next reset) but we are reading
the non-volatile register (FLASH_NVWPAR).
This is read at reset and any write to this register only effects the
volatile
Øyvind Harboe wrote:
On Mon, Feb 1, 2010 at 1:26 PM, Spencer Oliver s...@spen-soft.co.uk wrote:
Øyvind Harboe wrote:
should this include not be going in helper/system.h ?
I generally try to avoid include everything everywhere... so I think it is
nice that it goes into that one .c file.
I
Have you another board to try, Hitex like to externally connect SRST and
TRST. This causes issues with openocd and the str7.
I've checked the schematics and the behavior of the HITEX board.
The schematics shows that SRST pulls TRST.
I modified the configuration file to:
reset_config
we can, but it is only valid from the last reset.
Any changes made to FLASH_NVWPAR will not be viewable, even though
internally they are working.
I am a bit concerned that I see invalid information when I type flash info 0
and no warning that I'm looking at something invalid.
On the same note,
Edgar Grimberg wrote:
Have you another board to try, Hitex like to externally connect SRST and
TRST. This causes issues with openocd and the str7.
I've checked the schematics and the behavior of the HITEX board.
The schematics shows that SRST pulls TRST.
I modified the configuration file
Edgar Grimberg wrote:
Ah ok, I think this is an issue with the str7, rather than openocd.
The flash protection is being removed (until next reset) but we are reading
the non-volatile register (FLASH_NVWPAR).
This is read at reset and any write to this register only effects the
volatile
Strange, i have checked another two boards here, IAR and Keil and they are
both working aswell.
The interesting part of this problem is that reset is not always failing.
For example, I cannot reproduce anymore any of the reset problems I had
30 minutes ago, with the same firmware and
The str7 write protection is a bit quirky as once set can only be removed
temporarily anyway - until the next reset.
I'm thinking more of this situation:
* I reset and try to write something to the flash
* It will fail, since the protection is on.
* I check the flash, with flash info 0, I see
Edgar Grimberg wrote:
The str7 write protection is a bit quirky as once set can only be removed
temporarily anyway - until the next reset.
I'm thinking more of this situation:
* I reset and try to write something to the flash
* It will fail, since the protection is on.
* I check the
I see what you are saying, but if the user runs the default script then the
write protection will always be removed.
this assumes you are reseting with reset init.
Yes, but I trust the user to be smart enough to try a lot more combinations
than I can imagine. Inaccurate information will
Edgar Grimberg wrote:
I see what you are saying, but if the user runs the default script then the
write protection will always be removed.
this assumes you are reseting with reset init.
Yes, but I trust the user to be smart enough to try a lot more combinations
than I can imagine.
The default state of the flash after a reset init is unlocked.
The information in the flash driver reflects this.
The information about the lock status cannot be read from the
flash chip, so the user is informed that flash info might not
contain accurate information.
Signed-off-by: Edgar
Edgar Grimberg wrote:
The default state of the flash after a reset init is unlocked.
The information in the flash driver reflects this.
The information about the lock status cannot be read from the
flash chip, so the user is informed that flash info might not
contain accurate information.
The protection state will never be known until a protection check is done
anyway.
The protection state will never be known for sure. What if the user is running
an application that changes the protection status? Protection check doesn't
reflect the protection status of the flash.
On the other
Hi Everyone,
Has anyone succeeded in using the Olimex arm-jtag-ew with openocd 0.4.0_rc1 on
windows? I am having much trouble with mine. Is there a libusb0.dll that
works with the arm-jtag-ew?
thanks,
Nick
___
Openocd-development mailing list
I'm intrigued by having the bug database stored in git together with
the repository. Especially for posterity, offlline usage, etc.
I was kinda wondering if we could have the wiki stored in git as well.
(14 days cooloff before pushing or somesuch?).
The only really viable option
On Monday 01 February 2010, Edgar Grimberg wrote:
On the other hand, for other drivers, shouldn't flash info do a protection
check on the background? Otherwise the information presented by the
flash info command is *wrong*.
So far as I can tell, it's only valid after flash protect_check.
What
On Monday 01 February 2010, Spencer Oliver wrote:
I thought that the whole idea of creating the system.h is to stop
including system headers in the main openocd source.
Maybe stop including *the same* sytem headers all over.
There's nothing wrong with #including system headers.
They exist to
On Monday 01 February 2010, Nick wrote:
Has anyone succeeded in using the Olimex arm-jtag-ew with openocd 0.4.0_rc1
on windows?
Same question for Linux ... we really don't have many reports of
this particular driver working right. (Which is too bad. It's
one of a handful of discrete adapters
On Monday 01 February 2010, Edgar Grimberg wrote:
The default state of the flash after a reset init is unlocked.
The information in the flash driver reflects this.
The information about the lock status cannot be read from the
flash chip, so the user is informed that flash info might not
David Brownell wrote:
On Monday 01 February 2010, Spencer Oliver wrote:
I thought that the whole idea of creating the system.h is to stop
including system headers in the main openocd source.
Maybe stop including *the same* sytem headers all over.
There's nothing wrong with #including
Picking up, briefly, an old thread about how OpenOCD could
learn to support smart dongles... where code running inside
the JTAG adapter can offload some tasks from OpenOCD, like
polling for status changes.
On Monday 23 November 2009, David Brownell wrote:
On Monday 23 November 2009, Dean
This is a bit too philosophical for me. We have the solution and
can apply it to whatever the particular choice is w.r.t. what to
include where.
--
Øyvind Harboe
US toll free 1-866-980-3434 / International +47 51 63 25 00
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG
[reposting to list... I really wish this list had a proper reply-to]
Hello David,
Monday, February 1, 2010, 11:06:41 PM, you wrote:
DB It's come to my attention that at least current versions of NXP's
DB LPCXpresso [1] ($US 30) might include a candidate for this.
[...]
DB One question is
On Mon, 1 Feb 2010, Øyvind Harboe wrote:
On Mon, Feb 1, 2010 at 1:26 PM, Spencer Oliver s...@spen-soft.co.uk wrote:
Øyvind Harboe wrote:
should this include not be going in helper/system.h ?
I generally try to avoid include everything everywhere... so I think it is
nice that it goes
On Tue, Feb 2, 2010 at 3:03 AM, Nick ndro...@rogers.com wrote:
Has anyone succeeded in using the Olimex arm-jtag-ew
with openocd 0.4.0_rc1 on windows? I am having much trouble
with mine. Is there a libusb0.dll that works with the arm-jtag-ew?
Where do you get the libusb0.dll file? You
On Monday 01 February 2010, Xiaofan Chen wrote:
I do not think libusb0.dll is the problem. It is said that arm-jtag-ew
emulates the J-Link in low level API. It takes quite some for
OpenOCD to get J-Link working properly. So I will think the
first support is probably done by
FYI, I just pushed the following:
commit 3d2d5dcc9c27b84dc2e5e9ed53be0f784a450042
Author: Nicolas Pitre n...@fluxnic.net
Date: Tue Feb 2 00:05:42 2010 -0500
ARM semihosting: fix EOF handling with SYS_READ
The semihosting interface has a strange convention for read/write where
On Monday 01 February 2010, Nicolas Pitre wrote:
FYI, I just pushed the following:
Great, we just luuurve us some of those bugfixes! ;)
Something else that would be nice -- either from you or from
someone else: a simple test program which exercises all the
SYS_* requests, and everything else
45 matches
Mail list logo
