The STM32F4Discovery evaluation board is allegedly build to
program remote targets. It features a header that that has a debug-out Serial
Wire Debug (SWD) configuration. The documentation and examples that exemplify
this technique are sparse. The header features the following signals (see
UM1472 for further info):
- Pin1 Voltage from target application (do not use),
- Pin2 SWD Clock: Connect to SWCLK of the target (PA14 on STM32s),
- Pin3 GND: Connect to GND of the target (needed to share the signal ground),
- Pin4 SWD I/O: Connect to SWDIO of the target (PA13 on STM32s),
- Pin5 NRST: Connect to the target reset pin (RST on STM32s),
- Pin6 SWO: SWD trace data line (optional and therefore not subject to this post).
If it would be that easy to just connect the signals then
this tutorial could stop here. Unfortunately, to get things setup the
board has to be modified further. The SWD data lines are obviously used by
the STM32F407 that sits on the board. It is easy to
have exclusive access to these lines as follows:
·
Remove the jumpers on CN3.
That way thedebugger portion of the discovery board will
only share the SWD signals with the SWD connector.
Furthermore, the debugger shares the reset line of the
target with the on-board chip as well. If this line is not cut, the internal
circuit of the on-board chip will prevent the signal to be properly used for
remote applications. Instead of adding a jumper that would make it easy for
people to fix this, the STM guys decided to add a solder bride.
·
Replace the solder bridge SB11 with a jumper as shown in the following.
In order to be safe and avoid adverse affects, one can remove the power to the on-board chip. The STM people added a jumper that can be
replaced with an ampere-meter to measure the power consumption of the chip.
·
Remove JP1/PPI to cut the power to the on-board
chip.
In order to be sure that I can program other chips of the
STM32-family, I used a STM32VLDiscovery board as my guinea pig. As seen in the
picture, I shared the signal ground (GND) and provided 3V to the 3.3V pin of
the target board from the STM32F4Discovery. The reset line and SWD signals were
connected as described above.
All people who have no real operating system (i.e., M$
Windows), can download and use the STLink utility from STM. It provides crude access to the chip that is connected to the SWD port.
·
Select “Target” -> “Connect…”
Watch the status line and confirm that the connected chip matches the outcome you expect. In my case I use the debugger to connect to a STM32VLDiscovery that has a STM32F100 chip.
Watch the status line and confirm that the connected chip matches the outcome you expect. In my case I use the debugger to connect to a STM32VLDiscovery that has a STM32F100 chip.
·
Select “Target” -> “Program”
This allows you to upload an ELF or HEX file to the target board. The programming process should not take longer than a few milliseconds.
This allows you to upload an ELF or HEX file to the target board. The programming process should not take longer than a few milliseconds.
For all the advanced people there is OpenOCD for Linux. I am
using a development version (v0.7.x) from their git repository. When you build
OpenOCD from source (not covered in this article) make sure you enable the
STLink support. Shown below is my example file to flash the ELF file into the
STM32VLDiscovery.
OpenOCD can be invoked by just calling “openocd” in the
directory where the ELF- and the configuration files reside.
## openocd.cfg file for STLINK/v2 to program # an STM32F1xx chip. # # @author Thomas Reidemeister # Use STLink/V2 protocol source [find interface/stlink-v2.cfg] # Use STM32F1x source [find target/stm32f1x_stlink.cfg] # Connect to target init # Reset target into halt # Hint: _reset_ clears breakpoint buffer and puts the # system in defined state. # The target must be _halted_ to write to flash. reset halt # Write the image to the target flash write_image erase main.elf # uncomment the line if you want to have things verified #verify_image main.elf # execute the target reset run # close down OpenOCD shutdown
In conclusion, I have shown how to use the debugger portion of the STM32F4Discovery in a debug-out configuration to debug an external target. To make it hard, I picked a different chip from their value line series.
Although I am not a big fan of Windows, the STLink software
seems to be a great way to upgrade the firmware of the debugger itself. The reader should note that the STM engineers already use
internal pull-ups for the debug circuit of the STM. As a result it is possible
to just connect the power supply, ground pins, PA13, and PA14 on a remote
target on most STM32 processors. Be sure to check out the “Getting started with
XXX hardware development” application notes of your STM32 target to confirm
this.
(And a couple more toys to play with :D)
hello, İ beginner of stm32f407VG MCU. And I'm connecting stm32f407VG + nrf51822(bluetooth). I want to programming nrf51822 using stm32f407VG SWD pin? How I programming (I'm using keil debugging)
ReplyDeleteYou need a debugger like the ST-Link that is baked into the discovery boards. SWD cannot be daisy-chained, I fear wiring up the SWD pin to the NRF is not going to fix it.
ReplyDeleteI'd use the ST-Link of the discovery, connect the SWD of the 3 pin header and then use OpenOCD to program it. I'm not a big fan of Keil, so I do not know if they have an OpenOCD backend.