On Thursday 04 June 2009, David Brownell wrote:
>
> > ... although this touches on some other glitches in the
> > vicinity of tap enable/disable logic. The "tapenable"
> > code paths don't seem to have an obvious way to fail and
> > report that the tap was not enabled.
Still true, but not directly related to the notion that
targets on disabled taps should "just work".
> Glitch in the patch I sent, nyet sorted out: "reset" makes
> the server abort:
>
> lt-openocd: jtag_driver.c:243: interface_jtag_add_dr_scan: Assertion `field
> == out_fields + scan->num_fields' failed.
> Aborted
>
> I seem to have missed something.
There are two problems I've turned up so far, through
the startup.tcl code:
- The $target_name arp_* methods should not try to talk
to targets that are disabled.
- Conceptual problem: all the startup.tcl loops go
foreach t [target names] {
... doit ...
}
but the loop should be "for each *ENABLED* target.
Re that conceptual problem, my first thought was just
growing the loops:
if { 0 == [jtag tapisenabled $t] } {
continue
}
But for "target create MyTarget cortex_m3 -chain-position mychip.foo"
that loses, because there is no JTAG tap named MyTarget. Which just
points out another conceptual problem ... either (a) "target create"
should force target and TAP names to be the same (so "-chain-position"
becomes redundant), *or* (b) we need a "list enabled taps" primitive.
I tend to think that (a) is preferable.
Comments?
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
