#225 Error: The 'jtag configure' command must be used after 'init'.
Checking out the most recent sources from git, many configuration scripts which used to work now yield the following error instead:
openocd -f interface/ftdi/olimex-arm-usb-ocd-h.cfg -f target/imx6.cfg
Open On-Chip Debugger 0.10.0+dev-00677-gdeaf3d26-dirty (2019-02-06-11:35)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
Warn : imx6.sdma: nonstandard IR value
Error: The 'jtag configure' command must be used after 'init'.</transport>
openocd -f board/avnet_ultrazed-eg.cfg
Open On-Chip Debugger 0.10.0+dev-00677-gdeaf3d26-dirty (2019-02-06-11:35)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
none separate
none separate
adapter speed: 1000 kHz
Error: The 'jtag configure' command must be used after 'init'.
This appears to have been caused by the commit:
https://repo.or.cz/openocd.git/commit/877cec20dca6e78f9f029f0f173879cda101a6c2
I'm not sure what the correct fix would be. This does not happen with every script. (It seemed to work ok with board/nordic_nrf52_dk.cfg). I don't know if the scripts need to be updated or if the code does.
I worked around it my modifying src/jtag/tcl.c to change the mode for the jtag configure command to COMMAND_ANY (currently it's COMMAND_EXEC):
openocd -f interface/ftdi/olimex-arm-usb-ocd-h.cfg -f target/imx6.cfg
Open On-Chip Debugger 0.10.0+dev-00677-gdeaf3d26-dirty (2019-02-06-12:14)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
Warn : imx6.sdma: nonstandard IR value
adapter speed: 1000 kHz
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 1000 kHz
Info : JTAG tap: imx6.cpu tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x4)
Info : TAP imx6.sdma does not have IDCODE
Info : JTAG tap: imx6.sjc tap/device found: 0x2191c01d (mfg: 0x00e (Freescale (Motorola)), part: 0x191c, ver: 0x2)
Info : imx6.cpu.0: hardware has 6 breakpoints, 4 watchpoints
Info : Listening on port 3333 for gdb connections</transport>
My host environment is FreeBSD/amd64 11.1-RELEASE, however I observed the same problem building on an Ubuntu Linux host (16.04). The above test case is with a Freescale/NXP Sabre SD i.MX6Q target.
(Apologies if this has already been noticed and is being discussed elsewhere.)
Actually the error is in src/jtag/tcl.c
The right value for the command "jtag configure" should be COMMAND_ANY.
Before commit 877cec20dca6 there were no check on the value, so the wrong value passed unnoticed.
Our mistake, we merge the commit too quicly, without a complete audit of the commands that could have been impacted.
Since you found both bug and fix, would you mind to provide a patch in gerrit for the command "jtag configure" (and for any other command, if you have already found)?
If I did not made mistakes, here is the list of commands that are impacted by commit 877cec20dca6.
Now we need to check if any of them has wrong "mode".
Please cross check with me
Commands with mode = COMMAND_CONFIG
src/jtag/hla/hla_transport.c: "hla newdap"
src/jtag/tcl.c: "jtag newtap"
src/target/adi_v5_swd.c: "swd newdap"
src/target/target.c: "<target> configure"
src/target/target.c: "target create"</target>
every seams ok
Commands with mode = COMMAND_EXEC
src/jtag/aice/aice_transport.c: "jtag cget"
src/jtag/aice/aice_transport.c: "jtag configure"
src/jtag/aice/aice_transport.c: "jtag tapdisable"
src/jtag/aice/aice_transport.c: "jtag tapenable"
src/jtag/aice/aice_transport.c: "jtag tapisenabled"
src/jtag/hla/hla_transport.c: "hla cget"
src/jtag/hla/hla_transport.c: "hla tapenable"
src/jtag/hla/hla_transport.c: "hla tapisenabled"
src/jtag/tcl.c: "jtag cget"
src/jtag/tcl.c: "jtag configure"
src/jtag/tcl.c: "jtag drscan"
src/jtag/tcl.c: "jtag flush_count"
src/jtag/tcl.c: "jtag pathmove"
src/jtag/tcl.c: "jtag tapdisable"
src/jtag/tcl.c: "jtag tapenable"
src/jtag/tcl.c: "jtag tapisenabled"
src/target/aarch64.c: "aarch64 mcr"
src/target/aarch64.c: "aarch64 mrc"
src/target/arm946e.c: "arm946e cp15"
src/target/armv4_5.c: "arm mcr"
src/target/armv4_5.c: "arm mrc"
src/target/nds32_cmd.c: "nds bulk_read"
src/target/nds32_cmd.c: "nds bulk_write"
src/target/nds32_cmd.c: "nds multi_write"
src/target/nds32_cmd.c: "nds read_edmsr"
src/target/nds32_cmd.c: "nds write_edmsr"
src/target/target.c: "array2mem"
src/target/target.c: "mem2array"
src/target/target.c: "<target> arp_examine"
src/target/target.c: "<target> arp_halt"
src/target/target.c: "<target> arp_halt_gdb"
src/target/target.c: "<target> arp_poll"
src/target/target.c: "<target> arp_reset"
src/target/target.c: "<target> arp_waitstate"
src/target/target.c: "<target> array2mem"
src/target/target.c: "<target> curstate"
src/target/target.c: "<target> eventlist"
src/target/target.c: "<target> examine_deferred"
src/target/target.c: "<target> invoke-event"
src/target/target.c: "<target> mdb"
src/target/target.c: "<target> mdh"
src/target/target.c: "<target> mdw"
src/target/target.c: "<target> mem2array"
src/target/target.c: "<target> mwb"
src/target/target.c: "<target> mwh"
src/target/target.c: "<target> mww"
src/target/target.c: "<target> was_examined"</target></target></target></target></target></target></target></target></target></target></target></target></target></target></target></target></target></target></target>
What looks wrong here and should be mode = COMMAND_ANY are these two only:
src/jtag/aice/aice_transport.c: "jtag configure"
src/jtag/tcl.c: "jtag configure"
We should also check if command with mode COMMAND_ANY are really valid in any mode, but an error there is not breaking any script.
Antonio
I can't really confirm if these are the only things that need fixing. I only have a certain number of cases I can check. (I didn't even know there was a second instance of "jtag configure.")
So far that one command was the only one that went wrong for me. The failures I ran into were:
1) A Xilinx ZCU102 board, using its on-board Digilent (FTDI) debugger.
2) The aformentioned Freescale/NXP Sabre SD board with Olimex ARM debugger (also FTDI)
All I can say is it seems reasonable that those two cases should be changed based, on their usage in existing scripts. (I'm not exactly an expert with the scripting language; sometimes I customize existing ones but that's it.)
Note that you may be able to sanity check many opf the other scripts without needing actual hardware because the error is thrown before OpenOCD actually tries to connect to the debugger/target.
I specifically avoided submitting a patch because, as I said, what I did was just a workaround to get myself going again. I just wanted to call attention to the problem so that the appropriate maintainers could fix it right the first time.
-Bill
No problem, I will send a patch asap.
Thanks for reporting the issue.
Antonio
Fix available here http://openocd.zylin.com/4886
Bill,
I have added your name in the commit message as the person that reported the issue.
I have used your email from sourceforge. Let me know if you prefer to change it
I'm fine with the commit message as is. Thank you!
-Bill
Necesitoayuda