How to correctly start developing an application offline using Mbed OS 2 in 2020?

I’m trying to get my STM32F031 to run Mbed OS 2 for about three days without luck.
I understand that Mbed OS 5 is too large for this target, so I decided to try Mbed OS 2.

What have I done?
I downloaded mbed-cli and simple blink examples with steps below on my Ubuntu 16.04 LTS (also tested 18.04 LTS):

sudo apt-get install python-pip
pip2 install --user mbed-cli

sudo apt-get install libc6:i386 libncurses5:i386 libstdc++6:i386 python-jsonschema python-pyelftools gcc-arm-none-eabi git

mbed import

cd mbed_blinky
mbed config -G GCC_ARM_PATH /usr/bin
mbed compile -m NUCLEO_F031K6 -t GCC_ARM -v

and got the following:

[Fatal Error] main.cpp@1,18: mbed.h: No such file or directory
[ERROR] ./main.cpp:1:18: fatal error: mbed.h: No such file or directory
 #include "mbed.h"
compilation terminated.

And even reverting mbed to e95d10626187 with

cd mbed
mbed update e95d10626187

does not help either.
And what is interesting the mbed folder always contain the latest revision 65be27845400.

Also I tried to reproduce some blog posts like one from @MACRUM with mbed-cli 1.8.2 and other stuff from 20180918 or older. This does not lead to positive result too.

My current conclusion is the following: there are some problems on the server-side of Downloading Mbed OS 2 archives from links like always end with fetching latest build which does not contain mbed.h (like with mbed-cli as desribed in ).

So my question is very simple - how to correctly start developing an application offline using Mbed OS 2 in 2020??

Hello norkosolko,

  • To cross compile for ARM Cortex processors on Linux Ubuntu install the GNU Arm Embedded Toolchain. Mbed OS 2 works best with release 6-2017-q2-update which is available at Download the tarball and unpack to the /opt directory. Make sure the related paths are exported (add export PATH=$PATH:/opt/gcc-arm-none-eabi-6-2017-q2-update/bin:/opt/gcc-arm-none-eabi-6-2017-q2-update/arm-none-eabi/bin:/opt/gcc-arm-none-eabi-6-2017-q2-update/arm-none-eabi/lib to the .bashrc file).
  • Rather than importing a project use the --mbedlib option to create a Mbed OS 2 program as described in the Mbed documentation Working with mbed-cli->Create->For Mbed OS 2.
  • Since Mbed Studio does not work on Linux, with a little patience you can setup an IDE too.
1 Like

Thank you for reply! And thanks for all your libraries and projects, I have tested them with PlatformIO and Mbed OS 5.

This will not fix the problem with mbed.h. I have already installed gcc-arm-none-eabi and it works.

I have already tried this. But this will end with missed mbed.h header too. I forgot to mention this in first post.

Looks nice, standalone and electron-free, but I suppose it will not fix the problem with missed mbed.h.

@hudakz If you have time, could you please reproduce the problem with compilation of simple blink example by using mbed-cli and Mbed OS 2 (--mbedlib)? I’m currently out of ideas.

After you have created a new program (with --mbedlib option) change your working directory to the new program’s directory (move into the directory of your new program) and then try to compile!

Dear Zoltan!
I have killed about three days doing what you are recommending. If I say that it does not work, then it really does not work with

[Fatal Error] main.cpp@1,18: mbed.h: No such file or directory
[ERROR] ./main.cpp:1:18: fatal error: mbed.h: No such file or directory
 #include "mbed.h"
compilation terminated.

even with clean python environment, fresh Ubuntu VM and so on. The issue seems to be already documented on .

Thanks for helping and recommendations. I would suggest to test all this yourself and reply only after this to keep topic clear :slight_smile:

mbed5 (or upcoming mbed6) becomes back usable for tiny targets. Now it is already possible with the currenct master branch, but it is not tested for all targets yet and a few tricks are necessary if you want to try it already:
You can start with:
Then you need to modify mbed-os/targets/targets.json: find your target and replace ‘default_lib’ with ‘c_lib’ (small must be used). I recommend to create a branch that you don’t have to modify original master sources.
This should work already with targets >= 8 kB RAM. But the F031 has only 4kB, so another setting in mbed_app.json to reduce the default stack size is necessary.
This would be a mbed_app.json that compiled with your target and current mbed-os master branch:

    "requires": ["bare-metal"],
    "target_overrides": {
        "*": {
            "target.boot-stack-size": "0x800",
            "target.printf_lib": "minimal-printf",
            "platform.minimal-printf-enable-floating-point": "false",
            "platform.stdio-minimal-console-only": true

compile also with --profile release to achive minimum size of code.
Because amount of RAM is low, you may need to decrease the stack size further. 32 k Flash should be sufficient for some stuff that worked with mbed2 also.

I could compile this code for your target, but i don’t have it and cannot test if its execuable. I’m currently also trying to get mbed-os5 running on other tiny targets.

And pls. don’t blame Zoltan, he is one of the few guys who is trying here to help many people. He has also a lot of sample code on his mbed user page. The problem is that mbed-os is very volatile and developing fast.



Thanks for your suggestion about Mbed OS 5.
I have just tested it again and again on Windows and Linux - it does not compile.
On the newest Ubuntu 20.04 LTS it can’t find the cstddef header, on Windows in Mbed Studio it shows some error about INITIAL_SP:

Compile [ 43.9%]: mbed_error.c
[Error] mbed_rtx.h@137,2: "INITIAL_SP is not defined for this target in the mbed_rtx.h file"
[ERROR] armclang: warning: -Wl,--library_type=microlib: 'linker' input unused [-Wunused-command-line-argument]
In file included from .\mbed-os\platform\source\mbed_error.c:30:
./mbed-os/targets/TARGET_STM\mbed_rtx.h:137:2: error: "INITIAL_SP is not defined for this target in the mbed_rtx.h file"
#error "INITIAL_SP is not defined for this target in the mbed_rtx.h file"
1 error generated.

even if main.cpp is as simple as

/* mbed Microcontroller Library
 * Copyright (c) 2019 ARM Limited
 * SPDX-License-Identifier: Apache-2.0

#include "mbed.h"

#define WAIT_TIME 500 //msec

DigitalOut led1(LED1);

int main()
    while (true)
        led1 = !led1;

with mbed_app.json contents exactly as you wrote and changes in mbed-os/targets/targets.json.

So version 5 would not compile on my target.

So I still need solution to my original problem with Mbed OS 2.

Then you don’t have used the bare-metal example or don’t have the mbed_app.json, INITIAL_SP is pulled in from the rtos . That’s excluded in bare metal.
And it seems you are using clang for compiling, this is not (yet?) supported as I know. For ubuntu, you will find the gcc-arm-toolchain here:

1 Like

Thanks, this made the trick.

The reproducible method to get Mbed OS 5 running on my target is the following:

# get toolchain
mkdir ~/Software
cd ~/Software
wget -c "" -O gcc-arm-none-eabi-9-2019-q4-major-x86_64-linux.tar.bz2

tar -xf gcc-arm-none-eabi-9-2019-q4-major-x86_64-linux.tar.bz2
mbed config -G GCC_ARM_PATH /home/$USER/Software/gcc-arm-none-eabi-9-2019-q4-major/bin
# clone project
cd ~/Projects/stm32
mbed import
cd mbed-os-example-blinky-baremetal
cd mbed-os/
git reset --hard  mbed-os-5.15.1
pip2 install -r requirements.txt
cd ..
# adjust build-settings
cat <<EOF > mbed_app.json
    "requires": ["bare-metal"],
    "target_overrides": {
        "*": {
            "target.boot-stack-size": "0x800",
            "target.printf_lib": "minimal-printf",
            "platform.minimal-printf-enable-floating-point": "false",
            "platform.stdio-minimal-console-only": true

It compiles the program by

mbed compile -m NUCLEO_F031K6 -t GCC_ARM -v --flash

with the following stats

| Module           |     .text |   .data |    .bss |
| [fill]           |    28(+0) |   0(+0) |  19(+0) |
| [lib]/c_nano.a   |  4956(+0) | 100(+0) |  21(+0) |
| [lib]/gcc.a      |  1632(+0) |   0(+0) |   0(+0) |
| [lib]/misc       |   192(+0) |   0(+0) |  28(+0) |
| [lib]/nosys.a    |    16(+0) |   0(+0) |   0(+0) |
| main.o           |    68(+0) |   0(+0) |  28(+0) |
| mbed-os/hal      |  1266(+0) |   4(+0) |  66(+0) |
| mbed-os/platform |  2156(+0) |   4(+0) | 206(+0) |
| mbed-os/targets  |  5026(+0) |   4(+0) | 232(+0) |
| Subtotals        | 15340(+0) | 112(+0) | 600(+0) |
Total Static RAM memory (data + bss): 712(+0) bytes
Total Flash memory (text + data): 15452(+0) bytes

Image: ./BUILD/NUCLEO_F031K6/GCC_ARM/mbed-os-example-blinky-baremetal.bin

and successfully uploads Mbed OS 5 to the board.

But I still hope to get original problem with Mbed OS 2 solved too.

is the blinky also working?
This board was a ST giveaway and I found it my big ST box :slight_smile:
But I experience a problem now that the clock is not initialized correctly and the program hangs in system_clock.c SetSysClock_PLL_HSI().

Blinky has some non-monotonic behavior.
But I see that I2C scanner works as expected. Will test further.

what does that mean? LED1 ist LD3 on the board, beside the reset button. The dual color led beside the USB connector is a status led for the STLink, this is not the blinky led.

Argghhh, F or L… I had just mixed up the NUCLEO_F and NUCLEO_L, there are both as 031K6. With the correct one, it is running imediately :slight_smile:

So I would not invest more time in getting mbed-os 2 running, mbed5(6) is the way to go. You have used the default profile for compiling, which is ‘develop’. When you use --profile release you can save more flash space.

1 Like

With latest post of @neiljackson about stability ( I still have questions about reproducible builds of Mbed OS 2.

Do we have any?

I also hit this problem recently and my colleague
might find the actual problem of this, that is primary ‘zip’ format can only archives less than equal 65535 files in it, but latest archive revision 65be27845400 may have over 65535 files.

65be27845400  bldrc
>find 65be27845400 -type f | wc -l

Current zip has been extended can treat over 65535 files which is usually available.
Would someone who on server please take care this problem, re-archive with zip which can handle over 65535 files?

Thanks in advance.

Hi Yamamoto-san,

but latest archive revision 65be27845400 may have over 65535 files.

AFAIK, Mbed 2 library version 165 (#65be27845400) has missing files. I recommend to use version 163 (#e95d10626187) instead.

AFAIK, Mbed 2 library version 165 (#65be27845400) has missing files. I recommend to use version 163 (#e95d10626187) instead.

Thanks for your information. I have been using #e95d10626187, but current server behavior might have been changed as suppling #65be27845400 instead of #e95d10626187 or other any revisions in around 2020 March. And I couldn’t realize that changes until recent, because I had had a mbed_cache of #e95d10626187. And I’m guessing the missing files problem is due to the zip limitation.


You can use this archive here:

And my article in Japanese might be help.

Is the article available in English?

Sorry, I didn’t create English version, but you can use web translation service such as Google translate etc.

Thanks for your contribution.