What happens on the background when mbed CLI flashes the chip?

Question

Even though not every detail is relevant for this question, I will list my setup nonetheless:

• NUCLEO_F746ZG microcontroller board (https://os.mbed.com/platforms/ST-Nucleo-F746ZG/).
• I run mbed CLI (https://os.mbed.com/docs/v5.7/tools/arm-mbed-cli.html) to program the chip.
• My OS is Windows 10, 64-bit

To compile my code and flash the binary to the chip, I issue the following command in my cmd terminal:

> mbed compile -t GCC_ARM -m NUCLEO_F746ZG --flash

I get the following output:

...

+------------------+-------+-------+-------+
| Module           | .text | .data |  .bss |
+------------------+-------+-------+-------+
| [fill]           |   130 |     4 |    10 |
| [lib]\c.a        | 24965 |  2472 |    89 |
| [lib]\gcc.a      |  3120 |     0 |     0 |
| [lib]\misc       |   252 |    16 |    28 |
| mbed-os\drivers  |   658 |     4 |   100 |
| mbed-os\features |    74 |     0 | 12556 |
| mbed-os\hal      |  2634 |     4 |    66 |
| mbed-os\platform |  2977 |     4 |   270 |
| mbed-os\rtos     | 15887 |   168 |  5989 |
| mbed-os\targets  | 16013 |     4 |  1052 |
| source\main.o    |   244 |     4 |    84 |
| Subtotals        | 66954 |  2680 | 20244 |
+------------------+-------+-------+-------+
Total Static RAM memory (data + bss): 22924 bytes
Total Flash memory (text + data): 69634 bytes

Image: .\BUILD\NUCLEO_F746ZG\GCC_ARM\nucleo_f746zg_demo.bin
[mbed] Detected "NUCLEO_F746ZG" connected to "E:" and using com port "COM10"
        1 file(s) copied.

I'm particularly interested in the last lines, where the actual flashing of the chip takes place:

Image: .\BUILD\NUCLEO_F746ZG\GCC_ARM\nucleo_f746zg_demo.bin
[mbed] Detected "NUCLEO_F746ZG" connected to "E:" and using com port "COM10"
        1 file(s) copied.

I know from previous experience (before mbed CLI existed) that there is a lot going on to flash a binary to a chip. For example, I had to startup openocd, pass it a configuration file of the programmer (eg. stlink-v2-1.cfg) and a configuration file of the target board (eg. nucleo_f746zg.cfg). At last, I had to hand over the binary to openocd via a Telnet-session or a GDB-session. Everything is described extensively here: How to use the GDB (Gnu Debugger) and OpenOCD for microcontroller debugging - from the terminal?

Looking at mbed CLI flashing the chip, I get confused. What is happening on the background? Is mbed CLI secretly using openocd to connect to the chip? Or perhaps pyOCD? Or some other way?

Answer 1

mbed-cli is open source, you can find the repository here. If you search for "def compile_" you'll find the specific code for what is happening when you run mbed compile.

mbed-cli uses mbed-ls to detect your board and htrun to flash it. htrun has a variety of plugins for copying to different boards, including pyocd but in the most basic case it just copies to the disk detected with mbed-ls.

Answer 2

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.