Dirk Behme skrev:
Zach Welch wrote:
On Fri, 2009-05-22 at 10:57 +0200, Øyvind Harboe wrote:
Trying again...
My editor is screwing things up with whitespace, hence all those irrelevant
changes...
The second attempt was no better. Here it is done right.
First,
On Fri, 2009-05-22 at 10:57 +0200, Øyvind Harboe wrote:
Trying again...
My editor is screwing things up with whitespace, hence all those irrelevant
changes...
The second attempt was no better. Here it is done right.
Please let me know if this fixes things, and I will get it committed.
Looking at your configuration scripts, they should *not* call init
once they are implemented correctly.
This does mean that omap3.cpu has to be enabled *before* it can be used (?)
On the other hand, in previous discussion, we had learned that init has to
be called *after* target create. But
Øyvind Harboe wrote:
Looking at your configuration scripts, they should *not* call init
once they are implemented correctly.
Do you like to give any hints how to implement them correctly and what
do you think is wrong with them?
We talk about
I'm going to be out of the office for the next week, so I'm turning into
a pumpkin RSN.
omap3_dbginit should be made part of the reset sequence.
OpenOCD supports hot-plugging of targets. Feel free to scream, but this
is something that developers do since it saves time. If it bricks a beagleboard
Øyvind Harboe wrote:
I'm going to be out of the office for the next week, so I'm turning into
a pumpkin RSN.
omap3_dbginit should be made part of the reset sequence.
OpenOCD supports hot-plugging of targets. Feel free to scream, but this
is something that developers do since it saves
Trying again...
My editor is screwing things up with whitespace, hence all those irrelevant
changes...
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/target/cortex_m3.c
On May 20, 2009, at 11:03 PM, Dirk Behme wrote:
Just want to let you know that with recent svn head r1870 I get
trying to validate configured JTAG chain anyway...
openocd: jtag.c:889: interface_jtag_add_dr_scan: Assertion `field ==
out_fields + scan-num_fields' failed.
while at least r1865
Dirk, did this happen when you used the drscan/irscan commands?
Given that this is only an assert I think we'll have to add more
checking to these commands to give meaningful errors if someone uses
them incorrectly.
Michael
On Thu, May 21, 2009 at 8:15 AM, Rick Altherr kc8...@kc8apf.net wrote:
Michael Bruck wrote:
Dirk, did this happen when you used the drscan/irscan commands?
Not sure, but possible. Have a look to tap-enable event of
http://svn.berlios.de/svnroot/repos/openocd/trunk/src/target/target/omap3530.cfg
Given that this is only an assert
Well, at least OpenOCD stopped
On Thu, May 21, 2009 at 1:39 PM, Dirk Behme dirk.be...@googlemail.com wrote:
Michael Bruck wrote:
Dirk, did this happen when you used the drscan/irscan commands?
Not sure, but possible. Have a look to tap-enable event of
Michael Bruck wrote:
On Thu, May 21, 2009 at 1:39 PM, Dirk Behme dirk.be...@googlemail.com wrote:
Michael Bruck wrote:
Dirk, did this happen when you used the drscan/irscan commands?
Not sure, but possible. Have a look to tap-enable event of
On May 21, 2009, at 10:13 AM, Dirk Behme wrote:
Michael Bruck wrote:
On Thu, May 21, 2009 at 1:39 PM, Dirk Behme dirk.be...@googlemail.com
wrote:
Michael Bruck wrote:
Dirk, did this happen when you used the drscan/irscan commands?
Not sure, but possible. Have a look to tap-enable event of
Would have been nice before making this change in public svn it would
have been tested with all available configurations.
If you want to pitch in on adding stuff to test/selftest.cfg then we can get
more testing before committing stuff... The idea is that, eventually, we'll
be able to do a lot
If you like you can try it your own: Configure recent trunk (1875) with
--enable-dummy and then
openocd -s lib/openocd/ -f interface/dummy.cfg -f board/ti_beagleboard.cfg
This will result in
-- cut --
Open On-Chip Debugger 0.2.0-in-development (2009-05-21-19:06) svn:1875
BUGS? Read
This assert happens because a drscan is executed on a disabled TAP.
i.e. it is not in OpenOCD's list of enabled TAP's, the physical device
might very well be enabled.
How would you like OpenOCD to tell you this?
--
Øyvind Harboe
Embedded software and hardware consulting services
Øyvind Harboe wrote:
This assert happens because a drscan is executed on a disabled TAP.
i.e. it is not in OpenOCD's list of enabled TAP's, the physical device
might very well be enabled.
How would you like OpenOCD to tell you this?
Øyvind: I'm not sure if this question is for me or
17 matches
Mail list logo
