STM32F2 JTAG without NJTRST unusable

[jasonjason9]

Posted on June 30, 2013 at 00:29

We have a STM32F205RCT6 connected via JTAG.

The JTAG emulator uses TDI, TDO, TMS, TCK and SRST (system reset). The NJTRST (JTAG reset) pin is electrically not connected to the JTAG pin header. As long as the software is set up to configure all JTAG pins as ''alternate function'' everything works. As soon as the software configures the pin PB4 (NJTRST) as INPUT or OUTPUT or any other alternate function, JTAG stops working. This happens even though this pin is actually not used at all and electrically not connected at all (should be used as SPI lateron). According to RM0033, p.137, ''Full SWJ (JTAG-DP + SW-DP) but without NJTRST'' should be available when PB4/NJTRST is configured as something else than alternate function 0. This is also what STM32F2xx_StdPeriph_Examples/GPIO/JTAG_Remap/main.c attempts to do. We find that contrary to the documentation, JTAG is rendered completely useless as soon as NJTRST is disabled even though NJTRST is not used by our JTAG adapter. To our impression we are either doing something seriously wrong or this is a silicon bug or wrong documentation. Please comment on our findings. How to reproduce: Firmware sets up IOs and works as expected. If the last line (MODER assignment) is added to the firmware, JTAG stops working upon executing that line. configure_everything(); sleep_for_seconds(10); // 0 -> input, 1 -> output, 2 -> alternate, 3 -> analog // pin 4 -> bit shift by 8 unsigned int mask = 3U << (4*2); unsigned int bits = 0U << (4*2);  // 0U and 1U disable JTAG // This line actually disables JTAG when executed. GPIOB->MODER = (GPIOB->MODER & ~mask) | bits;

[Tesla DeLorean]

Posted on June 30, 2013 at 01:57

I'd expect NRST(SRST) to blow away any configuration of the GPIO.

Is this with some specific make/model of JTAG pod? Which have you tested, which failed? Are you doing boundary scan testing via JTAG? Do you have any pull up/down resistors related to the JTAG pins?

[jasonjason9]

Posted on June 30, 2013 at 02:26

> I'd expect NRST(SRST) to blow away any configuration of the GPIO.

Of course it does... but I don't see how this relates to the described problem in any way...? To repeat: JTAG (J-Link) is connected to all pins including NRST but excluding NJTRST. JTAG works great (program flash, debug, set breakpoints, read registers, etc.) As soon as we program PB4 to be INPUT or OUTPUT, JTAG stops working: Target polling gets no response any more. This holds even though PB4 (NJTRST) is not connected to the JTAG emulator. There are no external pullup/pulldown resistors. The problem is that as soon as the MCU itself re-confgures its port PB4 to be anything else than NJTRST (e.g. general purpose input), exactly at that moment, the JTAG connection between emulator and STM32 stops working properly. Even though NJTRST is not wired to the JTAG emulator but left open with internal pullup enabled. The MCU continues to run and execute as expected. If, at a later point, the MCU configures PB4 back to AF=0, the JTAG poll sees answers again and JTAG resumes working. Hence, PB4 (NJTRST) affects JTAG even though it is not electrically connected at all and even though the docu states that JTAG should remain operational if NJTRST is deactivated or used as GPIO.

[Tesla DeLorean]

Posted on June 30, 2013 at 04:01

Assume I reviewed your original post, I'm fishing for other data points.

The F1 series had a more considered and graduated method of remapping the JTAG/SWD pins. I'm not using PB4/NJTRST in my F2/F4 designs either. You might want to review the

http://www.st.com/st-web-ui/static/active/en/resource/technical/document/errata_sheet/DM00037591.pdf

, this is the F4 one, but the NJTRST issue is probably salient to the F2. Have you tried using the J-Link in SWD mode? Does the version you have support that?

[jj2]

Posted on June 30, 2013 at 05:29

Let this serve as, ''vote #2'' for switching to SWD from JTAG - but w/caveat that you do (at least temporarily) add 2k7-10K pull-ups, on both SWD lines.

It may be that ''harvest'' of NJTRST defeats or weakens those alleged/internal JTAG pull-ups...

[jasonjason9]

Posted on June 30, 2013 at 12:07

Ha, I already wanted to bet a crate of beer that I found a silicon bug which is not documented in the errata.

Thanks for pointing me at the F4 errata. I think it's precisely what I see with the F2. But it is not mentioned in the F2 errata document. ST should probably add it there. Is this going to be fixed at some point? If not, what about removing these false promises from the datasheet? I'll see whether I can get SWD working. (I'm using OpenOCD.)

[Tesla DeLorean]

Posted on June 30, 2013 at 18:32

I had written a longer response to this, but the forum/browser appears to have eaten it.

I don't work for ST, you'll have to push in via your FAE, or other ST contacts. I consider the F2 as in EOD, any and all development work is going into F4 road mapped devices, so I wouldn't expect any ''fix'' to the silicon. The errata is in the most recent geometry shrink of the F4 from 2013Q1. Couple of things going against a fix. The full-on JTAG works, boundary scan works, SWD works, pins work independently of debug, most systems aren't used in debug, and those which are predominantly use SWD.

[jasonjason9]

Posted on June 30, 2013 at 22:26

Regarding the fix, I can understand this. However if it's not fixed, it should then also be removed from the datasheet as a feature. Because I actually looked at the datasheet before designing this.

Anyway, it would be idiotic to explicitly promise features in the datasheet and then void them in the errata. Regarding pushing this to ST, I don't know whom to contact so if you or somebody can point me to that person, I'd be willing to invest some time into it.

[Amel NASRI]

Posted on July 11, 2013 at 13:59

Hello Jason,

Thanks for highlighting the issue. It is received by ST 🙂 So I confirm that there is an issue to use JTAG without NJTRST and it is similar to the one found for F4 and stated in the errata sheet. As it is considered as a limitation, it will be added into the errata sheet. The idea of the errata sheet is to state the limitations that may be fixed on other product revisions. -Mayla-