Using Your STM32F4 Discovery Board as a Programmer and Debugger

It’s a lot of fun writing code on your Discovery board with its myriad of peripherals to explore and exposed headers for further experimentation. Nothing, however, beats the satisfaction to be had from creating and coding your own board and there comes a time when every red blooded geek must strike out on their own!

I’ve recently been presented with an opportunity to create a new board that required a lot more grunt than the PIC based boards I normally deal with. We needed a much faster processor, an FPU and some DSP capability. As a result I opted to use the STM32F405RG as the MCU. The next thing I wanted to do was to mash up a prototype but I needed a quick and easy way to program it. I remembered that the Discovery board has an ST-LINK section with an SWD interface broken out onto headers so I thought I’d give it a go.

STM32F4 Discovery ST-LINK Jumpers

Setting up your Discovery to use it as a programmer is a very straightforward affair. The ST-LINK section is the top third of the board and can be easily isolated by removing the two CN3 jumpers shown above.

You’re also clearly going to need to expose the SWD interface on your board so you have something to connect the ST-LINK to. The schematic below shows how I did it.


A couple of things to note about the circuit above. I’ve pulled BOOT0 low which means that I’m programming flash memory. If you want to program other areas of memory then you’ll want to be able to change the state of this and the BOOT1 pin which is multiplexed with PB2 on the STM32F40x parts. Details can be found in section 2.4 of the reference manual.

The other thing I did was to expose the additional JTAG interface pins also in order to give me several programming and debugging options. Finally, I connected the NRST pin on the ST-LINK to the NJRST pin on my STM32. That may be wrong, you might be better off connecting it to the NRST pin on the STM32. Perhaps someone out there can let me know in the comments below.

The SWD interface is connected as follows:

ST-LINK to STM32F405 Connections

I chose to expose the interface as a row of 0.1” pitch header and connected the two boards together with female to female patch leads.

The next step is to try and get some code running on the device. I’m using Atollic TrueSTUDIO Lite for this but I’m sure the process is pretty much the same for other IDEs too.

Project Creation Steps

To get up a program up and running on the new board you need to create a new project that targets the STM32F405 or whichever STM32 part you’re using. This will generate a new, compilable and runnable project. If you run the program up now in the debugger you should be able to step through the code, look at variable values and memory content. This shows that everything is working fine.

The final step is to sort out your clocks. TrueSTUDIO will create a default system_stm32f4xx.c file containing a clock configuration for you but unless you happen to be using a 25MHz crystal you’ll want to change it for one targeting your own board. Mine, for example, uses a 4MHz external clock.

STM32 Clock Configuration Tool

STM32 Clock Configuration Tool

The easiest way to do this (as far as I’m aware at least) is to use the clock configuration tool provided by STMicroelectronics for the purpose. You can download the tool and the accompanying notes from their website. I used the simple wizard mode, followed the instructions very carefully and where I wasn’t sure of a value, I looked it up in the original file created by TrueSTUDIO. Once the new system_stm32f4xx.c is generated, it needs to replace the one in your project. Simply re-build the project, make sure you can still launch and debug it and you’re up and running.

So I’ve been running with this setup for a couple of weeks now with very few problems. I did get a bit of a scare when I saw smoke pouring out of the Discovery’s USB port once but I think that was a pretty freak incident as it hasn’t happened since. I’ve had the odd unexplained debugger disconnection but given the amount of myopic prodding I tend to do with scope probes that could be more about what I’m doing than the what the debugger is doing. All in all I think it provides quite a good option to anyone wishing to experiment with creating their own STM32 boards without forking out for new kit.

  1. orphee said:

    Thanks for your work.
    I tried to put a functionning soft (on Discovery board) to a STM32F407 100 pins PCB (homemade) and it doesn’t work. During programming it’s OK (no error message and I can read it back correctly ) but , no any signal can be seen on ports except 8Mhz crystal. ” Pdr” is connected to ground, “NRST” to Vcc (100k). I tried to do it again on a new PCB but it’s the same. Do you have an idear about what to do ?

    Thanks. Sorry for bad english.

    • Hi orphee, thanks for visiting it’s much appreciated.

      It’s difficult to know what is wrong without being able to see a circuit schematic but what I would say is that I had a similar problem at one stage when I wasn’t dealing with NRST properly. 100K sounds very high for a pull up, did you mean to say 10K? Taking it down to 4.7K might be worth a shot too. The other thing that is worth checking is that the BOOT0 pin is pulled low.

      I hope there’s something there that might help. Perhaps another reader might be able to add some more suggestions. Oh and there’s no reason to apologise for your English. It is a LOT better than my French!


      • orphee said:

        Thanks a lot for your answer

        I put my schematic here:

        Boot is 0 Level (S71)
        For NRST 100k I will try but I don’t think it will change result (NRST is necessary for programming)

  2. orphee said:

    Ok, in fact STM32 is working. It’s probably because of a bad ethernet wire connection

    • Hi Orphee,

      Huge apologies for not getting back to you sooner, it’s been a very hectic week! Glad it’s all worked out and thanks again for visiting, it’s much appreciated!


  3. Trojan said:


    There is already one Embedded ST-LINK available in the board. What was the need for extra circuitry? I mean you could have directly flashed the board using USB cable and OpenOCD. Maybe I am missing something here.


    • Hi Trojan, this post is about using the ST-LINK on the Discovery to program and debug a board that doesn’t have one built already built in.

      • Trojan said:

        Thanks for clearing my doubt.

  4. Arnout said:


    Just wanted to share that I also succeeded in doing this, but it is a little less obvious than it seems.
    The reason of course is that only two signals (SWCLK and SWIO) are disconnected by CN3, but TRST is still active. This causes problems.
    My recommendation:

    – You should to disconnect JP1 (To disable VDD to the debugger’s boards CPU). If you don’t do this, the “debuggers-board” CPU is still powered, and can interfere with the TRST line even when its SWD lines are cut: I’ve had cases where it pulled it low while programming another board, causing strange programming errors

    – You can just be really sure, and remove a solder bridge on the back of the board (SB11 on my revision). This is actually the best option (if you don’t plan to use the debugging board anymore as real target), since even with VDD disabled, the unpowered CPU still pulls the TRST line a bit, which can cause problems.

    Anyway, hope this helps anyone.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: