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):
...
[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.
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 https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads. 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).
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.
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: GitHub - ARMmbed/mbed-os-example-blinky-baremetal: Bare metal blinky Mbed OS example
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:
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.
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: Downloads | GNU Arm Embedded Toolchain Downloads – Arm Developer
is the blinky also working?
This board was a ST giveaway and I found it my big ST box
But I experience a problem now that the clock is not initialized correctly and the program hangs in system_clock.c SetSysClock_PLL_HSI().
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.
Edit:
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
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.
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.
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?
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.