Skip to content
JohnK1987 edited this page Jul 20, 2024 · 3 revisions

Short overview

Standard STM32 dev kits usually include also on-board ST-Link what provides a Drag & Drop program upload, external clock source (Just for the on-board MCU not for any external MCU), VCP (Virtual COM Port), but also a direct debugger feature. Thanks to the on-board debugger you are able to deploy and debug any external MCU via SWD port. That could be very handy when you want to make something by your self or when you have also a board without an on-board debugger. So when you buy a cheap Nucleo 64 board, then you get a professional dev board with full debugger. There is also a regular ST-Link option and some clones like ST-Link USB dongle, but from my point of view is the Nucleo on-board ST-Link best option.

We will focus on the variant with Nucleo on-board ST-Link and an external MCU, but basics features are same for all variants of ST-Link. However there are also more variants how we can upload our program. For example DFU (Device Firmware Upload).

ST-Link like external probe

ST-Link overview and features

  • Deploy and Debug via SWD (Serial Wire Debug) port
  • Drang & drop upload - this is provided via MSD (Mass storage device) wirth 2MB flash memory
  • SWO communication (Serial Wire Output)
  • VCP (Virtual COM Port) for regular serial communication

Of course ST-Link cooperate with STM software, for example with STM32CubeProgrammer, but because is very popular it is also supported by open-source tools like pyOCD, openOCD and also is possible convert it to J-link thanks to official Segger software. For more look to MbedCE Upload methods

Notes:

  • Keep the firmware of your debugger up to date! In case of ST-Link is the updater included in STM32CubeProgrammer or as standalone app - STSW-LINK007
  • ST-Link requires drivers for itself, but also for VCP - STSW-LINK009

Getting started with NUCLEO on-board ST-LINK/V2-1 and external MCU

Nucleo_ST-Link

Prepare ST-Link for external MCU:

  • remove two jumpers on CN2 header (marked in orange)
  • remove jumper from PWR header (marked in blue)
  • (just optional) on CN3 header (marked in green) we can found UART pins TX/RX what is connected to ST-Link's USB interface which provides a VCP in PC - for more look below
  • connect SWD from CN4 header (marked in purple) to an external MCU
    • pin 1. VDD_TARGET is an ADC pin what measure power source of external MCU. It is not necessary for basin usage, but it is necessary for Drag & Drop method
    • pin 2. SWCLK is clock for communication between ST-Link and MCU. Should be connected to same pin on MCU
    • pin 3. GND is very important and have to be connected to same GND like MCU
    • pin 4. SWDIO is data pin and have to be connected to same pin on MCU
    • pin 5. NRST is pin for resetting MCU and could be connected to same pin on MCU
    • pin 6. SWO is pin for SWO communication and could be connected to same pin on MCU - for more look below

Warning

For some targets is necessary to remove SLEEP via mbed_app.json file. Without this is not possible to perform the debugging session - "device_has_remove": ["SLEEP"]

Choose a variant with which you will deploy your program into target MCU.

Drag & drop

This method is just for upload and for this method is necessary have the pin 1. of SWD(CN4) VDD_TARGET connected to power source (3v3 max) of target MCU!

  1. just put already compiled binary file into the MSD memory and it is done.
  2. second variant is used via an IDE - Upload method MBED

Note

If the pin 1. of SWD(CN4) VDD_TARGET will be not connected to VDD of target MCU, then the USB MSD memory will show low capacity.

Note

When MSD memory show your self with low capacity (few KB), then target MCU is not properly connected or powered.

Note

For Drag & Drop is not necessary to install any driver under MS Windows. Do not be surprised when your binary will disappear from the memory because the file is consumed after deploy.

SWD

The SWD allow you Deploy and Debug any code in any connected MCU. Debugging is the most important feature in a programmer's life, so also this part is very important.

SWD pins, on the MCU side, are marked on MCU/board page or directly in source code mbed-os/targets/TARGET_STM/TARGET_STM32XX/TARGET_STM32XXXX/TARGET_XXXX/PinNames.h. Or eventually in manuals of specific MCU.

For example:

stm32f103c8t6_debug_con

Note

For SWD connection between your target and the Debugger is recommended to use wires approximately 10cm long. With longest wires there is a risk about bad and unstable connection (personal experiences with Blackpill).

Serial debugging with ST-Link

STDIO console

Default STDIO console is working on regular UART and is used for MbedOS crash reports or printf debugging uses macros CONSOLE_TX and CONSOLE_RX. These pins, on the MCU side, are marked on MCU/board page or directly in source code mbed-os/targets/TARGET_STM/TARGET_STM32XX/TARGET_STM32XXXX/TARGET_XXXX/PinNames.h.

For that we also need a Serial Terminal on PC side - Puty, Teraterm, Termite, YAT and so on.

Note

Be careful wires between UARTs must be crossed that means RX->TX and TX->RX.

Note

Default baud rate in MbedCE is 115200

SWO

SWO(Serial Wire Output) via SWO pin on SWD connector could be connected to MCU's SWO pin (look to MCU/board page) for a serial communication over one wire with Serial Wire Viewer. Serial Wire Viewer is part of STM32CubeProgrammer SWV

  1. Run STM32CubeProgrammer (for more just app)
  2. Connect ST-Link via green button in the app
  3. chose SWV on the left panel in the app
  4. set frequency of your MCU to System clock (MHz)
  5. press Start blue button
  6. look to the white listbox

Example with SWO:

#include "mbed.h"
#include "SerialWireOutput.h"

#define DEBUG   1

DigitalOut led1(LED1);

extern "C" void itm_init() { }

FileHandle* mbed::mbed_override_console(int)
{
    static SerialWireOutput swo;
    return &swo;
}

int main()
{
    debug_if(DEBUG, "Hello, SWO!\r\n");
    thread_sleep_for(500);
    debug_if(DEBUG, "CPU SystemCoreClock is %d Hz\r\n", SystemCoreClock);  
    thread_sleep_for(500);
    while (true) {
        led1 = !led1;
        debug_if(DEBUG, "blink\r\n");
        thread_sleep_for(500);
    }
}

Necessary mbed_app.json settings

{
    "target_overrides": {
        "*": {
            "platform.stdio-baud-rate": 115200,
            "platform.stdio-buffered-serial": 1,
            "target.printf_lib": "std",
            "target.device_has_add": ["ITM"]
        }
    }
}

Non-ST-Link solution

DFU over USB

DFU is Device Firmware Upload over on-chip USB interface. So when you are able to connect to the on-chip USB interface via USB cable, then is just bring 3v3 to a BOOT pin (look to MCU/board page or MCU manual) during reset or power up of the MCU.

DFU

  1. Run STM32CubeProgrammer (for more just app)
  2. Via blue button (close to green button) select USB
  3. In USB configuration prest Update button (ikon) and select an USB
  4. Press Connect green button
  5. Chose and click on card Open file and set path to your .bin file
  6. Press blue button Download
  7. Wait until it is done.

Note

here counts with a chip what has on-chip USB interface!

Note

if the USB is not recognized, then try reconnect USB or disconnect peripherals.

Serial debugging without ST-Link

If there is not on-board UART to USB convertor or ST-Link then you could use any USB to TTL convertor for example based on FTDI chip or something similar. But if you don't have a UART to USB adapter handy, and you aren't using the USB port in your code, you can also have the board send console output over its own USB port. Just drop the following target overrides into your mbed-app.json:

{
    "target_overrides": {
        "*": {
            "platform.stdio-baud-rate": 115200,
            "platform.stdio-buffered-serial": 1,
            "target.printf_lib": "std",
            "target.console-uart": false,
            "target.console-usb": true
        }
    }
}

However, DTR signal will be necessary!

Special thanks to Zoltan Hudak for sharing his materials.