mbed versioning mess

Even after reading about it, it took sometime to realize that version break changed the component name, so we have :

mbed	mbed 2 library
mbed-os	mbed 5 os and libraries

New mbed online Project

To create the project online, simply follow the link and click on import into Compiler

https://developer.mbed.org/users/hudakz/code/STM32F103C8T6_USBSerial/

• Update all libraries and dependencies (right click update)
• compile
• a bin file is automatically downloaded, ready to flash but by your own

No need to comment, out of the box compilation

Funny enough, the result is 1 KB beyond the Free Keil MDK limit, so won't be able to use the free version to recompile it offline.

STM32F103C8T6_USBSerialNUCLEO_F103RB.bin

33 KB

Export to the free world

The export is very simple, but note that you're moving from the arm compiler into the gcc compiler, and that won't be without consequences.

• The exported project has a makefile that you can compile by calling make
• make sure an arm gcc toolchain is within our path
• could be the official install "C:\Program Files (x86)\GNU Tools ARM Embedded\5.4 2016q3\bin"
• or even the platformIO toolchain "C:\Users\User\.platformio\packages\toolchain-gccarmnoneeabi\bin""

After the build, what a surprise !!!!!

PS D:\Projects\STM32\mbed\STM32F103C8T6_USBSerial> arm-none-eabi-size -B -d -t .\BUILD\STM32F103C8T6_USBSerial.hex
   text    data     bss     dec     hex filename
      0   68320       0   68320   10ae0 .\BUILD\STM32F103C8T6_USBSerial.hex
      0   68320       0   68320   10ae0 (TOTALS)

STM32F103C8T6_USBSerial.bin

67 KB

As you might have noticed that goes beyond the Bluepill Flash size.

• That the export from arm compiler to gcc doubles the code size is somehow impressive, is the arm compiler that efficient or is this a misconfiguration ?
• Answer to this question lay in the library, after the AMAP analysis tool allowed me to figure out that it's a library problem, a quick search resulted in such links : an explanation is here.
• Possible solution : check how to include other libs than the compiler default ones, stack overflow post.

Next steps will cover creating mbed cli and platformIO projects and try to manage the dependencies "mbed-STM32F103C8T6" and "USBDevice_STM32F103" to make them work. Understanding how to modify the environment parameter is crucial for such cases that require optimization.

mbedCLI

• Github doc for mbed cli
• Official doc for mbed cli

The idea here is not to create a tutorial on how to use mbed CLI, for that and other install and use steps please refer to the up link. Here is meant to have a quick view on possibilities and a reminder for steps and commands.

To use the GCC (Free and open), one way is to configure a system variable

MBED_GCC_ARM_PATH

or simply in "mbed_settings.py"

# GCC ARM
GCC_ARM_PATH = "C:\Program Files (x86)\GNU Tools ARM Embedded\6 2017-q1-update\bin"

import an existing project with mbed CLI

>mbed import http://mbed.org/users/hudakz/code/STM32F103C8T6_Hello/
>cd mbed
>mbed update
>cd ..
>mbed compile -t GCC_ARM -m NUCLEO_F103RB

Not updating it gets a compiler error, I don't know if this is a dependency mistake or a configuration error.

The target "BLUEPILL_F103C8" not recognised (only recognized in platformIO) you have to build for the Nucleo. Reason behind this is that the Blue pill does not have an mbed drag and drop ability, I find this reason funny. so here the hack is the already patched main including the right header before mbed.h and very important is to call yourself the confSysClock();

#include "stm32f103c8t6.h"
#include "mbed.h"
int main() {
    confSysClock();     //Configure system clock (72MHz HSE clock, 48MHz USB clock)

Better way to import a project by knowing what is going on

clone the complete repo or just copy the content of the sub directory test project, note you can also create a new project this way which I find more convenient as the whole thing is just around 1 KB.

The ".mbed" contains all the magic, tool chain, target,...

TOOLCHAIN=GCC_ARM
TARGET=NUCLEO_F103RB
ROOT=.

I do not knwo why the mbed has a different file extension for its library reference in the "mbed.bld"

https://mbed.org/users/mbed_official/code/mbed/builds/794e51388b66

There you could check and change the version manually if you want

and we're using a library, where there could be many, each should have a .lib file with one line :

http://mbed.org/users/hudakz/code/mbed-STM32F103C8T6/#9fbbea76d6f6

And you're ready to go. The mbed import does both create the file reference and download the whole thing, which we have here in separate steps. Now when we want to download the content after having committed the new project for example :

mbed deploy

and to compile, as we already declared the toolchain and target, it is an easy to type command :

mbed compile

mbed vs mbed-os

no big difference, the size difference was coming from the usage of the printf function.

Error with mbed-STM32F103C8T6

I got this error, which only happens if you do not compile in steps

[ERROR] .\mbed-os\targets\TARGET_STM\pinmap.c: In function 'pin_function':

although the code does not compile with the library added, even if not being used, removing the library compiling, then adding it solved the problem.

>mbed compile
>ERROR...
>mbed remove mbed-STM32F103C8T6
>mbed compile
>mbed add http://mbed.org/users/hudakz/code/mbed-STM32F103C8T6/
>cd .\mbed-STM32F103C8T6\
>mbed update
>cd ..
>mbed compile

Error Debug

• The build log have identical compile command line
• what differs is that every compile includes a special generated file ".includes_3e6572221c5360985dfa2ac639f88542.txt"
• there it's possible to see the include path, that in case of an added library, its include is put in the beginning " -I./mbed-STM32F103C8T6"

And that explains the missing declaration of "STM_PIN_INPUT" that comes from "PinNames.h" file overridden by the library "mbed-STM32F103C8T6"

• Once the error is understood, the fix is here, not more as a lib but committed to the project's dir

Solution add patching mbed-os to support the Blue pill

• The only differences between the builds are the mcu name TARGET_STM32F103RB and TARGET_STM32F103C8
• These two targets are identical, only differ in the Flash size
• If that is really a reason not to support a smaller size then patching the file "STM32F103XB.ld" down to 64K, should be a problem but in fact no, it compiles.
• The error coming from "RTX_Conf_CM.c" require "OS_TASKCNT" to be defined, which is defined for the F103RB in here "mbed_rtx.h"

It is enough to copy paste the section for the 103C8

#elif defined(TARGET_STM32F103RB)
#ifndef INITIAL_SP
#define INITIAL_SP              (0x20005000UL)
#endif
#ifndef OS_TASKCNT
#define OS_TASKCNT              6
#endif
#ifndef OS_MAINSTKSIZE
#define OS_MAINSTKSIZE          128
#endif
#ifndef OS_CLOCK
#define OS_CLOCK                72000000
#endif
#elif defined(TARGET_STM32F103C8)
#ifndef INITIAL_SP
#define INITIAL_SP              (0x20005000UL)
#endif
#ifndef OS_TASKCNT
#define OS_TASKCNT              6
#endif
#ifndef OS_MAINSTKSIZE
#define OS_MAINSTKSIZE          128
#endif
#ifndef OS_CLOCK
#define OS_CLOCK                72000000
#endif

• To be sure, I searched for all locations using "TARGET_STM32F103RB" and found another one in "RTX_CM_lib.h" so patched as well

#if defined(TARGET_MCU_NRF51822) || defined(TARGET_MCU_NRF52832) || defined (TARGET_STM32F334R8) ||\
    defined(TARGET_STM32F070RB) || defined(TARGET_STM32F072RB) || \
    defined(TARGET_STM32F302R8) || defined(TARGET_STM32F303K8) || defined (TARGET_STM32F334C8) ||\
    defined(TARGET_STM32F103RB) || defined(TARGET_STM32F103C8)

• And now we can enjoy an mbed-os supporting the "BLUEPILL_F103C8" as a build target
• I forked the mbed-os to test the FIX, and sent it back through a pull request, let's see if it interests the mbed-os owners to take that modif.
• in the meanwhile it is possible to compile with the blue pill target by using this mbed-os version

mbed remove mbed-os
mbed add https://github.com/wassfila/mbed-o

All is not lost : reduce gcc compile size with libg_nano

• As the section title mention, it is possible to use much smalled libaray for such a mcu purpose which is the "libg_nano.a", it comes by default with the gcc compiler install under lib\thumb\v7-m.
• it is not necessary to pass it as argument with -l but there is a special flag for that purpose

"--specs=nano.specs"

A dirty hack was to change the file "mbed-os\tools\profiles\develop.json"

{
    "GCC_ARM": {
...
       "ld": ["-Wl,--gc-sections", "-Wl,--wrap,main", "-Wl,--wrap,_malloc_r",
               "-Wl,--wrap,_free_r", "-Wl,--wrap,_realloc_r",
               "-Wl,--wrap,_calloc_r", "-Wl,--wrap,exit", "-Wl,--wrap,atexit",
               "-Wl,-n","--specs=nano.specs"]
    },

or create another json file and pass it after the "mbed compile --profile" command.

Conclusion

• We successfully manged (not without pain, debug and difficulties) to switch from the online compiler to the offline cli commands
• in these steps we've seen lots of things from within the most importants
  • managing dependencies with mbed cli
  • adding blue pill support for Nucleo projects
  • patching the mbed-os to support the Blue pill as a target
  • Full control over the build chain by finding all flags
  • passing the magic flag that saves the Blue pill life together with the mbed-os