> I see no problem ... TAP_RESET is a stable state, and
> JTAG adapters are allowed to let TCK run freely there.
But that's not what the code is doing. It goes to TAP_RESET,
then cycles 100 times in runtest idle and then back to TAP_RESET....
I guess I would be more comfortable with a change that cycled
100 clocks in reset.... that's probably harmless everywhere and
would let us invent a more generic scheme in time if it ever proved
necessary.
(non-sequitor: can we break out new discussion threads
a bit more often... easier to track residual issues....)
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
Partial fix for TAPs which need extra TCK cycles in the TAP_RESET
state. This relies on the fact that TAP_RESET is a stable state,
where TCK may run freely, and always issues those TCK cycles.
This doesn't address entry to TAP_RESET using TRST. Fixing that
will require calling jtag_add_tlr() after deasserting TRST.
---
src/jtag/core.c | 9 +++++++++
1 file changed, 9 insertions(+)
--- a/src/jtag/core.c
+++ b/src/jtag/core.c
@@ -469,6 +469,15 @@ void jtag_add_tlr(void)
{
jtag_prelude(TAP_RESET);
jtag_set_error(interface_jtag_add_tlr());
+
+ /*
+ * Add a bunch of clocks after TLR entry to force SWD reset (newer
+ * ARM cores; just in case, ~50 cycles), switch on ICEpick power
+ * domains (for some TI parts, ~100 cycles), etc. TAP_RESET is a
+ * stable state, so this must be harmless to all JTAG controllers.
+ */
+ jtag_set_error(interface_jtag_add_runtest(100, TAP_RESET));
+
jtag_call_event_callbacks(JTAG_TRST_ASSERTED);
}
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
