Debug print hungs the MCU

I am working with an STM32L4S7ZIT6 MCU. The MCU is on a NUCLEO-L4A6ZG board. I have to prepare a bootloader for this MCU. So I started doing some very primitive tests starting from the blinky example. Here is my main.cpp:

#include <mbed.h>
#include "serial_wire.hpp"
#include "PinNames.h"
// Blinking rate in milliseconds
#define BLINKING_RATE     500ms

DigitalOut led(LED1);
DigitalOut led(LED2);

Thread blink_thread(osPriorityNormal, OS_STACK_SIZE, nullptr, "blinky-klinky");

FileHandle *mbed::mbed_override_console(int) {
    static SWO_Channel debugport("swo_channel");
    return &debugport;

void blinky(void) {
    debug("blinky starts...\n");
    while(true) {
        debug("run blinky run\n");

int main() {
    debug("fw starts here\n");
    // ThisThread::sleep_for(1ms); <- Here is the problem
    debug("switching to the application at: 0x%x\n", POST_APPLICATION_ADDR);
    debug("app starts here\n");
    while (true) {
        debug("#GRN#infinite loop\r\n");

It is very clear, simple and straight forward. My only purpose was being sure that I am jumping from the btl. to the app. However, I discovered that the MCU is hanging once it starts the thread when I comment out the 1ms delay. I must uncomment the delay to get it work. Or I have to remove the debug() functions either in the thread or at the beginning of main(). What I do not understand is this does not happen when I run the same code on an F407VGT MCU. Why I observe this issue? It is very annoying because I observe the same behaviour also in the release fw. Here someone had the same issue when he calls printf() in an ISR. One of the answers says: printf() is not normally reentrant. I believe I am having the same problem with him but I still do not have an answer why the same code runs on an F407VGT without any issue? Does anybody have an idea?

Quick notes: F407 works @ 168 mhz while L4S7 @ 120. At the very beginning I was building the code without bootloader functionality (without any shifting in the text section). But it was always the same from the beginning



Is it also well managed in your linker script?

This is actually a bit confusing for me. I am not sure whether I have to define it somewhere explicitly. I thought this is done automatically during code compilation. Here is my custom_targets.json:

        "inherits": [
        "supported_form_factors": [
        "device_name": "STM32L4S7ZITx",
        "device_has_add": [
        "bootloader_supported": true

        "inherits": ["NUCLEO_L4PICO_MOD"]

        "inherits": ["NUCLEO_L4PICO_MOD"],
        "macros_add": ["BOOTLOADER"]   

I see all the debug messages in the correct order when I run the code and also LED1 stops flashing at correct time. I also read that the POST_APPLICATION_ADDR is correct regarding to these two "target.restrict_size": "0x40000", "target.app_offset": "0x40000" which I set for NUCLEO_L4PICO_BTL and NUCLEO_L4PICO_APP in my mbed_app.json.

At the very beginning I compiled the code for L4PICO_MOD and I discovered this problem with the thread. Then when got I sure that it is not blocking anything, I proceeded with the further tests about jumping to the application. Now everything works as desired.