Użytkownik napisał:
>I find it odd that none has.
Personally I don't know what is the point of that patch. I don't use OpenOCD
via tree of MinGW/MSYS and I don't think anyone does, so what's the point of
that patch? I use MinGW/MSYS to compile OpenOCD, and it compiles fine, because
that proce
I'm OK with this patch. I'll follow up on it for zy1000 once you push
it post 0.5.
I had a *minor* comment about not using 8 bit in bit arrays,
but my primary concerns have more to do with not disturbing your
momentum. :-)
--
Øyvind Harboe
US toll free 1-866-980-3434 / International +47 51 63 25
> +struct tms_command {
> + /** How many bits should be clocked out. */
> + unsigned num_bits;
> + /** The bits to clock out; the LSB is bit 0 of bits[0]. */
> + uint8_t *bits;
Tiny comment:
Use uint32_t here, rather than 8 bits. Why 8 bits? There is no
big
> I'll hope someone else chimes in with some insights here. This
> kind of needs to get sorted before 0.4 freezes.
Here is another tidbit:
If you execute "c", then first a step packet is sent, then a continue
packet. Weird, uh?
--
Øyvind Harboe
US toll free 1-866-980-3434 / International +47
On Fri, Jan 15, 2010 at 8:18 AM, Øyvind Harboe wrote:
> On Thu, Jan 14, 2010 at 11:26 PM, David Brownell wrote:
>> On Thursday 14 January 2010, Andreas Fritiofson wrote:
>>> Any comments on this?
>>
>> I was hoping some Windows users would comment ..
>
> I find it that none has.
arrg... send too
On Thu, Jan 14, 2010 at 11:26 PM, David Brownell wrote:
> On Thursday 14 January 2010, Andreas Fritiofson wrote:
>> Any comments on this?
>
> I was hoping some Windows users would comment ..
I find it that none has.
--
Øyvind Harboe
US toll free 1-866-980-3434 / International +47 51 63 25 00
h
On Thursday 14 January 2010, yintang gu wrote:
>
> >Hmm ... is this a bug you've observed, or is this something
> >you've wondered after poking through the code?
>
> >I recall setting breakpoints through the Tcl interface and
> >having them behave correctly. Haven't tried to do that any
> >time r
Implement the new TMS_SEQ command on FT2232 hardware, and remove
its now un-needed pathmove() support. This is a net minor code
shrink in this driver, combined with the feature addition.
Also, swap a bogus exit() call with a clean failure return.
---
src/jtag/drivers/ft2232.c | 133
When the underlying JTAG adapter supports it, use the new TMS sequence
operation instead of a pathmove(). This will eliminate duplicated work,
and removes the need for separate pathmove() logic in those drivers.
Similarly for statemove() ... which someday we might consider removing.
It's already
For support of SWD we need to be able to clock out special bit
sequences over TMS or SWDIO. Create this as a generic operation,
not yet called by anything, which is split as usual into:
- upper level abstraction ... here, jtag_add_tms_seq();
- midlayer implementation logic hooking that to the l
This is one of several low-level interface changes that will
support SWD ... obviously not for the 0.4 release, but I'm
posting it now as an FYI/RFC.
- Interface level patch: add a call to clock bits out on TMS.
Switching between JTAG and SWD modes involves some magic
sequences here. The
>Hmm ... is this a bug you've observed, or is this something
>you've wondered after poking through the code?
>I recall setting breakpoints through the Tcl interface and
>having them behave correctly. Haven't tried to do that any
>time recently, though. And I could believe there's a bit
>of a sema
On Thursday 14 January 2010, Andreas Fritiofson wrote:
> Any comments on this?
I was hoping some Windows users would comment ..
> I had hoped to get this functional in 0.4 so I
> could drop the -s from the command line at work.
>
> Windows builders/packagers, does this look OK from your point
Any comments on this? I had hoped to get this functional in 0.4 so I
could drop the -s from the command line at work.
Windows builders/packagers, does this look OK from your point of view
or do you still install scripts in ../lib?
___
Openocd-development
On Thursday 14 January 2010, Audrius Urmanavicius wrote:
> > I've seen JTAG 20 used with SWD. Is there a smaller SWD connector?
>
> The JTAG/SWD cable with small 10 pin 1.27mm pitch connector like the one
> on MCB1700 board:
>
> http://www.keil.com/support/man/docs/mcb1700/mcb1700_to_jtag.htm
>
On Wed, Jan 13, 2010 at 9:48 PM, Peter Korsgaard wrote:
>> "Øyvind" == Øyvind Harboe writes:
>
> Øyvind> To me this patch looks reasonable. the .c file is basically a bunch
> Øyvind> of parameters and a few lines of code.
>
> Øyvind> Perhaps later the code could be refactored to share more
If there are any hardware vendors out there that would like to
have some help in demonstrating openocd with their hardware
Zylin have resources(people) that can help you out for most
major venues.
Please get in touch.
--
Øyvind Harboe
US toll free 1-866-980-3434 / International +47 51 63 25 00
On Thu, Jan 14, 2010 at 4:05 PM, Spencer Oliver wrote:
> Øyvind Harboe wrote:
>>>
>>> I am a bit bemused by this.
>>> GDB will have a good copy of the registers when it connects to openocd
>>> anyway.
>>
>> Not necessarily true:
>>
>> target remote
>> load
>> monitor reg
>> => GDB is out of s
Øyvind Harboe wrote:
>> I am a bit bemused by this.
>> GDB will have a good copy of the registers when it connects to openocd
>> anyway.
>
> Not necessarily true:
>
> target remote
> load
> monitor reg
> => GDB is out of sync
> stepi
> => gdb is in sync here.
>
>
but surely the regs shoul
Hi,
On 2010.01.14 15:52, Øyvind Harboe wrote:
> I'm trying to get a sense for what cables are used out there.
>
> What would you guys expect to get with a JTAG debugger?
>
> The most common seems to be the JTAG 20 cable.
>
> I've seen JTAG 14 on an older AT91EB40a.
>
> Ultimately I would expect to
> I am a bit bemused by this.
> GDB will have a good copy of the registers when it connects to openocd
> anyway.
Not necessarily true:
target remote
load
monitor reg
=> GDB is out of sync
stepi
=> gdb is in sync here.
--
Øyvind Harboe
US toll free 1-866-980-3434 / International +47 51 63
>>
>> while checking the docs i found that gdb_sync has no mention.
>> If i knew what it did i would add something - any takers?
>
> gdb_sync can be used to tell GDB not to execute a step/continue
> upon the next step/continue, but return immediately.
>
> This will refresh the GDB copy of the tar
> The docs say a maximum timeout of 11.5secs for the largest bank (512k).
My problem with these sort of optimizations is that they *must* be balanced
with an equal amount of testing. IMHO, since we discovered this on
a simple smoketest, there just isn't enough testing done to justify
having that e
Øyvind Harboe wrote:
> On Thu, Jan 14, 2010 at 3:02 PM, Spencer Oliver wrote:
http://www.st.com/stonline/products/literature/es/12944.pdf
>>> So do we apply the patch or not?
>>>
>>>
>> i would say yes, as it only slows the erase a little.
>
> Will do.
>
>> Just for info have you tried incr
Hi,
I want to try to help those poor souls who'll face the same bug trying
to use a cross-compiled windows binary made with Debian's mingw.
First, do not forget to #include before compling the
openocd sources.
Second, you need to recompile mingw-runtime due to [1].
The bug hits badly every tim
On Thu, Jan 14, 2010 at 3:02 PM, Spencer Oliver wrote:
>
>>>
>>> http://www.st.com/stonline/products/literature/es/12944.pdf
>>
>> So do we apply the patch or not?
>>
>>
>
> i would say yes, as it only slows the erase a little.
Will do.
> Just for info have you tried increasing the timeout?
No.
>>
>> http://www.st.com/stonline/products/literature/es/12944.pdf
>
> So do we apply the patch or not?
>
>
i would say yes, as it only slows the erase a little.
Just for info have you tried increasing the timeout?
The silicon you have may be getting old.
Cheers
Spen
_
I'm trying to get a sense for what cables are used out there.
What would you guys expect to get with a JTAG debugger?
The most common seems to be the JTAG 20 cable.
I've seen JTAG 14 on an older AT91EB40a.
Ultimately I would expect to users to solder their own custom JTAG
cable for smaller foot
On Thu, Jan 14, 2010 at 2:39 PM, Spencer Oliver wrote:
> Laurentiu Cocanu wrote:
>> I tested version v0.4.0-rc1-98-g6c75f52 of OpenOCD for STR912 target.
>>
>> I tried to erase all the contents of the flash, sectors 0 to 7. Commands:
>>
>> reset init
>> flash erase_address 0 0x8 (or flash eras
Laurentiu Cocanu wrote:
> I tested version v0.4.0-rc1-98-g6c75f52 of OpenOCD for STR912 target.
>
> I tried to erase all the contents of the flash, sectors 0 to 7. Commands:
>
> reset init
> flash erase_address 0 0x8 (or flash erase_sector 0 0 7)
>
> The expected result is:
>
> erased secto
I tested version v0.4.0-rc1-98-g6c75f52 of OpenOCD for STR912 target.
I tried to erase all the contents of the flash, sectors 0 to 7. Commands:
reset init
flash erase_address 0 0x8 (or flash erase_sector 0 0 7)
The expected result is:
erased sectors 0 through 7 on flash bank 0 in x.xxs
I tested version v0.4.0-rc1-98-g6c75f52 of OpenOCD for STR912 target.
I tried to erase all the contents of the flash, sectors 0 to 7. Commands:
reset init
flash erase_address 0 0x8 (or flash erase_sector 0 0 7)
The expected result is:
erased sectors 0 through 7 on flash bank 0 in x.xxs
On Thursday 14 January 2010, Øyvind Harboe wrote:
> So essentially the codepath for RESET_HAS_SRST is unchanged?
That's the idea, yes. If neither of us see a difference,
then that concept seems to have been achieved. :)
> In that case I don't have a problem with this as RESET_HAS_SRST==0 is re
So essentially the codepath for RESET_HAS_SRST is unchanged?
In that case I don't have a problem with this as RESET_HAS_SRST==0 is really
a new feature anyway.
--
Ø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 Cor
On Thursday 14 January 2010, Paul Fertser wrote:
> > The On-chip Debug support is considered being private
> > JTAG instructions, and distributed within ATMEL and to
> > selected third party vendors only.
> >
> > Clearly, someone needs to throw a JTAG/SPI sniffer at some of the
>
On Thursday 14 January 2010, Øyvind Harboe wrote:
> Actually, just push the overlong line fixes first...
Good point -- done. Appended is the updated $SUBJECT patch.
- Dave
= CUT HERE
From: David Brownell
Subject: ARM7/ARM9: improved reset support
Teach most remaining ARM
On Thu, Jan 14, 2010 at 11:36 AM, Spencer Oliver wrote:
> David Brownell wrote:
>> On Wednesday 13 January 2010, Spencer Oliver wrote:
>>> Any reason why this cannot be used before init is called ?
>>
>> No reason I can think of .. go for it!
>>
>>
>>> Cheers
>>> Spen
>>>
>>> - enable gdb_breakp
David Brownell wrote:
> On Wednesday 13 January 2010, Spencer Oliver wrote:
>> Any reason why this cannot be used before init is called ?
>
> No reason I can think of .. go for it!
>
>
>> Cheers
>> Spen
>>
>> - enable gdb_breakpoint_override to be used within config script.
>>
>> Signed-off-by
2010/1/14 David Brownell :
> On Wednesday 13 January 2010, Řyvind Harboe wrote:
>> Perhaps there will be some feedback on minor things to change,
>> perhaps use size_t i for iteration variable instead of uint32_t i...
>
> Use "unsigned" ... :)
In this case it is a bit less obvious because it is an
On Wednesday 13 January 2010, Øyvind Harboe wrote:
> Perhaps there will be some feedback on minor things to change,
> perhaps use size_t i for iteration variable instead of uint32_t i...
Use "unsigned" ... :)
___
Openocd-development mailing list
Openocd
I think breakpoint handling has been kind of a mess for a long time.
No documentation on internal interfaces ... and in some cases there
seemed to be internal conflicts.
On Wednesday 13 January 2010, yintang gu wrote:
>
> In function
>
> arm7_9_resume(struct target *target, int current, ui
At this late stage, I would like to have this patch split into
overlong lines and *actual* changes. That makes the patch
easier to review for potential regressions.
Actually, just push the overlong line fixes first...
--
Øyvind Harboe
US toll free 1-866-980-3434 / International +47 51 63 25 0
On Thu, Jan 14, 2010 at 12:16:59AM -0800, David Brownell wrote:
> On Wednesday 13 January 2010, ?yvind Harboe wrote:
> > Seing that avr is not at the level of an "official feature" I don't have
> > a problem with merging this work in progress as it does not affect
> > any other code. It can probabl
On Wednesday 13 January 2010, Øyvind Harboe wrote:
> Seing that avr is not at the level of an "official feature" I don't have
> a problem with merging this work in progress as it does not affect
> any other code. It can probably be refactored easily enough.
>
> Meanwhile we can "measure" how much
Teach most remaining ARM cores how to use the "reset-assert" event.
Same model as elsewhere: iff a handler is provided for that event,
use that instead of trying to assert SRST (which may be unavailable);
else this code is a NOP.
Shrink some overlong lines. Add my 2009 copyright.
---
This is a
Hi all,
It works! This was a simple matter of using auto erase with the flash.
flash write_image $IMGFILE 0x8000
became:
flash write_image erase $IMGFILE 0x8000
I am not sure I understand why but it works.
I will create a patch containing the changes mentioned in my first
message, when
46 matches
Mail list logo
