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
FYI, I just pushed the following:
commit 3d2d5dcc9c27b84dc2e5e9ed53be0f784a450042
Author: Nicolas Pitre
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
the unused amount
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 reverse-engin
On Tue, Feb 2, 2010 at 3:03 AM, Nick 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 should use the lates
On Mon, 1 Feb 2010, Øyvind Harboe wrote:
> On Mon, Feb 1, 2010 at 1:26 PM, Spencer Oliver 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 i
On Monday 01 February 2010, Igor Skochinsky wrote:
> [reposting to list... I really wish this list had a proper reply-to]
You should just use the "Reply All" option; that's
how to issue public replies to mailing list posts.
If the list forced a "Reply-To" then it'd be really
painful to issue priv
[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 wh
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 debugg
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 Glaz
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 #inc
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
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 adapter
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
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".
>
> 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 opti
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
Open
>
> 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 othe
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 informati
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 Grimberg
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
> 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 ap
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 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
>
> 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 configu
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
>>
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
> 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 n
>
> 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 trst_an
Øyvind Harboe wrote:
> On Mon, Feb 1, 2010 at 1:26 PM, Spencer Oliver 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.
>>>
>>>
>>
>>
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
>>
>
> 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_N
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 in
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
___
Openocd-developm
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.
sti
On Mon, Feb 1, 2010 at 1:26 PM, Spencer Oliver 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 who
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 http://www.zylin.c
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 fou
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 0x000
Ø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
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 t
> 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 ARM
Edgar Grimberg wrote:
> On Fri, Jan 29, 2010 at 10:50 AM, Edgar Grimberg
> wrote:
>> On Tue, Jan 26, 2010 at 5:38 AM, David Brownell wrote:
>>> On Tuesday 19 January 2010, Øyvind Harboe wrote:
Run the following and it will fail to halt occasionally. This is not a
regression,
but I
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 ca
On Mon, Feb 1, 2010 at 5:54 PM, David Brownell 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 Windows.
#defin
Øyvind Harboe wrote:
> Include according to
> http://www.opengroup.org/onlinepubs/95399/functions/stat.html
>
> Signed-off-by: Øyvind Harboe
> ---
> src/target/arm_semihosting.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/src/target/arm_semihosting.c b/src
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
46 matches
Mail list logo
