[Openocd-development] Error: The 'init' command must be used before 'init'.

[Øyvind Harboe]

I thought a fix for this one was pushed yesterday?

Still happens... With dummy driver even.


***@titan:~/workspace/build$ openocd -f interface/dummy.cfg -f
board/at91eb40a.cfg
Open On-Chip Debugger 0.4.0-dev-00845-g24551b7 (2009-12-04-08:26)
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
srst_only srst_pulls_trst srst_gates_jtag srst_open_drain
fast memory access is enabled
dcc downloads are enabled
16000 kHz
Info : clock speed 16000 kHz
Error: The 'init' command must be used before 'init'.
Command handler execution failed
Warn : jtag initialization failed; try 'jtag init' again.

[Zach Welch]

This is actually expected; there was no warning previously, and the
dummy driver always fails because it returns garbage.

It still starts up, right? The fact that it is telling you where
something failed is a good thing, if were talking about real hardware...
right?

--Z

Post by Øyvind Harboe
I thought a fix for this one was pushed yesterday?
Still happens... With dummy driver even.
board/at91eb40a.cfg
Open On-Chip Debugger 0.4.0-dev-00845-g24551b7 (2009-12-04-08:26)
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
srst_only srst_pulls_trst srst_gates_jtag srst_open_drain
fast memory access is enabled
dcc downloads are enabled
16000 kHz
Info : clock speed 16000 kHz
Error: The 'init' command must be used before 'init'.
Command handler execution failed
Warn : jtag initialization failed; try 'jtag init' again.

[Øyvind Harboe]

Post by Zach Welch
This is actually expected; there was no warning previously, and the
dummy driver always fails because it returns garbage.

The error message is nonsensical and offers no clues as to what
is wrong, or what needs to be fixed.

The error message needs to be fixed minimally.

Post by Zach Welch
It still starts up, right?

I don't think so. I haven't debugged it yet.

Post by Zach Welch
 he fact that it is telling you where something failed is a good thing,
if were talking about real hardware... right?

I tried on real hardware and it fails there as well, I just used the
dummy driver as an reproduction example.

I don't know what the error message means or what you are working
on here yet. I just wanted to get this info back to you for now seeing
that it was reproducible with the dummy driver I thought it might
be useful.

Is this something that you want/need me to debug?

[David Brownell]

Post by Øyvind Harboe
Error: The 'init' command must be used before 'init'.
Command handler execution failed
Warn : jtag initialization failed; try 'jtag init' again.

Yeah, everything seems to cause JTAG init to fail lately.

One issue seems to be:

==================
Not clear *why* this is happening all of a sudden, but
JTAG initialization seems to be bypassing the code
which forced the adapter to set TRST and SRST status
to zero/inactive.

On a TRST-less board, TRST is getting left as "-1"
indicating never-initialized, so tests relying on
it being only zero or one (i.e. everything after
the initialization code that's now bypassed) fail.

--- a/src/jtag/core.c
+++ b/src/jtag/core.c
@@ -153,7 +153,7 @@ bool is_jtag_poll_safe(void)
* It is also implicitly disabled while TRST is active and
* while SRST is gating the JTAG clock.
*/
- if (!jtag_poll || jtag_trst != 0)
+ if (!jtag_poll || jtag_trst == 1)
return false;
return jtag_srst == 0 || (jtag_reset_config & RESET_SRST_NO_GATING);
}
@@ -347,7 +347,7 @@ int jtag_call_event_callbacks(enum jtag_event event)

static void jtag_checks(void)
{
- assert(jtag_trst == 0);
+ assert(jtag_trst != 1);
}

static void jtag_prelude(tap_state_t state)

[Øyvind Harboe]

That's better.

I still get error messages on startup(it should have
examined the JTAG chain), but it works.

Info : clock speed 16000 kHz
Error: The 'init' command must be used before 'init'.
Command handler execution failed
Warn : jtag initialization failed; try 'jtag init' again.
Init complete, GDB & telnet servers launched.

 static void jtag_checks(void)
 {
-       assert(jtag_trst == 0);
+       assert(jtag_trst != 1);
 }

Well spotted! I saw this assert triggering w/real hardware.

[David Brownell]

Post by Øyvind Harboe
That's better.

It's an ugly hack that's papering over some real bug.

Why was the JTAG initialization bypassed? The stuff
that forces the equivalent of "jtag_reset 0 0" ?

Post by Øyvind Harboe
I still get error messages on startup(it should have
examined the JTAG chain), but it works.
Info : clock speed 16000 kHz
Error: The 'init' command must be used before 'init'.
Command handler execution failed
Warn : jtag initialization failed; try 'jtag init' again.
Init complete, GDB & telnet servers launched.

 static void jtag_checks(void)
 {
-       assert(jtag_trst == 0);
+       assert(jtag_trst != 1);
 }

Well spotted! I saw this assert triggering w/real hardware.
--
Øyvind Harboe
US toll free 1-866-980-3434 / International [phone]
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer

[Zach Welch]

Post by David Brownell

Post by Øyvind Harboe
That's better.

It's an ugly hack that's papering over some real bug.
Why was the JTAG initialization bypassed? The stuff
that forces the equivalent of "jtag_reset 0 0" ?

I just pushed another workaround needed after your last fix, so try it
again now. Does it still hurt when you run your tests?

--Z

[Øyvind Harboe]

Post by Zach Welch

Post by David Brownell

Post by Øyvind Harboe
That's better.

It's an ugly hack that's papering over some real bug.
Why was the JTAG initialization bypassed?  The stuff
that forces the equivalent of "jtag_reset 0 0" ?

I just pushed another workaround needed after your last fix, so try it
again now.  Does it still hurt when you run your tests?

Works like a charm! Thanks!

[David Brownell]

Post by Zach Welch

Post by David Brownell

Post by Øyvind Harboe
That's better.

It's an ugly hack that's papering over some real bug.
Why was the JTAG initialization bypassed? The stuff
that forces the equivalent of "jtag_reset 0 0" ?

I just pushed another workaround needed after your last fix, so try it
again now. Does it still hurt when you run your tests?

OK now.