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
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, thanks for helping with this patch!
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.
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
Ø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 save
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:
> 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
http://svn.berlios.de/svnroot/repos/openocd/trun
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:
> 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 Mic
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
http://consultin
> 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?
> 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
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 > 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/svn
Michael Bruck wrote:
> On Thu, May 21, 2009 at 1:39 PM, Dirk Behme 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/tar
On Thu, May 21, 2009 at 1:39 PM, Dirk Behme 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
Did y
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 h
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 wrote:
>
> On May 20, 20
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
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 seems to work. Found while playing with OMAP3
scri
19 matches
Mail list logo