Incorrect signal configuration for OpenOCD

[tchebb]

I'm confused about the following bit of the OpenOCD configuration in the README:

ftdi_layout_init 0x0078 0x017b
ftdi_layout_signal nTRST -ndata 0x0010 -noe 0x0040
ftdi_layout_signal nSRST -ndata 0x0020 -noe 0x0040

Comparing this to the v1.1 schematic, there seem to be several inconsistencies:

1. The data direction bitmask (0x017b) sets BD6 and BC0 as outputs, even though BD6 is connected to the input buffer (and not used for JTAG) and BC0 is unconnected exactly like BC1-7, which are all set as inputs.
2. The nTRST and nSRST signals use BD6 as an output enable (which OpenOCD uses to tristate the pins), but that pin isn't connected to the output buffer at all. In reality, the nTRST and nSRST signals are not tristatable because we keep the output buffer enabled at all times.
3. The nTRST and nSRST signals use -ndata instead of -data, meaning OpenOCD inverts the signals it puts on the pins. The signals are not inverted in hardware, though, meaning that asserting either of these signals brings it high instead of low. I've verified that this is the case with my Tigard.

Is there something I'm missing? I'd expect the config to look like this, given Tigard's shipping hardware:

ftdi_layout_init 0x0038 0x003b
ftdi_layout_signal nTRST -data 0x0010
ftdi_layout_signal nSRST -data 0x0020

[securelyfitz]

Thanks for noticing this.
The openocd config is derived from the one i've been using for years with various ftdi boards, sometimes with additional hardware and sometimes without. One used BD6 as an enable on a level shifter.
I need to check on point 3 though - I use several devices with nTRST that shouldn't be working at all if the signal was inverted, but the do seem to work. I'll check those out and update the readme once i confirm what's happening.

[tchebb]

FYI, I've posted a draft change for upstream OpenOCD to add a config file for Tigard: https://review.openocd.org/c/openocd/+/6952. I wrote this config from scratch based on the schematics, but it's pretty similar to the one in the README save for the signal layout. I'll wait until you're done investigating on your end to mark it as ready for review, though.

[securelyfitz]

Thanks for your patience.
I have a couple targets that use the nTRST signal and work fine with tigard's existing (flawed) config file. Observing on a scope, i understand why. The board config files i'm using don't include any direct control of ntrst or nsrst - which means openocd leaves them high with either tigard config file.

On one device I have that pulls nTRST low, openocd leaves it high, which 'enables' jtag on that target. By default openocd uses tms/tck reset, so everything works fine.

On another device, while i have nSRST wired, openocd is using a jtag-command-triggered reset instead of the nSRST signal.

So 1) the changes you propose are correct 2) they don't break any of the boards i'm typically using 3) but that's because i'm not using board config files in a way that actually uses the reset signals.

Question for you - where do you think the best place is for the transport select command? I see a mix of board, target, and interface files all setting it. Right now, i direct people to have separate interface config files, since most of my use cases are bringing up a board before a board file is available...

[tchebb]

Question for you - where do you think the best place is for the transport select command?

I've never been too sure of this myself. Like you say, the upstream files are inconsistent and OpenOCD's documentation doesn't give a clear answer either.

My personal habit is to leave transport and speed settings out of both the interface and the target configs. I either pass them on the command line between including the two files, or I make them part of a small, per-project "glue" file that includes everything needed.

I can see the argument for putting the transport with the target, though, especially for targets that support only a single kind of debug interface. I left it out of my Tigard config since Tigard can do both JTAG and SWD (although I haven't used SWD myself, so maybe that needs other config changes too).

[securelyfitz]

looks like if you don't set it, it auto-selects 'jtag'. That means a generic tigard.cfg can leave it undefined and work in the majority of cases.

If someone is using SWD, they can define it in the board or target file, or use a specific tigard-swd.cfg

I did already adjust both the JTAG and SWD config in the readme in 4ac4998.

Thanks again for digging into this, and thanks for posting the openocd change - it's been on my todo list for.... two years?!

[Seas0]

Current config seems still broken for SWD reset, as the reset pin is not initialized with output mode.
Also adding reset_config trst_push_pull srst_push_pull is necessary for a ftdi adapter without tri-state gate setup.

My configuration for reference:
JTAG

adapter driver ftdi
transport select jtag
ftdi_vid_pid 0x0403 0x6010
ftdi_channel 1
ftdi_layout_init 0x0038 0x003b
ftdi_layout_signal nTRST -data 0x0010
ftdi_layout_signal nSRST -data 0x0020
reset_config trst_and_srst separate srst_nogate trst_push_pull srst_push_pull

SWD

adapter driver ftdi
transport select swd
ftdi_vid_pid 0x0403 0x6010
ftdi_channel 1
ftdi_layout_init 0x0028 0x002b
ftdi_layout_signal SWD_EN -data 0
ftdi_layout_signal nSRST -data 0x0020
reset_config srst_only separate srst_nogate srst_push_pull 

[securelyfitz]

@Seas0 Thanks for pointing this out. What's your test target? I only have 2 boards i use to test and neither use srst which is why
I'm still getting this wrong. Will confirm your config on a scope when i get a chance.

[securelyfitz]

I see the source of my error - i based the swd config file on one from a device that had srst on a different pin. i updated the ftdi_layout_signal but not the ftdi_layout_init when I copied and it worked for me.
I changed it in 5e57229 but reopening this issue until i have a chance to test everything and make sure it doesn't break, including older openocd versions.