STM32F103 not responding to JTAG - Page 1
Forum section: electronics / general

author: bson
author_rank: Unknown
timestamp: March 08, 2019, 06:32:24 am
content: I rolled a simple test board with an STM32F103RG but can't seem to get it to respond on the JTAG port. I've verified it has power, ground, and isn't held in reset or TRST. I can scope the TCK and TDI pins and see clock and data, but nothing ever comes out on TDO. BOOT0,1 are both pulled low. My experience previously is mainly with NXP and TI parts, is there anything special about ST's JTAG implementation? I'm using OpenOCD with a Tincan Tools Flyswatter2 (FT2232H based), but I also have an STLINK v3, but haven't tried that yet.Here's my JTAG wiring, pretty much copy and paste from other ARM processors. Both the R9 and R10 jumpers are installed.I've double checked the package pinout... twice.

author: dgtl
author_rank: Regular Contributor
timestamp: March 08, 2019, 02:24:11 pm
content: First of all, try setting the boot pins to internal boot and connect via bootloader to verify that the chip responds in some kind of reasonable way.I'm using SWD (not jtag) with STM32F1 chips and it works well with ST-link v2 and openocd. Their SWD implementation imho required some magic to switch from jtag to swd.

author: Cicero
author_rank: Contributor
timestamp: March 08, 2019, 02:31:13 pm
content: Pinout looks ok to me too, it all looks correct.I doubt its a problem, but on STM32's I generally don't put any external pullups/downs as they have them built in, I also use the 20pin JTAG headers when not using SWD.Worth a try using the STLINK and STM32 Utility as well, make sure to select JTAG in settings though.

author: bson
author_rank: Unknown
timestamp: March 09, 2019, 04:27:14 am
content: Grrr, STLINK v3 doesn't work with OpenOCD on OSX; the kernel attaches it as a mass storage device! ST couldn't possibly have used an application class!So I now have a STLINK v2 on order... hopefully that will work. You wouldn't mind sharing any OpenOCD magic you had to do to get SWD to work? I wouldn't mind going to a smaller connector, maybe a 6 pin Tag-Connect, and using SWD... I mainly stick to the full JTAG because it always works. Well, apparently not.I did look through the guide, and it says external pullups aren'tnecessarybut not that they shouldn't really cause any harm. Especially since JTAG calls for them in their specs. Also the reset default is to enable the full JTAG pin functionality although it's not clear on whether it's possibly entering SWD mode on POR.I see on their eval board they have a jumper for Vbat to select between a battery and Vdd... I tried it with and without a battery installed, but I don't have a jumper to tie it to Vdd.

author: bson
author_rank: Unknown
timestamp: March 09, 2019, 04:40:15 am
content: Ahhhh.... I wonder if this isn't causing my problem!It looks like the STM32F100 nRST is bidirectional, and when it's actively resetting it pulls it low - as an output. It seems to want a 0.1µF cap on there, but no external pullup since it has both a pullup and a 20µs pulse generator internally... I wonder how that will work with the FT2232H tool, I don't want it to drive it high while the µC tries to pull it low during POR. I bet the internal PU is sized for 0.1µF, not 1nF!!!I should depopulate the resistor and swap out the cap!

author: tsman
author_rank: Frequent Contributor
timestamp: March 09, 2019, 04:48:46 am
content: Quote from: bson on March 09, 2019, 04:27:14 amThat shouldn't break it. Your ST-LINK/V3 should appear as USB composite device consisting of a tiny drive, a UART and the actual debug interface itself. The more recent Nucleo boards have a ST-LINK/V2-1 which does this as well. You can completely ignore the USB MSC and the UART if you want.It was the ST-LINK/V1 which had the bizarre USB MSC implementation which wrapped ST-LINK commands inside SCSI packets. Thankfully that is long gone now.

author: bson
author_rank: Unknown
timestamp: March 09, 2019, 06:45:28 am
content: Success!Got it working with STLINK v3 using SWD!The reset fix, PLUS I rebuilt openocd from source - which was a bit of a hassle since it had a bunch of problems generating the docs. So removed all that from the Makefile. I decided to give this a shot since I saw a whole bunch of recent changes to the stlink/hla support.The target voltage reading (setting?) is a little odd, but the board is self-powered anyway.Code:Open On-Chip Debugger 0.10.0+dev-00738-gc3b90c05 (2019-03-08-22:35)Licensed under GNU GPL v2For bug reports, readhttp://openocd.org/doc/doxygen/bugs.htmlsrst_only separate srst_gates_jtag srst_open_drain connect_deassert_srstInfo : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWDadapter speed: 1000 kHzadapter_nsrst_delay: 100srst_only separate srst_nogate srst_open_drain connect_deassert_srstadapter speed: 4000 kHzInfo : Listening on port 6666 for tcl connectionsInfo : Listening on port 4444 for telnet connectionsInfo : clock speed 4000 kHzInfo : STLINK V3J1M1B1S1 (API v3) VID:PID 0483:374FInfo : Target voltage: 0.003200Error: target voltage may be too low for reliable debuggingInfo : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpointsInfo : Listening on port 3333 for gdb connectionsInfo : accepting 'telnet' connection on tcp/4444error: target must be halted for register accessestarget halted due to debug-request, current mode: Handler HardFaultxPSR: 0x01000003 pc: 0xfffffffe msp: 0xffffffdc===== arm v7m registers(0) r0 (/32): 0xF852F3B9(1) r1 (/32): 0x5F7AB2BC(2) r2 (/32): 0xBB639723(3) r3 (/32): 0x37C9955C(4) r4 (/32): 0xBDAD9598(5) r5 (/32): 0xFA9FCF62(6) r6 (/32): 0x46886EEE(7) r7 (/32): 0xCFF5FBE9(8) r8 (/32): 0x71624FF6(9) r9 (/32): 0x795B1DDE(10) r10 (/32): 0x3A7C99E0(11) r11 (/32): 0xDDBD5FEA(12) r12 (/32): 0x32857E97(13) sp (/32): 0xFFFFFFDC(14) lr (/32): 0xFFFFFFF9(15) pc (/32): 0xFFFFFFFE(16) xPSR (/32): 0x01000003(17) msp (/32): 0xFFFFFFDC(18) psp (/32): 0xE805BAD8(19) primask (/1): 0x00(20) basepri (/8): 0x00(21) faultmask (/1): 0x00(22) control (/2): 0x00===== Cortex-M DWT registersHere's the barebones config.Code:source [find interface/stlink.cfg]hla_vid_pid 0x0483 0x374ftransport select hla_swdset WORKAREASIZE 0x8000set CPUTAPID 0x1ba01477reset_config srst_onlysource [find target/stm32f1x.cfg]adapter_khz 4000$_TARGETNAME configure -event gdb-attach {reset halt}

author: donotdespisethesnake
author_rank: Super Contributor
timestamp: March 09, 2019, 07:23:34 am
content: Quote from: bson on March 09, 2019, 04:27:14 amNot just possible, the STM32F103 quite definitely defaults to SWD mode at POR. The datasheet is not 100% clear, but it is stated clearly in the reference manual.There is a special sequence to tell a Debug Port to switch from SWD to JTAG mode, I guess OpenOCD supports that.

author: bson
author_rank: Unknown
timestamp: March 09, 2019, 08:41:28 am
content: Good info, and exactly why I make my own test boards...New interface for the next rev, should be directly compatible with STLINK v3 without the extra board, from CN1 using their supplied 10 pin 50mil cable. And I get two extra GPIO pins in the bargain.

author: dgtl
author_rank: Regular Contributor
timestamp: March 09, 2019, 12:06:06 pm
content: Unless you are planning to use some advanced features (tracing etc), you can drop the SWO as well. Only SWDIO, SWCLK are needed for basic stuff, ie loading code, debugging, breakpoints, semihosting etc.

author: janoc
author_rank: Super Contributor
timestamp: March 09, 2019, 12:10:02 pm
content: Quote from: donotdespisethesnake on March 09, 2019, 07:23:34 amYes, indeed. The sequence is documented in the datasheet, I believe it is this same documented by ARM (the ARM debug port is standardized):http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka11775.html

author: bson
author_rank: Unknown
timestamp: March 09, 2019, 10:08:26 pm
content: Yeah, I know of the TMS sequence to switch modes... just don't want to get into that end of things. Less hackery is better.I do plan to use SWO to capture trace messages (SWV mode). It's one of the reasons I really wanted to get SWD working with the STLINK v3. I haven't looked closer to see how much of SWV OpenOCD supports, but it at least removes the need for a dedicated uart port even if all the STLINK does is route them to a header or VPC. (I know the 14 and 20 pin ST connectors also have rx/tx on them for VPC, but again 10 pins is nice, potentially doable with a 6 pin Tag-Connect since 4 pins are shield or NC.)

author: janoc
author_rank: Super Contributor
timestamp: March 09, 2019, 11:02:59 pm
content: Quote from: bson on March 09, 2019, 10:08:26 pmThen why to start with JTAG (instead of SWD) to begin with? I think ST doesn't even include JTAG headers on any of their dev boards - everything is just SWD.Quote from: bson on March 09, 2019, 10:08:26 pmApparently OpenOCD supports it:https://stackoverflow.com/questions/50075076/show-cortex-m4-swo-log-with-openocdMay have to try it someday, haven't played with it myself yet.

author: bson
author_rank: Unknown
timestamp: March 10, 2019, 01:27:56 am
content: Quote from: janoc on March 09, 2019, 11:02:59 pmI'm not using their boards.

author: janoc
author_rank: Super Contributor
timestamp: March 10, 2019, 10:52:15 am
content: Quote from: bson on March 10, 2019, 01:27:56 amYes, I know, I was just wondering where did you get the idea of using JTAG from, when even ST doesn't use it (even though the chips support it, of course).

author: bson
author_rank: Unknown
timestamp: March 11, 2019, 12:31:01 am
content: Quote from: janoc on March 10, 2019, 10:52:15 amI wanted to start with something I'm familiar with, have working on other processors, and have configs and tools set up for. Then I can adopt processor-specific details (like omitting external resistors, or cater to a strong SWD preference) from there; if those things fail I can always back up and return to something well understood that I know works while trying to figure out what's broken or wait for updated boards to arrive. The more novelties that are added per increment, the more difficult debugging becomes (possible root causes increase exponentially since they can be due to combinations of changes), and the longer it takes to reach the end state (which is a fully optimized production grade implementation).Shoveling every possible feature into the bringup stage is a recipe for massive frustration and headaches...

author: Gibson486
author_rank: Frequent Contributor
timestamp: March 11, 2019, 01:33:49 pm
content: I have been hassled by this a few times.... Everyone is moving to SWD now, so I guess it is par for the course.

author: janoc
author_rank: Super Contributor
timestamp: March 11, 2019, 09:04:38 pm
content: Quote from: Gibson486 on March 11, 2019, 01:33:49 pmJTAG still works fine but you need more pins which is a problem on smaller chips - that's why e.g. Cortex M0 supports only SWD and not JTAG. And, of course, if you want to do boundary scan (good for board testing!), then SWD is useless, you need JTAG.Quote from: bson on March 11, 2019, 12:31:01 amThat's a sane approach. However, what I use when starting with a chip I am not yet familiar with, is to try to copy the known-working design from one of the devboards/reference designs. ST provides all the documentation including schematic for all their devboards and it is a large time saver - at least I will be sure the board will work unless I grossly goof something up.

author: bson
author_rank: Unknown
timestamp: March 12, 2019, 04:46:07 am
content: Quote from: janoc on March 11, 2019, 09:04:38 pmYeah, copying reference designs is extremely common and of course a viable approach, but since I have the luxury of time I can afford to learn from failures. Often knowing what doesn't work, and why, is just as important as knowing what does...

author: bson
author_rank: Unknown
timestamp: March 13, 2019, 09:30:06 pm
content: So I ended up creating a small adapter to go from ARM Cortex-M 10P SWD to Tag-Connect TC2030 RJ12...(That's not the Samtec shrouded header actually used, and I was too lazy to download the Amphenol 3D model.)