mbed-cli | Arm Mbed Command Line Interface | Command Line Interface library

I have not tried all of them but the first and certainly the mbed supported nucleo boards show up as a virtual thumb drive, and you simply copy the .bin file over, no real magic to it from the host side no other software required other than what the operating system already has with respect to mounting usb flash drives. There is a debug header on these boards, and even if not that there is for the ones I know an mcu that manages the debug part I call that the debug mcu, then there is the mcu under test or the demonstration one that you bought the board to play with. The mbed ones have generally been arm and there is an swd (jtag-ish) interface, the debug mcu very likely uses that interface.

openocd is just one tool that knows the swd protocol, that doesnt mean that they have to run openocd on the mcu. you can write your own software to bit bang or talk to an ftdi chip to use mpsse or other solution to generate the swd protocol transitions on that bus.

Simplest case the firmware for the specific nucleo board only has to know that one stm32 it is programming, doesnt have to know more than that, but one swd is somewhat generic and may make sense to have a more generic debug mcu firmware.

Now these NUCLEO and other STM32 debug mcus also speak stlink which is separate from the firmware looks like a thumb drive deal. Stlink a protocol that a host can use to ask the debug mcu to do stuff, just like mpsse is a protocol/instruction set that you use to ask some ftdi parts to do stuff for you (a bit different but in concept speak one protocol to a proxy agent that does something for you).

This mbed cli could possibly just be copying the file over for you which you could have just done yourself. Or maybe it is speaking some other protocol The first mbeds were based on NXP parts not ST and thus dont have the stlink protocol on the front end. They had/have the just copy the binary which I remember seeing someones blog have so maybe they hired that person or borrowed that open source project.

While the mbed sandbox may be great I recommend you try out the other options, first mbed to build the binary, then copy it over, mbed to build it and maybe openocd through stlink to write it to flash. ST and NXP parts have traditionally had a bootloader that would support a uart protocol you can try that, as that is something you would very likely use, or swd, to get into a chip on a board if you were working on some product built around or that used chips like these but was not some hobby/eval board like the nucleos. I also recommend trying baremetal without the libraries, just read the manual, I find that easier than the libraries, YMMV, also ST has at least one set of its own libraries I think they are in a transition between to software solutions, perhaps try both or try the new one as the other will lose support.

You can also get the SWD spec and there are github and other open projects that can help, take your nucleo board and develop a program on one mcu to talk to another (mcus have gpio making it an easy way to bit bang, you can bit bang an ftdi part or do other things dont have to use an mcu) and try to learn/understand that protocol itself. It is used by all the cortex-ms thus far.

There is also a usb protocol like stlink that is being pushed by arm, the newer MSP432 launchpads use it or support it. The stlink protocol itself for that matter.

Anyway I digress the nucleo through the (debug) usb has the stlink protocol and has the I am a thumb drive thing, so mbed tools are likely using one of those probably the latter since stlink is likely not found on non-st products. Very likely that the debug mcu is using swd to program the development/demonstration mcu, dont know how else it would be doing it.

you cant compile them on mbed. Mbed uses HAL libraries anyway behind the scenes on STM32 devices but you cant compile those examples on embed.

The easy way:

Install openSTM32 package

Go to import/general/existing projects into workspace

Find the directory containing your example and SW4STM32 (it contains project files for your IDE)

Do not tick copy project into the workspace as it breaks include paths.

Finish and you are done.

Compile, run, enjoy

I've fixed my problem by installing these 2 repositories + my cmake was on pip3 strangely. It had install cmake with pip3 rather than pip2 since python3 is the main python on arch linux.

• arm-none-eabi-newlib
• avr-libc

here's the link that made me fix my problem:

arm-linux-gnu-gcc fatal error: stdio.h: No such file or directory

Did you accidentally remove the mbed_app.json file? The COMMON_PAL feature is declared in there.

This works for me (with mbed CLI):

That's the old example code based on mbed OS 3. Use the example for mbed OS 5 instead.

I think this is because you're referencing the mbed.h header (or Callback.h) from a .c file. Rename to C++.

If you need the file to be C, then wrap in an extern "C" {} block.