STM32F407VG: bare minimum mbed_die()s

christandlg · August 12, 2020, 12:09pm

I want to develop for STM32F407VG using mbed. I created a project for the ST STMF4DISCOVERY board, which uses the same uC than the boards I will be using (Clicker 2 for STM32) I can build and upload without issues, but unfortunately, even a “bare minimum sketch” has mbed end up in mbed_die().

the code:

#include <mbed.h>

int main() {
    while(1) {
    }
}

platformio.ini:

[env:disco_f407vg]
platform = ststm32
board = disco_f407vg
framework = mbed
upload_protocol = stlink

the debug console does not tell a lot:

Temporary breakpoint 1 at 0x8002fd8: file src\main.cpp, line 6.
PlatformIO: Initialization completed
PlatformIO: Resume the execution to debug_init_break = tbreak main
PlatformIO: More configuration options → Redirecting...
Note: automatically using hardware breakpoints for read-only addresses.

Program
received signal SIGINT, Interrupt.
0x08001654 in _wait_us_ticks (ticks=ticks@entry=150000) at C:\Users\Gregor.platformio\packages\framework-mbed@5.51401.200110\platform\source\mbed_wait_api_no_rtos.c:66
66 while (((us_ticker_read() - start) & US_TICKER_MASK) < ticks);

(the last line is where the debugger stops by default)

I am building with mbed 5.51401.200110 (all default settings).

Does anyone know what could be going wrong here? What further information can I provide?

maxgerhardt · August 12, 2020, 4:00pm

What is the stack trace that leats up to mbed_die()? In the lower section of the VSCode debugging, you can go to the GDB console and type in backtrace, or look at the call stack in the GUI.

christandlg · August 12, 2020, 4:53pm

the issue seems to be in system_clock.c:

backtrace
#0 mbed_die () at C:\Users\Gregor.platformio\packages\framework-mbed@6.51504.200716\platform\source\mbed_board.c:38
#1 0x080015b6 in _exit (return_code=3) at C:\Users\Gregor.platformio\packages\framework-mbed@6.51504.200716\platform\source\mbed_retarget.cpp:1537
#2 0x080015c2 in __wrap_exit (return_code=) at C:\Users\Gregor.platformio\packages\framework-mbed@6.51504.200716\platform\source\mbed_retarget.cpp:1592
#3 0x08000f4c in mbed_halt_system () at C:\Users\Gregor.platformio\packages\framework-mbed@6.51504.200716\platform\source\mbed_error.c:118
#4 0x08000f6a in error (format=0x800b3d4 “SetSysClock failed\n”) at C:\Users\Gregor.platformio\packages\framework-mbed@6.51504.200716\platform\source\mbed_error.c:138
#5 0x08001822 in SetSysClock () at C:\Users\Gregor.platformio\packages\framework-mbed@6.51504.200716\targets\TARGET_STM\TARGET_STM32F4\TARGET_STM32F407xG\TARGET_DISCO_F407VG\system_clock.c:128
#6 0x08002770 in mbed_sdk_init () at C:\Users\Gregor.platformio\packages\framework-mbed@6.51504.200716\targets\TARGET_STM\mbed_overrides.c:129
#7 0x08001652 in software_init_hook () at C:\Users\Gregor.platformio\packages\framework-mbed@6.51504.200716\platform\source\mbed_sdk_boot.c:101
#8 0x080001f6 in _start ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
{“token”:42,“outOfBandRecord”:,“resultRecords”:{“resultClass”:“done”,“results”:}}

system_clock.c:

void SetSysClock(void)
{
#if ((CLOCK_SOURCE) & USE_PLL_HSE_EXTC)
    /* 1- Try to start with HSE and external clock */
    if (SetSysClock_PLL_HSE(1) == 0)
#endif
    {
#if ((CLOCK_SOURCE) & USE_PLL_HSE_XTAL)
        /* 2- If fail try to start with HSE and external xtal */
        if (SetSysClock_PLL_HSE(0) == 0)
#endif
        {
#if ((CLOCK_SOURCE) & USE_PLL_HSI)
            /* 3- If fail start with HSI clock */
            if (SetSysClock_PLL_HSI() == 0)
#endif
            {
                {
                    error("SetSysClock failed\n");  //<-- this is where the exception comes from
                }
            }
        }
    }

    /* Output clock on MCO2 pin(PC9) for debugging purpose */
    //HAL_RCC_MCOConfig(RCC_MCO2, RCC_MCO2SOURCE_SYSCLK, RCC_MCODIV_1); // 84 MHz
}

the discovery board seems to be using a 8MHz crystal as HSE clock source while the clicker 2 uses a 12MHz crystal. that would explain why clock initialization fails. Now I just need to find out how to change the clock configuration…

maxgerhardt · August 12, 2020, 5:10pm

Well if you’re running on a different hardware configuration than the disco board then strictly said you’d need to define a new custom target, just like the docs show though in your case with the exact same µC as the provided target you can copy 99% of the code…

There are multiple possibilities here:

create a custom target and in its system_clock.c, use the appropriate code to run from HSE with a 12MHz base XTAL (can e.g. be autogenerated by STM32CubeMX, or recalculate PLL params by hand), or
use your current target but tell it do not use the HSE but HSI. You can reconfigure clock sources using the mbed_app.json file (docs) in the project and instructions like

  "target_overrides": { 
        "DISCO_F407VG": {
               "target.clock_source": "USE_PLL_HSI"
               }
        }

although a side effect of running on HSI is that USB functions will not be available (needs precise HSE clock).

maxgerhardt · August 12, 2020, 5:13pm

Actually, where did you read this? When I look in the schematics I see

A 25MHz crystal going into OSC_IN/OUT.

christandlg · August 12, 2020, 6:33pm

I know, that will be my next step. I was hoping to be able to use this target for a quick test and forgot about that small detail…

You are correct, I was having a different Clicker 2 Manual opened besides the Clicker 2 for STM manual and accidentially took the value from there.
Thank you for your help!