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,
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
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 interest
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 probably be
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
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
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 sectors 0
On Thu, Jan 14, 2010 at 2:39 PM, Spencer Oliver s...@spen-soft.co.uk 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
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
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
On Thu, Jan 14, 2010 at 3:02 PM, Spencer Oliver s...@spen-soft.co.uk 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?
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 limits.h before compling the
openocd sources.
Second, you need to recompile mingw-runtime due to [1].
The bug hits badly
Øyvind Harboe wrote:
On Thu, Jan 14, 2010 at 3:02 PM, Spencer Oliver s...@spen-soft.co.uk 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
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 users
Ø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 should be
On Thu, Jan 14, 2010 at 4:05 PM, Spencer Oliver s...@spen-soft.co.uk 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 sync
On Wed, Jan 13, 2010 at 9:48 PM, Peter Korsgaard jac...@sunsite.dk wrote:
Øyvind == Øyvind Harboe oyvind.har...@zylin.com 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
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
would
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?
___
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 of
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 semantic
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
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
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
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
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 recently,
On Thu, Jan 14, 2010 at 11:26 PM, David Brownell davi...@pacbell.net 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
On Fri, Jan 15, 2010 at 8:18 AM, Øyvind Harboe oyvind.har...@zylin.com wrote:
On Thu, Jan 14, 2010 at 11:26 PM, David Brownell davi...@pacbell.net wrote:
On Thursday 14 January 2010, Andreas Fritiofson wrote:
Any comments on this?
I was hoping some Windows users would comment ..
I find it
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 51
+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
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
Użytkownik oyvind.har...@zylin.com 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
32 matches
Mail list logo
