Hi
I have a Maple-mini (and a RET6) and I'd like to experiment with gdb and JTAG. I have all the hardware needed and just sat down to hook it up.
But, I've just spent quite a while searching the data sheets (technical and reference) and then general Googling for any clue of what pins to use for JTAG connection. I can find NOTHING -- anywhere. Am I going mad? Where should I be looking?
Many thanks! :-D
Oh yeah ... before someone tells me to, "RTFM" and provides a link to the Leaflabs JTAG pages ... please note that the Maple-mini does NOT have the little 8-pin header pads for this purpose AND that the master pin map in the documentation makes no mention of JTAG AND neither do any of the pin-out tables in either the technical or reference data sheets, from ST.
I find this utterly bizarre. I must be missing something.
Cheers.
gbulmer
Moderator
gruvin - The pin outs are described in the ST documentation, but it is tortuous and contains errors.
Start with RM0008, then the STM32F103xB datasheet, then the Maple pin-out documentation.
I used: "The Definitive Guide to the ARM Cortex-M3" Author: Joseph Yiu
http://www.arm.com/support/resources/arm-books/the-definitive-guide-to-the-arm-cortex-m3.php
to understand how the debugger subsystems are related.
AFAIK, the STM32F103xB datasheet does not explicitly list the debugger pins and purpose; you'd need to know the names of the pin functions already. Their is a hint in Figure 1 which lists all of the MCU functional blocks and their pins, but that isn't enough. Hence start at RM0008.
RM0008 is expicit. See section 31 "Debug support (DBG)" of RM0008; it describes the Debugger ports and pinouts:
http://www.st.com/st-web-ui/static/active/en/resource/technical/document/reference_manual/CD00171190.pdf
This is made more complex to understand because their are two separate debugger interfaces on the STM32F103; JTAG-DP (five signals) and Serial Wire (two signals), which share some pins.
Edit: (corrected references to ARM 10 pin to become generic 20-pin JTAG)
JTAG-DP is normally brought out to a 10-pin header for ARM. Many traditional JTAG debuggers talk to the 10pin ARM header or a 20pin generic JTAG header. STM32's ARM JTAG-DP is 5 JTAG pins: JTMS, JTCK, JTDO, JTDI and nJRESET, which is variously called NJTRST and JNTRST, making it harder to locate the information.
The 8pin header on the Maple is specific to LeafLabs, so you'd need to make an 8-pin to 10-pin ARM adapter, or 8-pin to 20-pin generic JTAG adapter. IIRC there is a thread on this forum where that is discussed, and a forum member has designed and shared a PCB to connected LeafLabs 8pin JTAG to 20pin generic JTAG (not 10-pin ARM).
The other debugger interface is SWJ-DP (Serial Wire/JTAG Debug Port) or just SWD. This is a "two wire" port interface which uses a clock (SWCLK) and a bi-directional data pin (SWDIO). AFAIK, the specifics of the SWD interface is proprietary to ARM, thought other CPU's do have "two wire" interfaces. The two pins shared by JTAG-DP and SWD are called JTMS/SWDIO and JTCK/SWCLK. (JTDO/TRACESWO is a third, but my debugger doesn't use it)
SWD is surfaced as a 6pin header on ST's Discovery and Nucleo boards. ST's Discover and Nucleo boards provide the cheapest hardware debugger for STM32; some of those boards are under $10, which IMHO is outstanding value for money. Those on-board debuggers only implement SWD, and use ST Micro's ST-LINK/V2 protocol over their USB debugger ports.
See section 31 of RM0008 describes the ports and pinouts:
http://www.st.com/st-web-ui/static/active/en/resource/technical/document/reference_manual/CD00171190.pdf
Table 216 in section 31.4.1 lists the mapping for the two debug ports to their two sets of pins.
Here it is, converted to be "mini-friendly':
JTAG-DP to Maple-mini:
STM32 Mini Pin-name Description
PA13: D22 JTMS JTAG Test Mode Selection
PA14: D21 JTCK JTAG Test Clock
PA15: D20 JTDI JTAG Test Data Input
PB3: D19 JTDO JTAG Test Data Output
PB4: D18 NJTRST JTAG Test nReset
SWJ-DP:
STM32 Mini Pin-name Description
PA13 D22 SWDIO Serial Wire Data Input/Output
PA14 D21 SWCLK Serial Wire Clock
optionally:
PB3: TRACESWO TRACESWO if async trace is enabled,
not connected on Discover/NucleoIt should be straightforward to do the same mapping to Maple.
(Full disclosure: I am not a member of LeafLabs staff)
Thank you, so much. I am ashamed to have somehow missed section 31.4.1 altogether. Guess I was having a worse day than I thought, at the time. LOL
Right. So, I happen to have purchased an Olimex USB debug tool (ARM-USB-OCD) as mentioned on the Leaflabs JTAG wiki pages. I have also made the 20 (not 10?) to 8 pin adapter board, also mentioned there. It all seemed rather easy going, up until I failed to RTFM properly. Oh, the irony! :-P
Now, armed with your information and a good dose of WTF flowing in my blood, I should be able to get things working. Great!
Oh and, I have read a note about how the Maple-mini disables JTAG debugging by default and the function call that re-enables it. Whew!
Thanks again.
gbulmer
Moderator
gruvin - Please don't worry about missing pieces of manual or making mistakes. Much better to fix things and make progress!!
Okay 20pin to 8pin, sorry about that (I have tried to fix it in my post above). IIRC, 20pin matched more JTAG debuggers. The 10pin is more of an ARM connector (mentioned in an Appendix in that book). The modern ARM 10 pin connector is 0.5" pitch, so it isn't much bigger than an ordinary 3pin header.
Thanks for posting about JTAG being disabled. Having that mentioned on this thread will probably help others a lot.
One of the advantages of 2-signal SWD is it leaves more pins available for the application. IIRC, the mechanism to disable JTAG pins can disable some JTAG pins, but leave SWD pins available. That might be a helpful compromise, as SWD would always be available for debugging, but you only lose two pins.
Also, IIRC, SWD might be comparable in speed, or faster, than 5-signal JTAG on many debuggers, like the Olimex, which I think is software bit banging with an FTDI USB chip.
All noted. Thanks.
Meanwhile. I've been tearing my hair out, trying to understand this incredibly complex openocd program.
This started with noting that the folder ~/libmaple/support/openocd/, as reference int he Leaflabs JTAG wiki page under the "Reflashing the bootloader" section, does not exist in the current libmaple git repository. So I have no beaten path to following, in the form of that run.cfg file.
I have been trying to piece together my own openocd.cfg file. But the going is tough -- especially when the documentation on the OpenOCD website refers to older than current versions of the program, where the ft2232 driver is present, when in fact it is no longer and has been replaced by ftdi. :-/ Having hopefully got around that, I'm now faced with errors like ...
$ openocd -f openocd.cfg Open On-Chip Debugger 0.8.0-rc1 (2014-04-08-15:31) Licensed under GNU GPL v2 For bug reports, read http://openocd.sourceforge.net/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' adapter speed: 1000 kHz adapter_nsrst_delay: 100 jtag_ntrst_delay: 100 cortex_m reset_config sysresetreq none separate Runtime Error: embedded:startup.tcl:20: Command/target: stm32f1x.cpu Exists in procedure 'script' at file "embedded:startup.tcl", line 58 in procedure 'target' called at file "openocd.cfg", line 108 in procedure 'ocd_bouncer' at file "embedded:startup.tcl", line 20
This is way, way harder than I ever could have imagined, having come from working with other MCU's and never had anything like this kind of complexity, just for basic old JTAG. I'm lost.
Incidentally, I'm using a Mac. OX 10.9.2 (Mavericks, all current.)
EDIT I had to switch to Linux (Ubuntu 12.04) because openocd has this problem ...
While libusb seems to be all-powerful in Linux, you cannot use it to connect to a USB CDC interface on Mac OS X because that interface is already claimed by the AppleUSBCDCACM driver.
The current version of openocd built and installed from source, seemingly without a hitch. The version I am using can be seen above.
Leaving me to get openocd itself working and connecting to my Olimex ARM-USB-OCD(not-H), I sure would appreciate a link to a concise and current set of instructions for this. Right now, I'd be happy just to be able to re-flash a bootloader. I can move on to debugging with gdb, once that at least works.
So, the following is how far I got, before giving up in disgust and going to bed. :-P
This is running under Ubuntu Linux 12.04 Desktop (64-bit).
I have my Maple-mini in permanent boot-loader mode.
$ openocd Open On-Chip Debugger 0.5.0 (2011-12-03-10:15) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' 1000 kHz adapter_nsrst_delay: 100 jtag_ntrst_delay: 100 cortex_m3 reset_config sysresetreq none separate Runtime Error: openocd.cfg:116: can't read "using_jtag": no such variable in procedure 'script' at file "embedded:startup.tcl", line 58 at file "openocd.cfg", line 116 Info : clock speed 1000 kHz Error: JTAG scan chain interrogation failed: all zeroes Error: Check JTAG interface, timings, target power, etc. Error: Trying to use configured scan chain anyway... Error: stm32.cpu: IR capture error; saw 0x00 not 0x01 Warn : Bypassing JTAG setup events due to errors Warn : Invalid ACK 0 in JTAG-DP transaction Polling target failed, GDB will be halted. Polling again in 100ms Polling target failed, GDB will be halted. Polling again in 300ms Polling target failed, GDB will be halted. Polling again in 700ms Polling target failed, GDB will be halted. Polling again in 1500ms Polling target failed, GDB will be halted. Polling again in 3100ms ^C
The errors, including, "all zeroes" would indicate to me that either a) my physical interface and/or wiring I have is faulty or b) the Maple-mini in permanent boot-loader mode does not support JTAG on pins D18-D22.
I'm using a 20-pin to 8-pin adapter, which I made myself, on a proper PCB etc. I've checked it more times than I cared to count. That is connected between the Olimex ARM-USB-OCD(not-H) and the Maple-mini, as follows ...
JTAG 8-pin Maple-mini Pin 1 (TRST) -> D18 (NJRST) Pin 2 (GND) -> GND Pin 3 (TCK) -> D21 (JTCK) Pin 4 (TDO) -> D19 (JTDO) Pin 5 (TDI) -> D20 (JTDI) Pin 6 (TMS) -> D22 (JTMS) Pin 7 (VCC) -> n.c. (‘mini has its own power) Pin 8 (TRST) -> linked to pin 1 (D18)
There are so many variables at play here. It's hard to know where to go next.
Cheers.
Got out of bed a little later to try an idea I had. But now, the Olimex ARM-USB-OCD isn't even initialising properly. Even with nothing connected to it but the USB cable, I just get a dim red light. I guess it's cooked or something. I cannot find anything on the Olimex website about self tests or trouble-shooting the device itself. Pretty lame. *sigh*
I think it's time I gave up on all this "hackery" and researched official programmers, from ST or Atmel. It's just not worth this hassle. I should have just done that from the beginning.
I do have a JTAG "USB Blaster", which I use with my Altera FPGA boards. Can that be used, I wonder?
gbulmer
Moderator
The low-cost ST debugger is an ST-LINK/V2 (avoid things called ST-LINK or ST-LINK/V1, IIRC they used a different USB transport):
http://www.st.com/web/catalog/tools/FM146/CL1984/SC720/SS1450/PF251168
It is less than 25 USD / 20 GBP, and is available from most distributers, e.g.
http://uk.farnell.com/stmicroelectronics/st-link-v2/icd-programmer-for-stm8-stm32/dp/1892523
http://www.digikey.com/product-detail/en/ST-LINK%2FV2/497-10484-ND/2214535
The SWD-only part of the ST-LINK/V2 debugger is built into most ST's ST32M32F Discovery development boards, and all ST Nucleo development boards. These are available at most distributers. Their are many different models with different MCU's. Prices start at under 9 USD/ 7 GBP. This is one example, but there are more than ten different boards under 20 USD /12 GBP:
http://uk.farnell.com/stmicroelectronics/stm32f0discovery/eval-kit-stm32f0-with-st-link-v2/dp/2096251
http://www.digikey.com/product-search/en/programmers-development-systems/evaluation-boards-embedded-mcu-dsp/2621773?k=STM32F0Discovery
Beware, older Discovery board models had the ST-LINK/V1. The ST datasheet says which it has, so if the datasheet says ST-LINK, and not ST-LINK/V2, avoid it.
These need a way to bridge between the debug software and the debug hardware. IIRC OpenOCD has such a bridge.There is also a gdb to ST-LINK/V2 specific bridge at:
https://github.com/texane/stlink
This has a few programs. One is a stand-alone program which can upload into the MCU. Another is a gdb-to-ST-LINK/V2 server.
Unfortunately, The ST-LINK/V2 protocol is proprietary. Some commercial development companies have signed an NDA with ST to see the documentation. AFAIK the developers of texane/stlink, like several other Open Source ST-LINK compatible gdb servers, have not seen ST's documentation.
AFAIK LeafLabs did use an Olimex JTAG debugger. However, more recently LeafLabs have recommended the Open Source Black Magic Probe, which looks like the best solution, because it is so straightforward to use:
http://www.blacksphere.co.nz/main/blackmagic
This implements gdb's protocol over USB serial. Hence, if you are using gdb, there is no other software to bridge between gdb and the STM32 MCU; gdb talks 'directly' to the Black Magic Probe. I keep meaning to either make or buy one. It should save a lot of futzing around installing and setting up software.
There is a lot of knowledge encoded in a bridge (gdb server) between gdb and the STM32F MCU's debug interface. I would be surprised if OpenOCD or another gdb server could drive a "USB Blaster" designed for an Altera FPGA. But I have been surprised before :-)
Thanks again. Lots to look into there. Seems like I'll now have to buy a Black Magic Probe, in hopes that it works more reliably.
I bought the Olimex ARM-USB-OCD purely because the Leaflabs JTAG wiki (JTAG Debugger section) recommended it -- first and foremost. In practice though, let's just say that my opinion of the product is now very low. It has all kinds of silly issues around initialising when plugged in and even staying connected to the USB bus -- especially in a virtual machine Ubuntu environment, such as I am forced to use on my Mac, which itself is very disappointing.
Software wise, everyone (including Leaflabs) seem to think that OpenOCD is the way to go. From what I've been able to glean from further research, OpenOCD does provide a gdb bridge for the STM32 series chips. In fact, this seems to be among their primary points of focus at present -- see the video linked on their home page just now.
So, I've now read up on a fair bit of OpenOCD's documentation and am gaining an appreciation for why it is, "incredibly complex". It attempts to be many things! The more I learn of course, the less complex it really is. If only the hardware was playing ball.
Historically (personally) programming an MCU has always been as simple as wiring up a cheap (often home made) programmer to the right pins, launching some program, selecting the device in question, loading the bin/hex file and clicking, "Program". It is certainly this way for Microchip PIC and Atmel chips I have been familiar with and I've been doing it effortlessly for many years. In-circuit debugging is a breeze too, but a proprietary affair, often only supported under Windows.
In any case, OpenOCD and these "programmers" we are discussing are more than that. They are for in-circuit debugging and even JTAG boundary scanning, which is something I looking forward to finally being able to do, since it will help greatly for testing of boards in the small production runs I tend to do.
STM32 chips are clearly much less obvious in terms of how to connect them up get code into them, let alone in-circuit debug and ST doesn't seem to prioritise making it easy for anyone. I suppose they rely on universities or class-room training or the like. Altera takes that approach, too. So us learn from home hobbyists have to rely on kind folks in the online communities who have walked that path.
Thanks again.
Oh dear. I don't see any support in OpenOCD for the Black Magic Probe.
Oh but, "... if you are using gdb, there is no other software to bridge between gdb and the STM32 MCU; gdb talks 'directly' to the Black Magic Probe."
OK. Need to do more reading, for this and to learn how the BMP implements good old fashioned Flash programming, for which GDB, AKAIK, is of no use.
Then of course, I am going to run in to issues with the existing recommended Libmaple make jtag and make debug directives. Yet more hacking to be done, no doubt. Goodness me. This is really turning out to be so much more than I bargained for. Still, what doesn't blow your mind, makes you smarter! :-P
Ob boy. So I've read everything I can find on the Black Magic probe and I cannot see for sure if it supports gdb's "remote put" command to upload (Flash) my code -- or indeed any examples, showing parameters that would surely be required to select what location the upload goes to (Flash, RAM, what address, etc.)
So again, I find myself completely lost. :'(
Should I abandon all hope in open source, poorly documented software and devices and just buy an ST programmer and use their proprietary software? (If there is any. Haven't been able to find that yet, either. :'( ) Atmel and Microchip make this SO EASY. WTF is up with ST? I'm really frustrated.
Some success, at last! (Evidently. I didn't abandon all hope. ;-) )
I threw out the 20-pin to 8-pin adapter board and connected directly to the 20-pin JTAG header on the Olimex ARM-USB-OCD. Still no go, until I read the documentation to reveal that pin 1 is an input voltage reference. Once I connected that to Vcc on the Maple-mini, hey presto! OpenOCD now communicates successfully with my STM32F103, when my Maple-mini is locked in bootloader mode. Yay \o/
From here, programming and JTAG in-ciruit debugging should proceed much more smoothly.
Incidentally, it turns out that there's no need, far as I can tell so far, to write a custom openocd.cfg file. With openocd v0.8-RC1 compiled and installed, all I needed was this ...
openocd -f interface/ftdi/olimex-arm-usb-ocd.cfg -f target/stm32f1x.cfg
- - -
The problems I was having with the Olimex programmer coming and going and being generally unreliable appear to have also been caused by the JTAGE adapter board, somehow loading down the power supply or something.
I checked the design once more against the adapter board design mentioned in the Leaflabs wiki (JTAG Adapter section) and published here. My board is definitely correct, in every detail. But this board does NOT work, at all. So not sure what's up with that.
OK. So now I have been able to, apparently, flash the bootloader on a Maple-mini clone I made.
`
$ telnet localhost 4444
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger
> reset
JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
JTAG tap: stm32f1x.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)
> halt
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x21000000 pc: 0x08000a48 msp: 0x20004fd0
> flash probe 0
device id = 0x20036410
flash size = 128kbytes
flash 'stm32f1x' found at 0x08000000
> stm32f1x mass_erase 0
stm32x mass erase complete
> flash write_bank 0 .../maple-bootloader/build/maple_boot.bin 0
wrote 12180 bytes from file /home/bryan/vista/libmaple/maple-bootloader/build/maple_boot.bin to flash bank 0 at offset 0x00000000 in 0.417124s (28.516 KiB/s)
> reset
`
But it's not executing. After a power cycle, the chip just sits there, seemingly doing nothing.
If I use JTAG to again to halt whatever it's doing, it always seems to break at the same address: 0xfff7fffe. This suggests to me that some error condition is being trapped and my bootloader code is simply not executing.
I am guessing (and soon to scour over data sheets again) that some kind of additional configuration is required to put the SMT32F103 into the right mode or whatever. Trying to find out about this is proving hard going. Seems still that STM32 chips are for men, not boys. :-P
OK. I got there in the end. Yay \o/
Turns out that I was using the Maple (RET6?) bootloader source code, which is all the instructions mention where I was reading and differs from that needed by the Maple-mini hardware. When I fixed that, suddenly everything worked. Go figure!
So, to summarise my set-up to get things working ...
openocd, there is no need for some custom .cfg file (as all those howtos etc say there is). Simply run ...
openocd -f interface/ftdi/olimex-arm-usb-ocd.cfg -f target/stm32f1x.cfg
`
$ telnet localhost 4444
...
At the prompt, type one by one, ...
reset
halt
flash probe 0
stm32f1x mass_erase 0
flash write_bank 0 <full-path-to>/build/maple__mini_boot.bin 0
reset
`
I think that's about it.
Oh. One more thing. Don't be a numbnutz like me and expect your system's default gdb to be able to debug your ARM chip. You need to be running the version of gdb that comes with with your cross toolchain. In my case, that was arm-none-eabi-gdb.
You must log in to post.