openocd command stuck in mpsse_flush() loop

[hadirkhan10]

Hello, I created a basic rtl from chipyard that is correctly being mapped on the arty-35 fpga and uses the same jtag configuration as the freedom e30 configuration. I am trying to connect the design with JTAG using the Olimex ARM-USB-TINY-H hardware. Following their manual, here is how I configured the openocd:

git clone https://github.com/riscv/riscv-openocd.git
cd riscv-openocd
./bootstrap
./configure --enable-ftdi --enable-ft2232_ftd2xx
make
make install

After this I created a board configuration file that looks something like this:

# JTAG adapter setup
adapter speed 1000
set chain_length 5
set _CHIPNAME riscv
jtag newtap $_CHIPNAME cpu -irlen $chain_length

set _TARGETNAME_0 $_CHIPNAME.cpu

target create $_TARGETNAME_0 riscv -chain-position $_TARGETNAME_0
init
halt

Then I am running the openocd command like this:

cd riscv-openocd
src/openocd -f tcl/interface/ftdi/olimex-arm-usb-tiny-h.cfg -f <path/to/my-board.cfg>

After running this command, I get the following output on the terminal:

Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
Info : clock speed 1000 kHz
Warn : Haven't made progress in mpsse_flush() for 2182ms.
Warn : Haven't made progress in mpsse_flush() for 4222ms.
Warn : Haven't made progress in mpsse_flush() for 8046ms.
Warn : Haven't made progress in mpsse_flush() for 16205ms.
Warn : Haven't made progress in mpsse_flush() for 32013ms.

This continues until I press CTRL+C which then exits and returns this error:

Error: libusb_handle_events() failed with LIBUSB_ERROR_INTERRUPTED

[jamesdunn]

Hello,

I'm not familiar enough with OpenOCD to know what exactly an mpsse_flush() loop indicates, but I worked on Arty support in Chipyard, so maybe I can offer a few initial debug tips. I can connect to a Chipyard build on Arty fine with the Olimex debugger, using your procedure for building and invoking riscv-openocd (where test.cfg is your configuration file) on Ubuntu 20.04:

$ ./src/openocd -f tcl/interface/ftdi/olimex-arm-usb-tiny-h.cfg -f src/test.cfg 
Open On-Chip Debugger 0.11.0-rc2+dev-01538-gd57ab0b63 (2021-02-13-12:52)
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>'.
Info : clock speed 1000 kHz
Info : JTAG tap: riscv.cpu tap/device found: 0x20000913 (mfg: 0x489 (SiFive Inc), part: 0x0000, ver: 0x2)
Info : datacount=1 progbufsize=16
Info : Disabling abstract command reads from CSRs.
Info : Examined RISC-V core; found 1 harts
Info :  hart 0: XLEN=32, misa=0x40801105
Info : starting gdb server for riscv.cpu on 3333
Info : Listening on port 3333 for gdb connections
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : accepting 'gdb' connection on tcp/3333

Have you tried using a pre-built riscv-openocd binary? They have one available on SiFive's software page, and I can also use it to connect to the Arty flashed with a Chipyard bitfile. This would tell you if it is an issue with your build of openocd.

Have you tried connecting with these same steps to an Arty flashed with SiFive's Freedom bitfile? If you can successfully connect in that case, it would indicate an issue with JTAG in your Chipyard build. If you can't, it would indicate an issue with the debugger's connection to the Arty board, or maybe an issue with FTDI drivers on your OS.

Have you double-checked the JTAG pin header connections per the Freedom Arty guide?

You can also get a more verbose output from openocd by running it with the -d flag.

[hadirkhan10]

@jamesdunn I followed the first step of debugging by downloading OpenOCD from Sifive's website. Upon running openocd from there like the following command:

./bin/openocd -f share/openocd/scripts/interface/ftdi/olimex-arm-usb-tiny-h.cfg -f <path/to/mycfg.cfg>

I get the following output:

Open On-Chip Debugger 0.10.0+dev (SiFive OpenOCD 0.10.0-2020.04.6)
Licensed under GNU GPL v2
For bug reports:
	https://github.com/sifive/freedom-tools/issues
Warn : Interface already configured, ignoring
Info : clock speed 1000 kHz
Error: Timed out handling USB events in mpsse_flush().
Error: ftdi device did not return all data: 0, expected 85
Segmentation fault (core dumped)

[jamesdunn]

This appears to be the same issue, so likely not a problem with your build of riscv-openocd.

Please try flashing the Arty with the Freedom image, described here, and see if you get the same behavior.

Please also double-check wiring between the Olimex debugger and Arty PMOD header, and also run OpenOCD using the -d flag for more debugging output.

[timsifive]

I added the code that generates that error message in d214cadfef. It was to work around a bug where OpenOCD would intermittently hang while waiting for USB data from an Olimex adapter. IIRC I was running OpenOCD in Linux in a VM at the time. I haven't seen this error in ages, and it never reproduced consistently for me. Perhaps on your system the timeout (2 seconds) is too small?

[hadirkhan10]

So I flashed the .mcs file available from SiFive's website and it runs fine since I can see the SiFive logo on the UART terminal and a blinking RGB LED. However, I am noticing some abnormal behavior when I connect the Olimex hardware jumpers to the JD PMOD headers (even when the USB connection between the Host PC and Olimex hardware is not made), the blinking RGB LED turns off and the normal LED (LD4 and LD6) on the Arty board, turns on. A light red LED turns on in the Olimex hardware after the connection with the host PC. But, when I try to upload the program from the freedom-e-sdk, I get the following error:

scripts/upload --elf /home/merl/Desktop/freedom-e-sdk/software/hello/debug/hello.elf --openocd /home/merl/Downloads/riscv-openocd-0.10.0-2020.04.6-x86_64-linux-ubuntu14/bin/openocd --gdb /home/merl/Downloads/riscv64-unknown-elf-gcc-8.3.0-2020.04.0-x86_64-linux-ubuntu14/bin/riscv64-unknown-elf-gdb --openocd-config bsp/freedom-e310-arty/openocd.cfg
Open On-Chip Debugger 0.10.0+dev (SiFive OpenOCD 0.10.0-2020.04.6)
Licensed under GNU GPL v2
For bug reports:
	https://github.com/sifive/freedom-tools/issues
Using JTAG
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
Info : ftdi: if you experience problems at higher adapter clocks, try the command "ftdi_tdo_sample_edge falling"
Info : clock speed 10000 kHz
Error: JTAG scan chain interrogation failed: all zeroes
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Error: riscv.cpu: IR capture error; saw 0x00 not 0x01
Warn : Bypassing JTAG setup events due to errors
Error: dtmcontrol is 0. Check JTAG connectivity/board power.
Info : Listening on port 3333 for gdb connections
Error: Target not examined yet

localhost:3333: Connection timed out.
"monitor" command not supported by this target.
"monitor" command not supported by this target.
You can't do that when your target is `exec'
"monitor" command not supported by this target.
"monitor" command not supported by this target.

After this the LED on the Olimex hardware turns off.

I faced this before as well when I manually ran the openocd with a configuration file as described in the Rocketchip repository. I figured out that when I changed the .cfg file and removed the adapter speed setting and then ran openocd, it fails and the Olimex's LED turns back on as bright red (Doesn't make sense but maybe it was stuck in some loop). Then again I reset my .cfg file with the adapter speed present and it removes the above mentioned error of "Check JTAG connectivity/board power" but gives me those errors mpsse_flush().

[hadirkhan10]

Update: Not connecting the nRST (grey jumper) to the JD PMOD Pin 9 and the nTRST (orange jumper) to the JD PMOD Pin 2 removes the abnormal behavior (RGB LED Blinking turns off. No SiFive logo on the UART screen anymore) however, still doing a make upload through the freedom-e-sdk causes the same error dtmcontrol is 0. Check JTAG connectivity/board power.

[nachoge98]

Update: Not connecting the nRST (grey jumper) to the JD PMOD Pin 9 and the nTRST (orange jumper) to the JD PMOD Pin 2 removes the abnormal behavior (RGB LED Blinking turns off. No SiFive logo on the UART screen anymore) however, still doing a make upload through the freedom-e-sdk causes the same error dtmcontrol is 0. Check JTAG connectivity/board power.

In the file ~/freedom-e-sdk/bsp/freedom-e-310-arty/openocd.cfg of the freedom-e-sdk repository from SiFive, they have this:

if {[ info exists pulse_srst]} {
  ftdi_set_signal nSRST 0
  ftdi_set_signal nSRST z
  sleep 1500
}

I am not sure it is related but maybe helps with the nRST jumper problem

[en-sc]

@hadirkhan10, could you please check if the issue is still relevant? Otherwise I would like to close it.