ST 32F4xx debugging and NJTRST mystery - does it do anything?

[peter-h]

Currently, on my target I have these two connectors



(actually on J9, 3,5,7,9 are all GND)

J6 connects to the 20-way big connector on the STLINK V2 / STLINK V3 debuggers. This works. NJTRST isn't connected. I originally did a lot of googling on this and found a vast number of people asking the same question, with no real answers

J9 is the "standard ARM debug" pinout documented by various debugger tool makers e.g. Keil, and is supported by STLINK V3 via its CN1 connector and the 14-way to 10-way cable they provide. This doesn't have NJTRST.

I sort of understand this ST world isn't actually JTAG but an ST-special single wire debugging thingy. So maybe this is why NJTRST is not used. But it takes up PB4 which could otherwise be useful



Currently I have a 10k pullup on PB4, just in case The data sheet is silent on PB4 mode. The ref manual describes how it can be used for stuff according to whether Jtag is configured, and it mentions an internal pullup but doesn't say whether this pullup is always present.

[ataradov]

TRST only resets the TAP controller. It practice it does not do nothing useful, so it is often omitted. SWD is not ST specific, it is ARM standard across all Cortex-Mx cores. All unused programming pins can be used as GPIO.

See Table 299. "Flexible SWJ-DP pin assignment" of the reference manual on all possible combinations of debug pins.

[SiliconWizard]

I've never used this signal myself.

[peter-h]

Thanks All.

I had to google on "TAP controller" - it is something related to boundary scan and thus JTAG.

Learn something every day... this shows how the four pins come up after reset, and it probably makes sense to have external resistors there which are aligned with this config.

[newbrain]

But it takes up PB4 which could otherwise be useful



Currently I have a 10k pullup on PB4, just in case The data sheet is silent on PB4 mode. The ref manual describes how it can be used for stuff according to whether Jtag is configured, and it mentions an internal pullup but doesn't say whether this pullup is always present.

The datasheet specifies PB4 is in NJRST mode after reset, as you show, and the reference manual shows the details: it's in ALT0 mode with pull-up at reset.
This can be seen by checking the the reset values for GPIOx_MODER, GPIOx_PUPDR and GPIOx_AFRL).

You can program it as any other GPIO, if you are not using it, including the pull-up/down mode (SWD is usually the preferred debug interface, even if the chips by default come up in JTAG mode).

[harerod]

...
You can program it as any other GPIO, if you are not using it, including the pull-up/down mode (SWD is usually the preferred debug interface, even if the chips by default come up in JTAG mode).

Interesting statement. I am under the impression that when debugging increasing code/data size and complexity, JTAG behaves faster and more reliably. Never mind on an F0, but an F4 is more fun with a fast and steady debugger.

[ataradov]

For the same clock speed JTAG is slower. It may be a lot slower depending on the way device is accessed.

Reliability depends on the signal integrity and with a good connection (short cables, good ground) you will get the same reliability on both interfaces.

SWD should always be preferred. I was surprised ST even leaves JTAG enabled for anything but boundary scan.

[harerod]

ataradov, thank you for that input. I am pretty confident in my setups. The JLINK's JTAG has been operating reliably at 12MHz for a long time. For the next big debug session I will give SWD a shot. I have a couple of JLINKs, several STLINKs and an STLINKiso in the lab. We'll see.