What is actually sent/loaded to a microcontroller / STM32?

Question

I see in all tutorials or sources, everybody creates a project in some IDEs and then loads code to the MCU again via those IDEs.

What is sent to the MCU? Is it a sequence of binary numbers or some different file?

Is there one file that I can just send it to the MCU without using any third-party application (IDEs)?

For example, I am using STMicroelectronics's STM32CubeIDE, and as I understood, it generates a .elf file. What is the role of this .elf file? In which step does it stand during loading code to MCU?

I think I found a better way to express myself.

I am essentially looking for something identical to a .exe file. Through the development of a .exe file, there are lots of parts .c , .h , .cpp for example. But an end user only needs an .exe file to run the code. Then I wonder if there is an equivalent of this .exe file (or any executable file format from other operating systems) in embedded platforms.

The comments below the approved answer may be helpful to understand in detail.

Answer 1

As Eugene has already mentioned, getting the data off your computer and onto the microcontroller requires some form of proprietary USB to JTAG or Serial converter, and software to communicate with that converter. That said, you don't always have to know all the code (C files and such) to program a microcontroller. For instance, you can use a .hex file, which is just a formatted series of bytes and offsets loaded straight into the memory (flash, EEPROM,etc), to run from on an STM32 using the ST-Link Utility. Hex files are simply pre-compiled versions of the C files.

To address your comment about what "file" is sent to the microcontroller, there isn't one. The programmer simply wipes the MCU's memory, and then replaces that memory with different bytes. These bytes are determined by what's in the .hex/.bin file.

Answer 2

That is a lot of questions...

So a simple, technically functional, STM32 program:

.thumb

.globl _start
_start:
    .word 0x20000100
    .word reset
    .word 0x12345678
    .word 0xAABBCCDD
.thumb_func
reset:
    nop
    nop
    nop
    b reset

Build it and then see what we see:

$ arm-none-eabi-as so.s -o so.o
$ arm-none-eabi-ld -Ttext=0x08000000 so.o -o so.elf
$ arm-none-eabi-objcopy so.elf -O srec so.srec
$ arm-none-eabi-objcopy so.elf -O ihex so.hex
$ arm-none-eabi-objdump -D so.elf > so.list

actually start with this one:

$ arm-none-eabi-objdump -D so.o 

so.o:     file format elf32-littlearm


Disassembly of section .text:

00000000 <_start>:
   0:   20000100    andcs   r0, r0, r0, lsl #2
   4:   00000000    andeq   r0, r0, r0
   8:   12345678    eorsne  r5, r4, #120, 12    ; 0x7800000
   c:   aabbccdd    bge feef3388 <reset+0xfeef3378>

00000010 <reset>:
  10:   46c0        nop         ; (mov r8, r8)
  12:   46c0        nop         ; (mov r8, r8)
  14:   46c0        nop         ; (mov r8, r8)
  16:   e7fb        b.n 10 <reset>

The choice to use the ELF file format is not arbitrary but in some sense it is, there are other file formats that could be used or could invent a new one, but elf is quite useful for many architectures. The GNU tools at least for ARM default to ELF. The object files are in ELF format as well as we see above.

The assembler has converted the assembly language into machine code the best it can. The .word reset line is not an instruction it is me asking for the address of the label reset to be placed there as that is a vector table that you need to boot the processor. The linker will fill in the externs and other gaps that the compiler doesn't know at compile time. So linked we can see the output in the so.list file I created:

Disassembly of section .text:

08000000 <_start>:
 8000000:   20000100    andcs   r0, r0, r0, lsl #2
 8000004:   08000011    stmdaeq r0, {r0, r4}
 8000008:   12345678    eorsne  r5, r4, #120, 12    ; 0x7800000
 800000c:   aabbccdd    bge 6ef3388 <_stack+0x6e73388>

08000010 <reset>:
 8000010:   46c0        nop         ; (mov r8, r8)
 8000012:   46c0        nop         ; (mov r8, r8)
 8000014:   46c0        nop         ; (mov r8, r8)
 8000016:   e7fb        b.n 8000010 <reset>

When you read the documentation from ST and ARM you find that the STM32 family is so far based on ARM Cortex-M cores, pretty much all of the flavors they make, they so far all boot the same way. The 32-bit value at address zero in the processors memory space is a value that they load into the stack pointer for you, nice feature, but I won't spend more time on it. The 32 bit word at address 0x00000004 in the processors memory space is the address where the reset handler is when the processor comes out of reset that address points at the code to run. Those are instructions, so machine code. The vector table is just vectors. For reasons I won't go into the LSB has to be a one so for the address 0x00000010 the vector is 0x00000011.

And you can see that the toolchain has done what I asked and put the machine code for those no-ops and the branch in there.

Now for the processor to do what we want we have to have all of these bytes in a place where the processor gets them when it fetches/reads those addresses.

When you read the documentation you find that for bootloader and perhaps other reasons they can/will remap what is presented to the processor as memory at address 0x00000000. When in the normal operating mode the flash that is at address 0x08000000 is mirrored at address 0x00000000. So if I put 0x08000011 at address 0x08000004 which is mirrored to 0x00000004. After reset the processor then sees that in the vector table and now fetches instructions from 0x08000010 and if we do everything right the processor will find our instructions and run them.

When you read the documentation for the chip you find that the flash is in the part and there are a couple-three ways to program the flash, to write bytes to it. One is a serial/UART deal, you wire the boot pin(s) to be high or low, reset the part, and it goes into the built-in bootloader that ST puts in there, not ours. Then there are formatted packets you communicate with the part and with that protocol you can ask it to write data to certain addresses in that flash, so the vector table and the machine code is what we would need to write:

 8000000:   20000100
 8000004:   08000011
 8000008:   12345678
 800000c:   aabbccdd
 8000010:   46c0    
 8000012:   46c0    
 8000014:   46c0    
 8000016:   e7fb    

These are hex numbers, the address on the left, data on the right. THAT is what we need to transfer.

Some of the STM32's have a USB bootloader, and all have a JTAG like thing, SWD, which is what you get with ST-LINK and such. On a lot of development boards you are actually talking to another microcontroller and that microcontroller is the one that uses SWD to talk to the MCU you are developing for.

Then you can wrap all kinds of host development IDE software around these interfaces for this part or other on board features, etc.

There are MANY files that qualify as "binary" files.

All of the ones I created above contain/describe the bytes and addresses we need to go into the flash. But as you saw above when I disassembled the program in the ELF file the labels _start, reset are in the output, how is that possible if that is not in any way used by the processor? Because these types of binaries have information like that for debugging or disassembling or other similar reasons.

hexdump -C so.elf
00000000  7f 45 4c 46 01 01 01 00  00 00 00 00 00 00 00 00  |.ELF............|
00000010  02 00 28 00 01 00 00 00  00 00 00 08 34 00 00 00  |..(.........4...|
00000020  d0 01 01 00 00 02 00 05  34 00 20 00 01 00 28 00  |........4. ...(.|
00000030  06 00 05 00 01 00 00 00  00 00 01 00 00 00 00 08  |................|
00000040  00 00 00 08 18 00 00 00  18 00 00 00 05 00 00 00  |................|
00000050  00 00 01 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00010000  00 01 00 20 11 00 00 08  78 56 34 12 dd cc bb aa  |... ....xV4.....|
00010010  c0 46 c0 46 c0 46 fb e7  41 13 00 00 00 61 65 61  |.F.F.F..A....aea|
00010020  62 69 00 01 09 00 00 00  06 02 09 01 00 00 00 00  |bi..............|
00010030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00010040  00 00 00 08 00 00 00 00  03 00 01 00 00 00 00 00  |................|
00010050  00 00 00 00 00 00 00 00  03 00 02 00 01 00 00 00  |................|
00010060  00 00 00 00 00 00 00 00  04 00 f1 ff 06 00 00 00  |................|
00010070  11 00 00 08 00 00 00 00  02 00 01 00 0c 00 00 00  |................|
00010080  00 00 00 08 00 00 00 00  00 00 01 00 0f 00 00 00  |................|
00010090  10 00 00 08 00 00 00 00  00 00 01 00 21 00 00 00  |............!...|
000100a0  18 00 01 08 00 00 00 00  10 00 01 00 12 00 00 00  |................|
000100b0  18 00 01 08 00 00 00 00  10 00 01 00 20 00 00 00  |............ ...|
000100c0  18 00 01 08 00 00 00 00  10 00 01 00 59 00 00 00  |............Y...|
000100d0  00 00 00 08 00 00 00 00  10 00 01 00 2c 00 00 00  |............,...|
000100e0  18 00 01 08 00 00 00 00  10 00 01 00 38 00 00 00  |............8...|
000100f0  18 00 01 08 00 00 00 00  10 00 01 00 40 00 00 00  |............@...|
00010100  18 00 01 08 00 00 00 00  10 00 01 00 47 00 00 00  |............G...|
00010110  18 00 01 08 00 00 00 00  10 00 01 00 4c 00 00 00  |............L...|
00010120  00 00 08 00 00 00 00 00  10 00 01 00 53 00 00 00  |............S...|
00010130  18 00 01 08 00 00 00 00  10 00 01 00 00 73 6f 2e  |.............so.|
00010140  6f 00 72 65 73 65 74 00  24 64 00 24 74 00 5f 5f  |o.reset.$d.$t.__|
00010150  62 73 73 5f 73 74 61 72  74 5f 5f 00 5f 5f 62 73  |bss_start__.__bs|
00010160  73 5f 65 6e 64 5f 5f 00  5f 5f 62 73 73 5f 73 74  |s_end__.__bss_st|
00010170  61 72 74 00 5f 5f 65 6e  64 5f 5f 00 5f 65 64 61  |art.__end__._eda|
00010180  74 61 00 5f 65 6e 64 00  5f 73 74 61 63 6b 00 5f  |ta._end._stack._|
00010190  5f 64 61 74 61 5f 73 74  61 72 74 00 00 2e 73 79  |_data_start...sy|
000101a0  6d 74 61 62 00 2e 73 74  72 74 61 62 00 2e 73 68  |mtab..strtab..sh|
000101b0  73 74 72 74 61 62 00 2e  74 65 78 74 00 2e 41 52  |strtab..text..AR|
000101c0  4d 2e 61 74 74 72 69 62  75 74 65 73 00 00 00 00  |M.attributes....|
000101d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000101f0  00 00 00 00 00 00 00 00  1b 00 00 00 01 00 00 00  |................|
00010200  06 00 00 00 00 00 00 08  00 00 01 00 18 00 00 00  |................|
00010210  00 00 00 00 00 00 00 00  04 00 00 00 00 00 00 00  |................|
00010220  21 00 00 00 03 00 00 70  00 00 00 00 00 00 00 00  |!......p........|
00010230  18 00 01 00 14 00 00 00  00 00 00 00 00 00 00 00  |................|
00010240  01 00 00 00 00 00 00 00  01 00 00 00 02 00 00 00  |................|
00010250  00 00 00 00 00 00 00 00  2c 00 01 00 10 01 00 00  |........,.......|
00010260  04 00 00 00 07 00 00 00  04 00 00 00 10 00 00 00  |................|
00010270  09 00 00 00 03 00 00 00  00 00 00 00 00 00 00 00  |................|
00010280  3c 01 01 00 60 00 00 00  00 00 00 00 00 00 00 00  |<...`...........|
00010290  01 00 00 00 00 00 00 00  11 00 00 00 03 00 00 00  |................|
000102a0  00 00 00 00 00 00 00 00  9c 01 01 00 31 00 00 00  |............1...|
000102b0  00 00 00 00 00 00 00 00  01 00 00 00 00 00 00 00  |................|

You can see the strings _start and reset in the file. But if you look, you can see the 0x12345678 and 0xAABBCCDD values in there with the 0x08000010 and machine code before and after, put those in there to make it super easy to find.

00010000  00 01 00 20 11 00 00 08  78 56 34 12 dd cc bb aa  |... ....xV4.....|

Intel Hex and Motorola S-record are/were competing formats from back in the day still used by some tools, you could carry these files around and a ROM programmer would burn that into the ROM. They are ASCII files like these:

cat so.hex
:020000040800F2
:10000000000100201100000878563412DDCCBBAA94
:08001000C046C046C046FBE7F4
:0400000508000000EF
:00000001FF

cat so.srec
S00A0000736F2E7372656338
S31508000000000100201100000878563412DDCCBBAA86
S30D08000010C046C046C046FBE7E6
S70508000000F2

Tith the srecord the S3 lines describe the address and data that we need to go into the flash to run. The s0 and s7 lines are additional information that the processor does not need.

arm-none-eabi-objcopy so.elf -O binary so.bin
hexdump -C so.bin
00000000  00 01 00 20 11 00 00 08  78 56 34 12 dd cc bb aa  |... ....xV4.....|
00000010  c0 46 c0 46 c0 46 fb e7                           |.F.F.F..|
00000018

This form of binary file with this toolchain/tools is a memory image that needs to go into the processor, byte for byte. but the user has to know the address there is no debugging or other information like that the user has to know where this data goes.

These kinds of things are true for all processors, the details for each chip/core are specific to that core, how they start, if they have vector tables, the machine code itself, if the memory is in the part how to get the code in there, if outside the part descriptions of the busses so that you can interface the part to some memory or your logic so that when it reads/fetches the instructions at some address you provide the bytes from that address so that it works.

A very flexible file format like elf is such that you can use it to carry around the "binary" the program plus debug and other info, and then have tools like objcopy to convert it to file formats that other tools that don't support ELF might use. The elf file format you can google and is pretty simple, don't even need a library just read the file.

Not all MCUs have a bootloader built in, some only have one way in. Some folks develop their own bootloader that use other interfaces or the same ones in different ways, can/have created a bootloader for the STM32 that works over the UART using a different protocol than the one built in.

For the new fear of security "secure boot" the newer STM32's do not support the bootloader even though it's in the part, you have to unlock it before you can use it using another way in.

The STM32's only have a couple three ways in so all tools you find are coming in through one of those interfaces and/or the product has a bootloader and you are coming in through that (think AVR's on Arduinos).

Answer 3

The elf, bin, or hex file is essentially equivalent to an exe file (in fact, some operating systems use elf format for their native executables). However, you do need a way to transfer the data in this file over to the microcontroller, and this usually requires some sort of programming software. This will be a part of the IDE you use for development, but it is usually possible to get this piece in isolation just for "flashing" the microcontroller with the design. This will be dependent on the interface you're using to connect your computer to the microcontroller.

Answer 4

Elf, bin, or hex files are not essentially equivalent to an exe file. EXE files depend on Windows (or DOS) loader to do the necessary relocation to place the code, data, stack, etc., segments in the available memory of a PC. Binary files to be loaded into a MCU cannot be relocated at the time of loading and hence have to be fully located before loading. i.e. Memory addresses referenced are absolute and can't be changed during loading.

http://www.jklp.org/profession/books/mix/c07.html