Debugging a Pico with ARM-USB-OCD-H and ARM-JTAG-SWD

Started by BlueLightning, March 22, 2023, 12:52:31 PM

Previous topic - Next topic

BlueLightning

I would like to debug a Pico using the Olimex ARM-USB-OCD-H and the ARM-JTAG-SWD. As per instructions online and in the manual I connected the SWD adapter directly to the ARM-USB-OCD-H.

I am using the following command line to start openocd on Linux:

openocd -f interface/ftdi/olimex-arm-usb-ocd-h.cfg -f interface/ftdi/olimex-arm-jtag-swd.cfg -f target/rp2040.cfg

This includes config files for the Olimex JTAG adapter, the SWD adapter and the target board. However, I have no idea which pins to connect to the Pico?

I did find one online resource which suggested connecting SWDIO to pin 5 and SWDCLK to pin 7 (and obviously GND to GND, pins 2,4 or 8) but I get:

$ openocd -f interface/ftdi/olimex-arm-usb-ocd-h.cfg -f interface/ftdi/olimex-arm-jtag-swd.cfg -f target/rp2040.cfg
Open On-Chip Debugger 0.12.0-rc2+dev-00037-g77c281d2d (2022-12-25-19:14)
Licensed under GNU GPL v2
For bug reports, read
   http://openocd.org/doc/doxygen/bugs.html
Info : FTDI SWD mode enabled
Warn : Transport "swd" was already selected
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Warn : An adapter speed is not selected in the init scripts. OpenOCD will try to run the adapter at the low speed (100 kHz)
Warn : To remove this warnings and achieve reasonable communication speed with the target, set "adapter speed" or "jtag_rclk" in the init scripts.
Info : clock speed 100 kHz
Error: Failed to connect multidrop rp2040.dap0

I also tried SWDIO on pin 7 as would seem apparent from looking at the olimex-arm-jtag-swd.cfg file, but have no idea where to connect the SWDCLK? I tried pin 5 but with the same result as above.

Other than the suggested command line on the purchasing page, there seems to be no documentation for the ARM-JTAG-SWD. The Wiki just has all sections 'under constructon'. The manual for the ARM-USB-OCD-H re-iterates the need to attach the SWD adapter directly to the ARM-USB-OCD-H but seems to provide no other detail. I would appreciate knowing which pins on the ARM-JTAG-SWD need to be connected to the Pico? Does there need to be a line in the olimex-arm-jtag-swd.cfg file to specify the pin for SWDCLK? Also is the adapter speed warning in any way relevant?


LubOlimex

I've seen few people using that combo. Maybe check here how VisualGDB published a guide for Olimex tools and RPI Pico:

https://visualgdb.com/documentation/embedded/raspberry/pico/swd/
Technical support and documentation manager at Olimex

BlueLightning

#2
Thanks. That's one of the references I came across and tried connecting the pins as follows:

Olimex    -> SWD
------------------
7 (TTMS)  -> SWDIO
9 (TTCK)  -> SWCLK
6 (GND)   -> GND

The openocd output remains unchanged.

I tried the Raspberry version of openocd. Seems I possibly got a little more progress, but its still getting stuck:

$ ./src/openocd -f interface/ftdi/olimex-arm-usb-ocd-h.cfg -f interface/ftdi/olimex-arm-jtag-swd.cfg -f target/rp2040.cfg -c "adapter speed 6000" -s tcl
Open On-Chip Debugger 0.11.0-g228ede4-dirty (2022-12-25-19:12)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : FTDI SWD mode enabled
Info : Hardware thread awareness created
Info : Hardware thread awareness created
Info : RP2040 Flash Bank Command
adapter speed: 6000 kHz

Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 6000 kHz
Warn : Haven't made progress in mpsse_flush() for 2042ms.
Warn : Haven't made progress in mpsse_flush() for 4082ms.
Warn : Haven't made progress in mpsse_flush() for 8162ms.
Warn : Haven't made progress in mpsse_flush() for 16068ms.
Warn : Haven't made progress in mpsse_flush() for 32134ms.
Warn : Haven't made progress in mpsse_flush() for 64011ms.
Warn : Haven't made progress in mpsse_flush() for 128020ms.
Warn : Haven't made progress in mpsse_flush() for 256037ms.
Warn : Haven't made progress in mpsse_flush() for 512073ms.

A Ctrl-C results in the following error:

Error: libusb_handle_events() failed with LIBUSB_ERROR_INTERRUPTED
Error: MPSSE failed




LubOlimex

This looks better, I feel the problem is somewhere in the OpenOCD init or usage. Did you also check this picture which shows the command:

https://visualgdb.com/w/wp-content/uploads/2021/03/rpi.png
Technical support and documentation manager at Olimex

LubOlimex

You said you got stuck but your command just starts OpenOCD GDB server:

"./src/openocd -f interface/ftdi/olimex-arm-usb-ocd-h.cfg -f interface/ftdi/olimex-arm-jtag-swd.cfg -f target/rp2040.cfg -c "adapter speed 6000" -s tcl"

It will stop there and not progress any further! It will wait for commands over the GDB. If you wish to do more you have to open second terminal over telnet over the port mentioned and send commands to the GDB server.

Alternatively instead of starting a GDB server you can use the communication to flash a binary directly...

Technical support and documentation manager at Olimex

LubOlimex

Like this, one window starts the GDB server, the other is used to issue commands to the GDB (and the first reports back how the command went):

https://i.imgur.com/nmi3J1H.jpg
Technical support and documentation manager at Olimex

BlueLightning

#6
I had tried connecting with gdb but got nowhere. There was no response to any commands even a simple halt. I suspected that the error 'Warn : Haven't made progress in mpsse_flush() for 2042ms.' meant that the openocd session is not stable and gdb is therefore unable to establish a proper connection. Clearly there is a tcp connection as gdb does not complain when doing target remote localhost:4444, but I don't seem to get a working session once connected.

Had another look at the picture that you posted and in particular the command line being configured by the software. I am running on a Linux machine so VisualGDB is not an option, so am using the command line.

I added the '-c init -c "reset init" ' part. This unfortunately resulted in the message that 'reset' is not a valid command. I therefore removed '-c "reset init"'. The next message I got was to add '-c "swd newdap"' so my command line now looks like this:

./src/openocd -f interface/ftdi/olimex-arm-usb-ocd-h.cfg -f interface/ftdi/olimex-arm-jtag-swd.cfg -f target/rp2040.cfg -c "adapter speed 3000" -c "swd newdap" -c init -s tcl

The output I see is now this:

$ ./pico-swd.sh
Open On-Chip Debugger 0.11.0-g228ede4-dirty (2022-12-25-19:12)
Licensed under GNU GPL v2
For bug reports, read
 http://openocd.org/doc/doxygen/bugs.html
Info : FTDI SWD mode enabled
Info : Hardware thread awareness created
Info : Hardware thread awareness created
Info : RP2040 Flash Bank Command
adapter speed: 3000 kHz

Missing CHIP TAP OPTIONS ....

I am not sure what that last line means?
What are CHIP TAP OPTIONS? Isn't target/rp2040.cfg meant to provide the chip config details?

BTW, can some one explain why it is necessary to use the Raspberry version of openocd to work with Raspberry devices? The OS version seems to include most of the .cfg files. What's missing from the standard OS version and why can't it be included? Wouldn't it be simpler to have one standard version instead of fragmenting into different versions for different vendors? Or is this naive of me?


LubOlimex

It might be a better idea to post in the RPi OpenOCD issues or RPi forums, since it now appears like the issues are related to the commands or the OpenOCD and we don't have RP2040 board to test anything here. The error you see now seems similar to this one:

https://forums.raspberrypi.com/viewtopic.php?t=325583

QuoteBTW, can some one explain why it is necessary to use the Raspberry version of openocd to work with Raspberry devices? The OS version seems to include most of the .cfg files. What's missing from the standard OS version and why can't it be included? Wouldn't it be simpler to have one standard version instead of fragmenting into different versions for different vendors? Or is this naive of me?

I honestly don't know, I believe asking RPi community or OpenOCD community might give you definitive answers to those questions.

Without investigating I would imagine the RPi fork probably has quick fixes to make OpenOCD work, but these fixes break the general usage of OpenOCD (for other targets) or the build doesn't follow the OpenOCD community guidelines and practices (so maintainers can't accept it).
Technical support and documentation manager at Olimex

BlueLightning

Thanks. I will probably ask over on the RPI community. I think the Olimex part of it is fine and the two config files arte pretty standard. I also think I now have the correct wiring between the target and the ARM-JTAG-SWD. I don't know whether I must use the Raspberry version of OpenOCD to access the Pico, but it did seem necessary when I did some work on the Pi3 a while back so it could be the same with the Pico. The rest of the problem does appear to be related to the behaviour of the RPi version of the OpenOCD software.