Debugging software environments for STM32 development

I’ve reached the point where I want to undertake some more ambitious hacking on the code for various MI modules, and I really need a proper development environment. I have an STM32F4 Discovery board with built-in ST/Link-2, and a suitable set of JTAG/SWD cables and adaptors. What is the best open-source environment (for OS X, preferably) for debugging code running STM32 processors? I’ve found various recipes for using the Eclipse IDE together with OpenOCD and gdb with the ARM gcc compiler, but the set-up looks slightly complex, and I was wondering if there were other options that anyone doing a lot of this sort of development (who might that be?) could recommend.

Hi Tim,
I switched to in-circuit debugging a short while ago too :slight_smile: I just use OpenOCD and gdb directly in command-line (none of the fancy IDEs; my editor is Emacs). Type “layout src” in gdb if you’re lost. Olivier has included a set of make targets to help that, so for instance if you do “make debug_server” it’ll freeze the module, and wait for connections from gdb. The do “make debug_client” and it’ll open gdb, and you can load new code directly in RAM, step through your program, set watch/breakpoints… as if you were directly on your machine. Pretty cool. I now basically never go out of gdb while developing. Also, I don’t know if you use the ST-Link with Olivier’s infrastructure, but I figured out the OpenOCD configuration files for it if you need them (it took me a while).

Do tell me if you need more help, I’m getting more and more familiar with this stuff.

PS: I bought a proper ST-link and a STM32F4 discovery board, but the latter has only SWD pins if I’m correct. What cable/pinout do you use?

Just using the command line is fine, no need for an IDE, just using the provided makefile targets would be enough.

I am using these connections, as worked out by Michael Morin, using a custom miniJTAG cable I made:

Braids <------> STM32F4 Discovery 6-pin connector

1 +3.3V 1. VDD
2 JTMS 4. SWDIO (Single Wire Debug I/O)
3 GND 3. GND
4 JTCK 2. SWCLK
5 GND 3. GND (not necessary)
6 JTDO — (JTAG OUT - not used for SWD)
7 — ---
8 JTDI — (JTAG IN - not used for SWD)
9 GND 3. GND (not necessary)
10 RESET 5. RESET

However, I also have one of these: http://www.adafruit.com/product/2094 and one of these: http://www.adafruit.com/product/1675

Maybe I should just buy a proper STLINK/V2 device and a 20-pin cable to connect it to the Adafruit adaptor board and be done with it? It is certainly very affordable. In which case details of the OpenOCD config would be very useful.

Edit: I just ordered an STLINK/V2, which I think comes with a 20-pin ribbon cable, so I should be good to go by the weekend.

> I figured out the OpenOCD configuration files for it if you need them (it took me a while).

That would be useful, are they on your github? … I tried the other week, but failed.

> What cable/pinout do you use?

As for SWD < > mini JTAG, the cleanest solution probably is to have a little adapter PCB fabbed. There are ready-to-go adapters, too; for example, someone on Muffwiggler linked this: https://github.com/PatternAgents/JTAG20M-STLV2F

> That would be useful, are they on your github? … I tried the other week, but failed.

I forked and updated stmlib a couple of days ago, you might have missed it. Here’s the commit in question:
https://github.com/mqtthiqs/stmlib/commit/bc00be289e0c64395ef3fba65158e9ad34977300

> Maybe I should just buy a proper STLINK/V2 device and a 20-pin cable to connect it to the Adafruit adaptor board and be done with it?

I’m not sure what the difference is between SWD (6-pin) and JTAG (20- or 10-pin). But if you found a pin mapping from one to the other, you should be good to go already, aren’t you? What happens if you set your config files as I did and “make upload_combo_jtag”?

Ah, indeed, I missed that. Thank you. And brilliant, seems to work now; I had “transport select hla_swd”, which didn’t work.

And yeah, he should be good to go, in this context the differences should be entirely negligible. At least that’s my (pretty vague) understanding.

Oh well, the STLINKv2 was only AU$30, free delivery.

> And brilliant, seems to work now

Great. Happy to help!

> Oh well, the STLINKv2 was only AU$30, free delivery.

You lucky, I had to order 80 EUR worth of crap from Mouser to get free delivery. I’m never going to use that Nucleo board or these breadboard jumpers :slight_smile:

OK, my ST-LINK/v2 arrived, and I have connected it to Peaks, and using mqtthiqs’ config settings for it, it works perfectly: I can upload new code, and invoke gdb and halt the processor, examine registers etc. Nice! Now I just need to learn how to use gdb properly…

Edit: Huzzah! I can set breakpoints and print the values of variables! That will make it a lot easier to work out what the hell is going on!

Though I guess that’s clear / just not to confuse people: You don’t have to buy a STLink to do that; discovery board et al (= STLink/V2, as you say). Also, said (modded) config scripts are mostly for convenience, you could have used gdb all along (?)

In retrospect, yes, but for $30, this is a neater solution which doesn’t require custom cables and lets me use the Discovery board for other things (such as collecting dust, most likely). All this embedded stuff is new to me…

> Nice! Now I just need to learn how to use gdb properly…

Here are a few commands I use regularly:

  • layout src: splits the window and show the code in a convenient way
  • load: reloads the code in the memory of the module (doesn’t have to write on Flash)
  • monitor reset: resets the module
  • monitor reset halt: resets and stops execution
  • continue: runs code.
  • next: steps through the code in the same stack frame (skipping function calls).
  • watchpoint: like a breakpoint but for variables or expressions’ values. “watchpoint (x < 42)” will stop the execution whenever the value of (x < 42) changes.
    Also you might already know that you can abbreviate all the commands as much as you like as long as there’s no ambiguity: c is continue, lo is load,…

> Also, said (modded) config scripts are mostly for convenience, you could have used gdb all along (?)

Not really… The real work is done by OpenOCD, which communicates with the MCU; GDB is just a remote control, with an interface that’s already well-known to programmers. The config scripts are commands for OpenOCD to recognize the adapter, the processor, and set up a server for GDB to connect to. Sure you can get rid of them but you’d have to retype the commands they contain on OpenOCD’s command line each time.

> Not really…

Well, if he had used the discovery board before, he must have used openocd, hence he could have used gdb. The rest is convenience, in my book at least.

Yes sorry, I misinterpreted your comment.

No worries. I’m all for convenience … just thought it’d be worth emphasising this should have been perfectly possible with the discovery board.

Gdb may have worked with the Discovery board, I just never tried it. The Discovery board did need a custom cable, though, which as very fiddly to solder.

How did I ever manage without on-chip debugging with gdb via openOCD?