[cw310] Enable debugging support through JTAG/OpenOCD

[imphil]

The CW310 board doesn't currently provide software debugging support through GDB, as the Nexys Video board did. Implement that.

[cryptobsv]

Implementing SCA-resistant crypto will require some assembly code. Debugging C by just putting "printf" in various places is unpleasant. Debugging assembly code (e.g. tracking register values) in this way is practically impossible. Good debugging facilities speed up software development significantly.

[moffen]

With Nexys Video no longer supported, this is badly needed.

[colinoflynn]

What hardware is actually needed for the debug - I was assuming a probe would just be attached to the JTAG port. Potentially it could be transported via the USB on the CW310 already (unrelated we had looked at implementing a 'FTDI clone mode' across all our boards to support FTDI-based tools, but not sure what is possible).

[MaayanKashani]

JTAG is basic tool for debugging on Nuvoton side as well. Needed for SW and validation teams. Please enable it on the CW310 board.

[tjaychen]

you are welcome to help triage / debug this area as well. I think right now at least, there isn't much spare bandwidth from others to do really look into this area.

On Wed, Nov 10, 2021 at 1:37 AM MaayanKashani @.***> wrote:

JTAG is basic tool for debugging on Nuvoton side as well. Needed for SW and validation teams. Please enable it on the CW310 board.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/lowRISC/opentitan/issues/8739#issuecomment-964946905, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAH2RSQEZQGQRINXWNXJVOLULI4NDANCNFSM5GJAVH6A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[colinoflynn]

If debugging via CW310 USB is preferred we'll try to enable that - it looks possible right now if we emulate the FTDI commands so openocd "just works".

I'm not sure on how the pinout of the OpenTitan top module works - there is the debug headers on the board, as mentioned my original assumption was that those headers are used with a FTDI cable or debug probe.

[tjaychen]

@colinoflynn yes you're right, that is how this should work. From usb -> ftdi to the appropriate pins on the device.

If you look here, you'll see the pins where we map jtag. So in theory, if we can just hook-up to these specific pins, and make sure the life cycle is also set correctly, everything should just work.

[markgelfgat]

It is recommended to have a standard HW Jtag interface (not only SW emulated) utilizing J13 on CW310 board (the blue 20-pin connector) to connect any OpenOCD Jtag debugger (f.e. JLink). Possible to add to FPGA support?

[tjaychen]

i feel like if there is an ftdi-type chip already on cw310 (sorry i can't remember if there was ...but nexysvideo did have one), being able to go from there directly to jtag is a much more user friendly solution, since everything is contained in one setup.

Of course, your point about using another header with a standard connector is also valid, but it would require everyone to have the set of equipment.

[colinoflynn]

The CW310 does have a microcontroller - we're checking if we can implement "FTDI-compatible" mode that would mean you don't need to have too much effort in the OpenOCD side. If this works it means a stock (or "almost stock") OpenOCD build would see part of the CW310 interface as if it was a FTDI chip. Otherwise it would require a custom patch to the OpenOCD to add the USB interface part, which will always have maintenance issues.

I suspect it won't be as efficient as an actual FTDI chip (which I think aren't the highest performance to start with). Hence my comment that an external debug probe may be easier - also if it's blocking anything "now" an external FTDI would work right away! Hopefully the built-in debug interface will be up towards end of the month or early Dec, but will get a better idea as we do more testing.

In the mean-time if things are being blocked I'd suggest using an external debug probe (is it just a FTDI breakout one needs?) would be fastest.

[tjaychen]

yeah i think just a FTDI debug cable would work. It hasn't been tried though :), and we may need to make some updates on the configurations

On Thu, Nov 11, 2021 at 11:12 AM colinoflynn @.***> wrote:

The CW310 does have a microcontroller - we're checking if we can implement "FTDI-compatible" mode that would mean you don't need to have too much effort in the OpenOCD side. If this works it means a stock (or "almost stock") OpenOCD build would see part of the CW310 interface as if it was a FTDI chip. Otherwise it would require a custom patch to the OpenOCD to add the USB interface part, which will always have maintenance issues.

I suspect it won't be as efficient as an actual FTDI chip (which I think aren't the highest performance to start with). Hence my comment that an external debug probe may be easier - also if it's blocking anything "now" an external FTDI would work right away! Hopefully the built-in debug interface will be up towards end of the month or early Dec, but will get a better idea as we do more testing.

In the mean-time if things are being blocked I'd suggest using an external debug probe (is it just a FTDI breakout one needs?) would be fastest.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/lowRISC/opentitan/issues/8739#issuecomment-966556633, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAH2RSQVUPBL5AMOPNL6WMTULQISDANCNFSM5GJAVH6A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[a-will]

When I get a chance, I can try my trusty Olimex ARM-TINY-USB-H (FTDI-based JTAG debugger) on the JTAG ports. We can just hook up the provided JTAG connectors on the CW310 board.

[colinoflynn]

This may be "imminent support" - @alex-dewar has support for OpenOCD/JTAG on our related platforms (CW-Lite), so need to confirm no issues with it running alongside everything else on the SAM3X on the CW310. But if so that should provide a solution that works as-is.

It will still be alpha however so you may want the build option of swapping the JTAG pins out to the header.

[a-will]

@colinoflynn That's good news! If it doesn't substantially harm timing, we could always allocate one of the DIP switches to select between the "on-board" and external JTAG options (if there is still a good reason to use the external one).

[cryptobsv]

I took the bitstream in CI build 20211210.6. I connected a Digilent HS2 to J13 on the CW310. Then I said: openocd -c "adapter driver ftdi" -c "ftdi_vid_pid 0x0403 0x6014" -c "ftdi_channel 0" -c "ftdi_layout_init 0x00e8 0x60eb" -c "adapter speed 30000" -c"ftdi_tdo_sample_edge falling" -c "transport select jtag" The more interesting part of the openocd output was:

...
Warn : There are no enabled taps.  AUTO PROBING MIGHT NOT WORK!!
Error: JTAG scan chain interrogation failed: all ones
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Warn : Bypassing JTAG setup events due to errors
Warn : gdb services need one or more targets defined

As a sanity check, I connected my probe's TDO to GND and got Error: JTAG scan chain interrogation failed: all zeroes as expected. Admittedly, the probe is only connected to the board with six jumper wires at the moment, but I have checked, double-checked, disconnected and reconnected everything. I'm happy to do more experiments, if it helps to resolve this issue.

[a-will]

@cryptobsv That call to openocd is missing a TAP and target declaration. See https://docs.opentitan.org/doc/ug/getting_started_fpga/#connect-with-openocd-and-debug for the instructions.

That said, the FPGA doesn't hook up the pins from J13 right now, so this won't work yet.

[cryptobsv]

I tried with a TAP definition as well. I left it out of the comment because it did not seem relevant to the main problem. Thanks for the information about J13. I suspected my reading of the comments above might have been a bit too optimistic.

[arunthomas]

@colinoflynn Thought I'd send a ping for the status of OpenOCD/JTAG support for CW310. Thanks a lot!

[colinoflynn]

@alex-dewar has this "seemingly" working - the code works on other platforms and he was seeing what (looked) like appropriate activity on the relevant lines. But no response was seen - I think there is a CW310 firmware with this enabled but I'll let him chime in to confirm. We hadn't tested with latest CW310 I admit so that was our next step but delayed for other reasons.

Is there an easy way to debug the JTAG (maybe an oxymoron?)? We can try with a fresh checkout to see if some changes since our last build just fixed it.

[alex-dewar]

Yup, https://github.com/newaetech/chipwhisperer/blob/develop/software/chipwhisperer/hardware/firmware/cwbergen.py has OpenOCD support enabled. You'll need the latest commits from the chipwhisperer repo as well. With newest firmware/chipwhisperer sw, doing

import chipwhisperer as cw
target = cw.target(None, cw.targets.CW310)
target.enable_MPSSE()

will cause the CW310 to reenumerate with two custom interfaces instead of one custom interface and two CDC serial ports.

I'm going to try routing out JTAG to the SAM3X JTAG header to see if I can connect to other devices, just in case there's some issue affecting this build and not ones on other CW devices.

[colinoflynn]

Good news - we seem to have this working (working relative to 2022 standards that is). It looks like the issue was a few FTDI commands that got used with openocd+opentitan, but not with other targets, meant we had a bug in our "FTDI mode" that we had trouble finding.

You'll need to firmware update the CW310. If you have the latest ChipWhisperer (develop branch) you can do this with:

import chipwhisperer as cw

target = cw.target(None, cw.targets.CW310)
target.upgrade_firmware()

Entering bootloader mode...
Detected com port /dev/ttyACM0
Loading cwbergen firmware...
Opened!
Connecting...
Connected!
Erasing...
Erased!
Programming file CW310.bin...
Programmed!
Verifying...
Verify OK!
Resetting...
Upgrade successful

If you prefer manual upgrade - the SAM3U firmware file is here. Note this is built from the mpsse branch, we haven't merged it to main yet.

Then - use the CW310 to program the FPGA as normal. I tested this on a FPGA bitstream built as an artifact from one of the recent commits in this repo for example (asdasd was my temp directory I put the artifact in, real high-tech):

./util/fpga/cw310_loader.py --bitstream asdasd/lowrisc_systems_chip_earlgrey_cw310_0.1.bit
./util/fpga/cw310_loader.py --firmware build-bin/sw/device/examples/hello_world/hello_world_fpga_cw310.bin --set-pll-defaults

Now the trick - you'll swap the CDC USB interface to FTDI mode (this may stop the UART from working for now btw, so if you have screen connected it dies I think). From a python3 console just run:

import chipwhisperer as cw
target = cw.target(None, cw.targets.CW310)
target.enable_MPSSE(1)

Close the Python console if you need to use cw310-loader.py again or you'll get errors. Once that mode is enabled it stays until the device resets (or is disabled with enable_MPSSE(0) which also resets it).

Note that if you power cycle the CW310 etc you'll need to re-run enable_MPSSE(1). You CAN kill openocd & re-run the cw310_loader.py files without doing anything else.

You'll need lowrisc-earlgrey-cw310.cfg and bergen-mpsse.cfg from our branch.

Then do a normal openocd spec with those new files:

/tools/openocd/bin/openocd -f board/lowrisc-earlgrey-cw310.cfg 

It looks like some error with the JTAGID we need to check, but things seem to work after that:

Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 500 kHz
Info : JTAG tap: riscv.tap tap/device found: 0x00000001 (mfg: 0x000 (<invalid>), part: 0x0000, ver: 0x0)
Warn : JTAG tap: riscv.tap       UNEXPECTED: 0x00000001 (mfg: 0x000 (<invalid>), part: 0x0000, ver: 0x0)
Error: JTAG tap: riscv.tap  expected 1 of 1: 0x04f5484d (mfg: 0x426 (Google Inc), part: 0x4f54, ver: 0x0)
Error: Trying to use configured scan chain anyway...
Warn : Bypassing JTAG setup events due to errors
Info : datacount=2 progbufsize=8
Info : Examined RISC-V core; found 1 harts
Info :  hart 0: XLEN=32, misa=0x40101106
Info : starting gdb server for riscv.tap.0 on 3333
Info : Listening on port 3333 for gdb connections
Info : accepting 'gdb' connection on tcp/3333
Info : [riscv.tap.0] Found 1 triggers

Then I used this:

/tools/riscv/bin/riscv32-unknown-elf-gdb -ex "target extended-remote :3333" -ex "info reg" sw/device/examples/hello_world/hello_world_fpga_cw310.elf

Note that loading seems to have errors. If that is the case just use cw310_loader.py to reload. Be sure to kill the openocd before you do that, otherwise there will be problems with the JTAG/SPI pin conflict I think. You need to rerun openocd after running cw310_loader.py so that the JTAG pins get set back up.

For reference when loading via gdb we see this in gdb:

(gdb) load
Loading section .flash_header, size 0x4 lma 0x80000000
Loading section .crt, size 0xce lma 0x80000004
Loading section .vectors, size 0x80 lma 0x80000100
Load failed

And this in openocd:

Info : accepting 'gdb' connection on tcp/3333
Warn : Failed to write memory via program buffer.
Warn : Failed to write memory via abstract access.
Error: Target riscv.tap.0: Failed to write memory (addr=0x800000d0)
Error:   progbuf=failed, sysbus=skipped (unsupported size), abstract=failed

This could still be some JTAG error, but we weren't sure how JTAG/openocd had been used recently so perhaps there is just a config change we hadn't reflected in our openocd files. That earlier JTAGID error is suspicious, but it seems for example using stepi in gdb shows it stepping through instructions OK. So it seems this shows the debug/JTAG interface working?

(gdb) stepi
[riscv.tap.0] Found 1 triggers
0x80000fa2      15      in ../../s/sw/device/lib/runtime/hart.c
(gdb) 
0x80000fa4      15      in ../../s/sw/device/lib/runtime/hart.c
(gdb) 
0x80000fb0      15      in ../../s/sw/device/lib/runtime/hart.c
(gdb) 
0x80000fb4      15      in ../../s/sw/device/lib/runtime/hart.c
(gdb) 

[cryptobsv]

Thanks for looking into this. I see some unexpected behaviour:

1. disas reads only 0xffff and hence cannot disassemble code. However, x shows the correct code memory content.
2. Setting breakpoints does not seem to work. OpenOCD says Couldn't find an available hardware trigger. and can't add breakpoint: resource not available. Is there an easy fix for these two issues?

[colinoflynn]

Moving some discussion from #12633, I built a new CW310 firmware (see the debug directory) to reflect the updated strapping pins. I'm not 100% sure of order they need to be toggled in, instead as a test:

1) You can adjust bergen-mpsse.cfg to ignore the aux pins by setting the ftdi layout_init as:

ftdi layout_init 0x0008 0x000b

And commenting out the ftdi layout_signal lines. Running that seemed to give some non-random output, but clearly invalid:

nfo : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 500 kHz
Info : TAP riscv.tap does not have valid IDCODE (idcode=0xfd6cb27a)
Info : JTAG tap: auto0.tap tap/device found: 0xfeb6593d (mfg: 0x49e (Allwinner Technology), part: 0xeb65, ver: 0xf)
Info : JTAG tap: auto1.tap tap/device found: 0xad8d7ac1 (mfg: 0x560 (Shenzhen OSCOO Tech Co Ltd), part: 0xd8d7, ver: 0xa)
Info : TAP auto2.tap does not have valid IDCODE (idcode=0xd111bd5e)
Info : JTAG tap: auto3.tap tap/device found: 0x6888deaf (mfg: 0x757 (<unknown>), part: 0x888d, ver: 0x6)
Info : TAP auto4.tap does not have valid IDCODE (idcode=0x366a0092)
Info : JTAG tap: auto5.tap tap/device found: 0x9b350049 (mfg: 0x024 (IBM), part: 0xb350, ver: 0x9)
Info : JTAG tap: auto6.tap tap/device found: 0x7060cd6b (mfg: 0x6b5 (<unknown>), part: 0x060c, ver: 0x7)
Info : TAP auto7.tap does not have valid IDCODE (idcode=0xec499ffa)
Info : JTAG tap: auto8.tap tap/device found: 0x7624cffd (mfg: 0x7fe (<unknown>), part: 0x624c, ver: 0x7)
Info : TAP auto9.tap does not have valid IDCODE (idcode=0x5ab14ff8)
Info : TAP auto10.tap does not have valid IDCODE (idcode=0x2d58a7fc)
Info : TAP auto11.tap does not have valid IDCODE (idcode=0x16ac53fe)
Info : JTAG tap: auto12.tap tap/device found: 0x0b5629ff (mfg: 0x4ff (<invalid>), part: 0xb562, ver: 0x0)
Info : JTAG tap: auto13.tap tap/device found: 0x65589db1 (mfg: 0x6d8 (<unknown>), part: 0x5589, ver: 0x6)
Info : JTAG tap: auto14.tap tap/device found: 0xbe424905 (mfg: 0x482 (VMware Inc), part: 0xe424, ver: 0xb)
Info : JTAG tap: auto15.tap tap/device found: 0x653fbfbf (mfg: 0x7df (<unknown>), part: 0x53fb, ver: 0x6)
Info : JTAG tap: auto16.tap tap/device found: 0x65656565 (mfg: 0x2b2 (Focus Enhancements), part: 0x5656, ver: 0x6)
Info : JTAG tap: auto17.tap tap/device found: 0x65656565 (mfg: 0x2b2 (Focus Enhancements), part: 0x5656, ver: 0x6)
Info : JTAG tap: auto18.tap tap/device found: 0x65656565 (mfg: 0x2b2 (Focus Enhancements), part: 0x5656, ver: 0x6)
Info : JTAG tap: auto19.tap tap/device found: 0x65656565 (mfg: 0x2b2 (Focus Enhancements), part: 0x5656, ver: 0x6)
Warn : Unexpected idcode after end of chain: 455 0x65656565
Warn : Unexpected idcode after end of chain: 487 0x65656565
Warn : Unexpected idcode after end of chain: 519 0x65656565
Warn : Unexpected idcode after end of chain: 551 0x65656565
Warn : Unexpected idcode after end of chain: 583 0x65656565
Warn : Unexpected idcode after end of chain: 615 0x65656565
Error: double-check your JTAG setup (interface, speed, ...)
Error: Trying to use configured scan chain anyway...
Error: riscv.tap: IR capture error; saw 0x12 not 0x01
Warn : Bypassing JTAG setup events due to errors
Error: Unsupported DTM version: 2
Warn : target riscv.tap.0 examination failed
Info : starting gdb server for riscv.tap.0 on 3333
Info : Listening on port 3333 for gdb connections

The cw310 loader already has the strapping mapping, so some config should be able to be done in that. As a very simplistic example, using hard-coded pin names (schematic names):

import time
import chipwhisperer as cw
target = cw.target(None, cw.targets.CW310)

snake_gpio = target.gpio_mode()
snake_gpio.pin_set_output('USB_A13')#TRST
snake_gpio.pin_set_output('USB_A14')#SRST
snake_gpio.pin_set_output('USB_A15')#PIN_SW_STRAP0
snake_gpio.pin_set_output('USB_A16')#PIN_SW_STRAP1
snake_gpio.pin_set_output('USB_A17')#PIN_SW_STRAP2
snake_gpio.pin_set_output('USB_A18')#TAP_STRAP0
snake_gpio.pin_set_output('USB_A19')#TAP_STRAP1

snake_gpio.pin_set_state('USB_A13', 1) #TRST
snake_gpio.pin_set_state('USB_A14', 1) #SRST

snake_gpio.pin_set_state('USB_A18', 0) #TAP_STRAP0 
snake_gpio.pin_set_state('USB_A19', 1) #TAP_STRAP1

snake_gpio.pin_set_state('USB_A15', 0) #SW_STRAP0
snake_gpio.pin_set_state('USB_A16', 0) #SW_STRAP1
snake_gpio.pin_set_state('USB_A17', 0) #SW_STRAP2

snake_gpio.pin_set_state('USB_A19', 1)
snake_gpio.pin_set_state('USB_A14', 0)
time.sleep(0.1)
snake_gpio.pin_set_state('USB_A14', 1)
snake_gpio.pin_set_state('USB_A19', 1)

#MPSSE time for OpenOCD
target.enable_MPSSE(1)

However I'm not 100% sure the actual status of the JTAG scanchain etc, or what the new strapping configuration is needed to ensure I'm seeing the right stuff?

[vogelpi]

Thanks @colinoflynn for looking into this. I am not sure on how to enable JTAG exactly. Based on https://github.com/lowRISC/opentitan/blob/d7325402e8b86c5df9c79d19c37587df2a356797/util/fpga/cw_spiflash.py#L188-L209

I would say this looks right. Probably @msfschaffner knows the exact sequence needed.

[colinoflynn]

OK I had tried something like that too - running the cw_spiflash.py to load the binary then connecting with JTAG gave me the above scan chain (I disabled the other strapping pins from being under OpenOCD control). But I'm not sure if the scan chain itself changed at all or it should be the same as before?

Primarily I wasn't sure if the JTAG/SPI mux was maybe an issue and I wasn't getting it strapped into JTAG mode.

[msfschaffner]

Hm, the strapping sequence to select the JTAG TAP looks correct to me.

The life cycle state is currently preset to RMA on the FPGA, so the TAP selection straps are sampled continuously. This means that we can switch back and forth between normal functional mode and JTAG dynamically without resetting the device. See this section in the pinmux docs for more info on strap sampling.

In terms of pin mapping, this seems to be correct also, see XDC here: https://github.com/lowRISC/opentitan/blob/416467bc10f2da23b5da77b699ae25ba95930def/hw/top_earlgrey/data/pins_cw310.xdc#L46-L61 and pinout table here (rendered version in the docs): https://github.com/lowRISC/opentitan/blob/416467bc10f2da23b5da77b699ae25ba95930def/hw/top_earlgrey/data/top_earlgrey.hjson#L1409-L1419

Is the OpenOCD output above supposed to show the RV tap JTAG ID (manufacturer / part)? If so, I can't find the ID that we currently assign to our RV_DM TAP: https://github.com/lowRISC/opentitan/blob/416467bc10f2da23b5da77b699ae25ba95930def/hw/top_earlgrey/rtl/jtag_id_pkg.sv#L8-L15

Some more ideas what we could try:

• assert both SRST and TRST (not only SRST) during the strapping sequence, and then release them together.
• double check the JTAG interface is mapped onto the SPI SCK, SDI, SDO and CS pins.
• double check the XDC assignments are actually correct (the FPGA side should be, but maybe the SAM3X side is not).

[vogelpi]

After updating the SAM3X firmware and running

import chipwhisperer as cw
target = cw.target(None, cw.targets.CW310)
target.enable_MPSSE(1)

I got a bit further. OpenOCD now returns:

openocd -f board/lowrisc-earlgrey-cw310.cfg
Open On-Chip Debugger 0.11.0
Licensed under GNU GPL v2
For bug reports, read
    http://openocd.org/doc/doxygen/bugs.html
Info : Hardware thread awareness created
force hard breakpoints
none separate

Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 500 kHz
Info : JTAG tap: test.tap tap/device found: 0xdfdfdfdf (mfg: 0x7ef (<unknown>), part: 0xfdfd, ver: 0xd)
Info : JTAG tap: riscv.tap tap/device found: 0xdfdfdfdf (mfg: 0x7ef (<unknown>), part: 0xfdfd, ver: 0xd)
Warn : JTAG tap: riscv.tap       UNEXPECTED: 0xdfdfdfdf (mfg: 0x7ef (<unknown>), part: 0xfdfd, ver: 0xd)
Error: JTAG tap: riscv.tap  expected 1 of 1: 0x04f5484d (mfg: 0x426 (Google Inc), part: 0x4f54, ver: 0x0)  // <-- RV_DM
Info : JTAG tap: auto0.tap tap/device found: 0xdfdfdfdf (mfg: 0x7ef (<unknown>), part: 0xfdfd, ver: 0xd)
Info : JTAG tap: auto1.tap tap/device found: 0xdfdfdfdf (mfg: 0x7ef (<unknown>), part: 0xfdfd, ver: 0xd)
Info : JTAG tap: auto2.tap tap/device found: 0xdfdfdfdf (mfg: 0x7ef (<unknown>), part: 0xfdfd, ver: 0xd)
Info : JTAG tap: auto3.tap tap/device found: 0xdfdfdfdf (mfg: 0x7ef (<unknown>), part: 0xfdfd, ver: 0xd)
Info : JTAG tap: auto4.tap tap/device found: 0xdfdfdfdf (mfg: 0x7ef (<unknown>), part: 0xfdfd, ver: 0xd)
Info : JTAG tap: auto5.tap tap/device found: 0xdfdfdfdf (mfg: 0x7ef (<unknown>), part: 0xfdfd, ver: 0xd)
Info : JTAG tap: auto6.tap tap/device found: 0xdfdfdfdf (mfg: 0x7ef (<unknown>), part: 0xfdfd, ver: 0xd)
Info : JTAG tap: auto7.tap tap/device found: 0xdfdfdfdf (mfg: 0x7ef (<unknown>), part: 0xfdfd, ver: 0xd)
Info : JTAG tap: auto8.tap tap/device found: 0xdfdfdfdf (mfg: 0x7ef (<unknown>), part: 0xfdfd, ver: 0xd)
Info : JTAG tap: auto9.tap tap/device found: 0xdfdfdfdf (mfg: 0x7ef (<unknown>), part: 0xfdfd, ver: 0xd)
Info : JTAG tap: auto10.tap tap/device found: 0xdfdfdfdf (mfg: 0x7ef (<unknown>), part: 0xfdfd, ver: 0xd)
Info : JTAG tap: auto11.tap tap/device found: 0xdfdfdfdf (mfg: 0x7ef (<unknown>), part: 0xfdfd, ver: 0xd)
Info : JTAG tap: auto12.tap tap/device found: 0xdfdfdfdf (mfg: 0x7ef (<unknown>), part: 0xfdfd, ver: 0xd)
Info : JTAG tap: auto13.tap tap/device found: 0xdfdfdfdf (mfg: 0x7ef (<unknown>), part: 0xfdfd, ver: 0xd)
Info : JTAG tap: auto14.tap tap/device found: 0xdfdfdfdf (mfg: 0x7ef (<unknown>), part: 0xfdfd, ver: 0xd)
Info : JTAG tap: auto15.tap tap/device found: 0xdfdfdfdf (mfg: 0x7ef (<unknown>), part: 0xfdfd, ver: 0xd)
Info : JTAG tap: auto16.tap tap/device found: 0xdfdfdfdf (mfg: 0x7ef (<unknown>), part: 0xfdfd, ver: 0xd)
Info : JTAG tap: auto17.tap tap/device found: 0xdfdfdfdf (mfg: 0x7ef (<unknown>), part: 0xfdfd, ver: 0xd)
Info : JTAG tap: auto18.tap tap/device found: 0xdfdfdfdf (mfg: 0x7ef (<unknown>), part: 0xfdfd, ver: 0xd)
Error: Trying to use configured scan chain anyway...
Error: test.tap: IR capture error; saw 0x1f not 0x01
Warn : Bypassing JTAG setup events due to errors
Error: Unsupported DTM version: 15
Warn : target riscv.tap.0 examination failed
Info : starting gdb server for riscv.tap.0 on 3333
Info : Listening on port 3333 for gdb connections
^Cshutdown command invoked
Error: Unsupported DTM version: 15

So, OpenOCD actually recognizes the debug module but reading out the registers fails. OpenOCD seems to get 0xdfdfdfdf for the DTMCSR (and also other registers). The LSBs of the DTMCSR register should be 0x1 instead of 0xF according to the doc.

To make sure my OpenOCD installation is not completely broken, I've connected to RV_DM in the Verilator simulation. This works fine.

[a-will]

Warn : JTAG tap: riscv.tap UNEXPECTED: 0xdfdfdfdf (mfg: 0x7ef (), part: 0xfdfd, ver: 0xd) Error: JTAG tap: riscv.tap expected 1 of 1: 0x04f5484d (mfg: 0x426 (Google Inc), part: 0x4f54, ver: 0x0) // <-- RV_DM

@vogelpi These two lines go together. The line with "expected" is saying what it did not find. So whatever is responding is constantly putting out a 0xfd or 0xdf pattern. :smiley:

[vogelpi]

Ah, so you're saying there is something else constantly spamming the JTAG.

[moidx]

We are working on using a JTAG cable connection. Pending documentation updates.

[a-will]

Closing, as JTAG support was implemented in #13464 and documented in #13744. The decision to pause pursuits of JTAG through the SAM3X came from the silicon WG meeting, after discussing #13552.