What is actually sent/loaded to a microcontroller / STM32?What is the STM32 event EVENTOUT?STM32 program not executingWhat are these components in block diagram of STM32?STM32 Series Microcontroller - Calculations of Timer VariablesWhat does “Low density device” mean? About STM8 / STM32Atollic STM32H7 + ST-LINK Error writing data to flash with math librarySTM32 GPIO SpeedWhich STM32 microcontroller has the most PWM channels?STM32 Power connections questionWhat STM32 to learn with?
Is it safe if the neutral lead is exposed and disconnected?
How can Paypal know my card is being used in another account?
What would the United Kingdom's "optimal" Brexit deal look like?
Summoning A Technology Based Demon
Scam? Checks via Email
How do I make my photos have more impact?
Why were contact sensors put on three of the Lunar Module's four legs? Did they ever bend and stick out sideways?
What are the closest international airports in different countries?
Can Lightning Lure be used to knock out a creature like a magical Taser?
What is more environmentally friendly? An A320 or a car?
Why was the LRV's speed gauge displaying metric units?
Is it okay for me to decline a project on ethical grounds?
Why force the nose of 737 Max down in the first place?
Composing fill in the blanks
Blank spaces in a font
Argand formula and more for quaternions?
GNU sort stable sort when sort does not know sort order
How to have poached eggs in "sphere form"?
My employer is refusing to give me the pay that was advertised after an internal job move
A variant of the Multiple Traveling Salesman Problem
Would people understand me speaking German all over Europe?
Piece of chess engine, which accomplishes move generation
Why did House of Representatives need to condemn Trumps Tweets?
Why is my fluorescent tube orange on one side, white on the other and dark in the middle?
What is actually sent/loaded to a microcontroller / STM32?
What is the STM32 event EVENTOUT?STM32 program not executingWhat are these components in block diagram of STM32?STM32 Series Microcontroller - Calculations of Timer VariablesWhat does “Low density device” mean? About STM8 / STM32Atollic STM32H7 + ST-LINK Error writing data to flash with math librarySTM32 GPIO SpeedWhich STM32 microcontroller has the most PWM channels?STM32 Power connections questionWhat STM32 to learn with?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;
$begingroup$
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.
microcontroller stm32
edited Jul 20 at 12:47
Peter Mortensen
1,5993 gold badges14 silver badges22 bronze badges
asked Jul 19 at 17:22
muyustanmuyustan
928 bronze badges
$endgroup$
|
show 4 more comments
$begingroup$
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.
microcontroller stm32
edited Jul 20 at 12:47
Peter Mortensen
1,5993 gold badges14 silver badges22 bronze badges
asked Jul 19 at 17:22
muyustanmuyustan
928 bronze badges
$endgroup$
1
$begingroup$
It is usually sent via some proprietary USB protocol to some on-(or off..)board proprietary USB to JTAG or SWD converter, which is sending the bitstream to the actual controller.ELFfiles are pretty much unrelated, it is just a format that can contain the executable and meta-data. They are first converted to raw binaries and then sent as stated above.
$endgroup$
– Eugene Sh.
Jul 19 at 17:26
$begingroup$
@EugeneSh thanks for the answer. However you did not mention about "what" is sent? I am actually expecting an answer for example like " A.hex / .bin / .c / xyzfile is sent. " This question came my mind originaly from a video I watched in which -if I remember correctly- somebody was connecting its MCU(an stm32 board) to PC, and the PC sees it as a removable disk. Then he just dragged a file in that disk as if he was copying some file to a regular USB drive.
$endgroup$
– muyustan
Jul 19 at 17:30
1
$begingroup$
Usuallybinis the raw binary, so it is containing all and only data required for the programming. What you describe here seem to be something completely different - something like an already programmed STM32 which is emulating mass storage.
$endgroup$
– Eugene Sh.
Jul 19 at 17:32
$begingroup$
@EugeneSh. hmm, understood. Maybe I am just not remembering correctly. So, I have to use a software to load my code to the MCU then.
$endgroup$
– muyustan
Jul 19 at 17:44
1
$begingroup$
I am essentialy looking something identical to a .exe file- That is exactly what the ELF file is. Whileexestands for "executable",ELFstands for "executable & linkable foramat" - it is a single file format for both executables and libraries (dll). It is the executable format of the Unix world and is theexeformat on Linux. What is sent to an MCU depends on weather it is running an OS. On bare-metal machine (no or before OS) the programmer would strip out the ELF header and just send the bytes of machine code inside the ELF file.
$endgroup$
– slebetman
Jul 20 at 12:32
|
show 4 more comments
$begingroup$
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.
microcontroller stm32
edited Jul 20 at 12:47
Peter Mortensen
1,5993 gold badges14 silver badges22 bronze badges
asked Jul 19 at 17:22
muyustanmuyustan
928 bronze badges
$endgroup$
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.
microcontroller stm32
microcontroller stm32
edited Jul 20 at 12:47
Peter Mortensen
1,5993 gold badges14 silver badges22 bronze badges
asked Jul 19 at 17:22
muyustanmuyustan
928 bronze badges
edited Jul 20 at 12:47
Peter Mortensen
1,5993 gold badges14 silver badges22 bronze badges
asked Jul 19 at 17:22
muyustanmuyustan
928 bronze badges
edited Jul 20 at 12:47
Peter Mortensen
1,5993 gold badges14 silver badges22 bronze badges
edited Jul 20 at 12:47
Peter Mortensen
1,5993 gold badges14 silver badges22 bronze badges
edited Jul 20 at 12:47
Peter Mortensen
1,5993 gold badges14 silver badges22 bronze badges
1,5993 gold badges14 silver badges22 bronze badges
asked Jul 19 at 17:22
muyustanmuyustan
928 bronze badges
asked Jul 19 at 17:22
muyustanmuyustan
928 bronze badges
asked Jul 19 at 17:22
muyustanmuyustan
928 bronze badges
928 bronze badges
1
$begingroup$
It is usually sent via some proprietary USB protocol to some on-(or off..)board proprietary USB to JTAG or SWD converter, which is sending the bitstream to the actual controller.ELFfiles are pretty much unrelated, it is just a format that can contain the executable and meta-data. They are first converted to raw binaries and then sent as stated above.
$endgroup$
– Eugene Sh.
Jul 19 at 17:26
$begingroup$
@EugeneSh thanks for the answer. However you did not mention about "what" is sent? I am actually expecting an answer for example like " A.hex / .bin / .c / xyzfile is sent. " This question came my mind originaly from a video I watched in which -if I remember correctly- somebody was connecting its MCU(an stm32 board) to PC, and the PC sees it as a removable disk. Then he just dragged a file in that disk as if he was copying some file to a regular USB drive.
$endgroup$
– muyustan
Jul 19 at 17:30
1
$begingroup$
Usuallybinis the raw binary, so it is containing all and only data required for the programming. What you describe here seem to be something completely different - something like an already programmed STM32 which is emulating mass storage.
$endgroup$
– Eugene Sh.
Jul 19 at 17:32
$begingroup$
@EugeneSh. hmm, understood. Maybe I am just not remembering correctly. So, I have to use a software to load my code to the MCU then.
$endgroup$
– muyustan
Jul 19 at 17:44
1
$begingroup$
I am essentialy looking something identical to a .exe file- That is exactly what the ELF file is. Whileexestands for "executable",ELFstands for "executable & linkable foramat" - it is a single file format for both executables and libraries (dll). It is the executable format of the Unix world and is theexeformat on Linux. What is sent to an MCU depends on weather it is running an OS. On bare-metal machine (no or before OS) the programmer would strip out the ELF header and just send the bytes of machine code inside the ELF file.
$endgroup$
– slebetman
Jul 20 at 12:32
|
show 4 more comments
1
$begingroup$
It is usually sent via some proprietary USB protocol to some on-(or off..)board proprietary USB to JTAG or SWD converter, which is sending the bitstream to the actual controller.ELFfiles are pretty much unrelated, it is just a format that can contain the executable and meta-data. They are first converted to raw binaries and then sent as stated above.
$endgroup$
– Eugene Sh.
Jul 19 at 17:26
$begingroup$
@EugeneSh thanks for the answer. However you did not mention about "what" is sent? I am actually expecting an answer for example like " A.hex / .bin / .c / xyzfile is sent. " This question came my mind originaly from a video I watched in which -if I remember correctly- somebody was connecting its MCU(an stm32 board) to PC, and the PC sees it as a removable disk. Then he just dragged a file in that disk as if he was copying some file to a regular USB drive.
$endgroup$
– muyustan
Jul 19 at 17:30
1
$begingroup$
Usuallybinis the raw binary, so it is containing all and only data required for the programming. What you describe here seem to be something completely different - something like an already programmed STM32 which is emulating mass storage.
$endgroup$
– Eugene Sh.
Jul 19 at 17:32
$begingroup$
@EugeneSh. hmm, understood. Maybe I am just not remembering correctly. So, I have to use a software to load my code to the MCU then.
$endgroup$
– muyustan
Jul 19 at 17:44
1
$begingroup$
I am essentialy looking something identical to a .exe file- That is exactly what the ELF file is. Whileexestands for "executable",ELFstands for "executable & linkable foramat" - it is a single file format for both executables and libraries (dll). It is the executable format of the Unix world and is theexeformat on Linux. What is sent to an MCU depends on weather it is running an OS. On bare-metal machine (no or before OS) the programmer would strip out the ELF header and just send the bytes of machine code inside the ELF file.
$endgroup$
– slebetman
Jul 20 at 12:32
1
1
$begingroup$
It is usually sent via some proprietary USB protocol to some on-(or off..)board proprietary USB to JTAG or SWD converter, which is sending the bitstream to the actual controller.
ELF files are pretty much unrelated, it is just a format that can contain the executable and meta-data. They are first converted to raw binaries and then sent as stated above.$endgroup$
– Eugene Sh.
Jul 19 at 17:26
$begingroup$
It is usually sent via some proprietary USB protocol to some on-(or off..)board proprietary USB to JTAG or SWD converter, which is sending the bitstream to the actual controller.
ELF files are pretty much unrelated, it is just a format that can contain the executable and meta-data. They are first converted to raw binaries and then sent as stated above.$endgroup$
– Eugene Sh.
Jul 19 at 17:26
$begingroup$
@EugeneSh thanks for the answer. However you did not mention about "what" is sent? I am actually expecting an answer for example like " A
.hex / .bin / .c / xyz file is sent. " This question came my mind originaly from a video I watched in which -if I remember correctly- somebody was connecting its MCU(an stm32 board) to PC, and the PC sees it as a removable disk. Then he just dragged a file in that disk as if he was copying some file to a regular USB drive.$endgroup$
– muyustan
Jul 19 at 17:30
$begingroup$
@EugeneSh thanks for the answer. However you did not mention about "what" is sent? I am actually expecting an answer for example like " A
.hex / .bin / .c / xyz file is sent. " This question came my mind originaly from a video I watched in which -if I remember correctly- somebody was connecting its MCU(an stm32 board) to PC, and the PC sees it as a removable disk. Then he just dragged a file in that disk as if he was copying some file to a regular USB drive.$endgroup$
– muyustan
Jul 19 at 17:30
1
1
$begingroup$
Usually
bin is the raw binary, so it is containing all and only data required for the programming. What you describe here seem to be something completely different - something like an already programmed STM32 which is emulating mass storage.$endgroup$
– Eugene Sh.
Jul 19 at 17:32
$begingroup$
Usually
bin is the raw binary, so it is containing all and only data required for the programming. What you describe here seem to be something completely different - something like an already programmed STM32 which is emulating mass storage.$endgroup$
– Eugene Sh.
Jul 19 at 17:32
$begingroup$
@EugeneSh. hmm, understood. Maybe I am just not remembering correctly. So, I have to use a software to load my code to the MCU then.
$endgroup$
– muyustan
Jul 19 at 17:44
$begingroup$
@EugeneSh. hmm, understood. Maybe I am just not remembering correctly. So, I have to use a software to load my code to the MCU then.
$endgroup$
– muyustan
Jul 19 at 17:44
1
1
$begingroup$
I am essentialy looking something identical to a .exe file - That is exactly what the ELF file is. While exe stands for "executable", ELF stands for "executable & linkable foramat" - it is a single file format for both executables and libraries (dll). It is the executable format of the Unix world and is the exe format on Linux. What is sent to an MCU depends on weather it is running an OS. On bare-metal machine (no or before OS) the programmer would strip out the ELF header and just send the bytes of machine code inside the ELF file.$endgroup$
– slebetman
Jul 20 at 12:32
$begingroup$
I am essentialy looking something identical to a .exe file - That is exactly what the ELF file is. While exe stands for "executable", ELF stands for "executable & linkable foramat" - it is a single file format for both executables and libraries (dll). It is the executable format of the Unix world and is the exe format on Linux. What is sent to an MCU depends on weather it is running an OS. On bare-metal machine (no or before OS) the programmer would strip out the ELF header and just send the bytes of machine code inside the ELF file.$endgroup$
– slebetman
Jul 20 at 12:32
|
show 4 more comments
3 Answers
3
active
oldest
votes
$begingroup$
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.
answered Jul 19 at 17:52
ccoltonccolton
717 bronze badges
$endgroup$
1
$begingroup$
There are also schemes were a literal file is sent, there are many different ways possible, making the question fail the requirement of specific answerability.
$endgroup$
– Chris Stratton
Jul 19 at 18:11
$begingroup$
@ChrisStratton I agree, but the question clearly seems geared towards actual code being transferred to an MCU.
$endgroup$
– ccolton
Jul 19 at 18:13
$begingroup$
Thanks a lot to both of you, please let me ask like that then; I created a project on a PC for example. And for a reason I will change my PC let's say. Do I have to store the whole project folder to carry thecodewith me to load it into the MCU later from another PC? @ccolton @ChrisStratton
$endgroup$
– muyustan
Jul 19 at 18:21
$begingroup$
@muyustan If you need to modify the source code later, yes. If you just need one version of the code that you will never need to modify again, no.
$endgroup$
– ccolton
Jul 19 at 18:27
1
$begingroup$
@muyustan You just need the .hex/.bin file, those are the two biggest standards. Here is a forum link showing how to generate these. Then, all you need is ST-Link Utility to flash onto an MCU.
$endgroup$
– ccolton
Jul 19 at 19:15
|
show 3 more comments
$begingroup$
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).
edited Jul 20 at 8:58
ilkkachu
7145 silver badges8 bronze badges
answered Jul 20 at 2:04
old_timerold_timer
6,09216 silver badges28 bronze badges
$endgroup$
$begingroup$
well, I think I will explain this amazing answer of you in detail. Thanks for such effort.
$endgroup$
– muyustan
Jul 20 at 3:11
$begingroup$
@muyustan Where will you explain it?
$endgroup$
– Peter Mortensen
Jul 20 at 12:41
$begingroup$
@PeterMortensen misused word, it should have been "examine"
$endgroup$
– muyustan
Jul 20 at 12:45
add a comment |
$begingroup$
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.
answered Jul 19 at 20:00
alex.forencichalex.forencich
34.4k1 gold badge55 silver badges93 bronze badges
$endgroup$
$begingroup$
so, is this software and a .bin/.hex/.elf file is enough to load the instructions into the MCU?
$endgroup$
– muyustan
Jul 19 at 20:12
$begingroup$
Assuming the programming hardware you're using is compatible with st-link, then yes, that should be all you need.
$endgroup$
– alex.forencich
Jul 19 at 20:53
$begingroup$
yes it is, thanks.
$endgroup$
– muyustan
Jul 19 at 21:03
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
return StackExchange.using("schematics", function ()
StackExchange.schematics.init();
);
, "cicuitlab");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "135"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2felectronics.stackexchange.com%2fquestions%2f449120%2fwhat-is-actually-sent-loaded-to-a-microcontroller-stm32%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
$begingroup$
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.
answered Jul 19 at 17:52
ccoltonccolton
717 bronze badges
$endgroup$
1
$begingroup$
There are also schemes were a literal file is sent, there are many different ways possible, making the question fail the requirement of specific answerability.
$endgroup$
– Chris Stratton
Jul 19 at 18:11
$begingroup$
@ChrisStratton I agree, but the question clearly seems geared towards actual code being transferred to an MCU.
$endgroup$
– ccolton
Jul 19 at 18:13
$begingroup$
Thanks a lot to both of you, please let me ask like that then; I created a project on a PC for example. And for a reason I will change my PC let's say. Do I have to store the whole project folder to carry thecodewith me to load it into the MCU later from another PC? @ccolton @ChrisStratton
$endgroup$
– muyustan
Jul 19 at 18:21
$begingroup$
@muyustan If you need to modify the source code later, yes. If you just need one version of the code that you will never need to modify again, no.
$endgroup$
– ccolton
Jul 19 at 18:27
1
$begingroup$
@muyustan You just need the .hex/.bin file, those are the two biggest standards. Here is a forum link showing how to generate these. Then, all you need is ST-Link Utility to flash onto an MCU.
$endgroup$
– ccolton
Jul 19 at 19:15
|
show 3 more comments
$begingroup$
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.
answered Jul 19 at 17:52
ccoltonccolton
717 bronze badges
$endgroup$
1
$begingroup$
There are also schemes were a literal file is sent, there are many different ways possible, making the question fail the requirement of specific answerability.
$endgroup$
– Chris Stratton
Jul 19 at 18:11
$begingroup$
@ChrisStratton I agree, but the question clearly seems geared towards actual code being transferred to an MCU.
$endgroup$
– ccolton
Jul 19 at 18:13
$begingroup$
Thanks a lot to both of you, please let me ask like that then; I created a project on a PC for example. And for a reason I will change my PC let's say. Do I have to store the whole project folder to carry thecodewith me to load it into the MCU later from another PC? @ccolton @ChrisStratton
$endgroup$
– muyustan
Jul 19 at 18:21
$begingroup$
@muyustan If you need to modify the source code later, yes. If you just need one version of the code that you will never need to modify again, no.
$endgroup$
– ccolton
Jul 19 at 18:27
1
$begingroup$
@muyustan You just need the .hex/.bin file, those are the two biggest standards. Here is a forum link showing how to generate these. Then, all you need is ST-Link Utility to flash onto an MCU.
$endgroup$
– ccolton
Jul 19 at 19:15
|
show 3 more comments
$begingroup$
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.
answered Jul 19 at 17:52
ccoltonccolton
717 bronze badges
$endgroup$
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.
answered Jul 19 at 17:52
ccoltonccolton
717 bronze badges
edited Jul 19 at 18:11
answered Jul 19 at 17:52
ccoltonccolton
717 bronze badges
answered Jul 19 at 17:52
ccoltonccolton
717 bronze badges
answered Jul 19 at 17:52
ccoltonccolton
717 bronze badges
717 bronze badges
1
$begingroup$
There are also schemes were a literal file is sent, there are many different ways possible, making the question fail the requirement of specific answerability.
$endgroup$
– Chris Stratton
Jul 19 at 18:11
$begingroup$
@ChrisStratton I agree, but the question clearly seems geared towards actual code being transferred to an MCU.
$endgroup$
– ccolton
Jul 19 at 18:13
$begingroup$
Thanks a lot to both of you, please let me ask like that then; I created a project on a PC for example. And for a reason I will change my PC let's say. Do I have to store the whole project folder to carry thecodewith me to load it into the MCU later from another PC? @ccolton @ChrisStratton
$endgroup$
– muyustan
Jul 19 at 18:21
$begingroup$
@muyustan If you need to modify the source code later, yes. If you just need one version of the code that you will never need to modify again, no.
$endgroup$
– ccolton
Jul 19 at 18:27
1
$begingroup$
@muyustan You just need the .hex/.bin file, those are the two biggest standards. Here is a forum link showing how to generate these. Then, all you need is ST-Link Utility to flash onto an MCU.
$endgroup$
– ccolton
Jul 19 at 19:15
|
show 3 more comments
1
$begingroup$
There are also schemes were a literal file is sent, there are many different ways possible, making the question fail the requirement of specific answerability.
$endgroup$
– Chris Stratton
Jul 19 at 18:11
$begingroup$
@ChrisStratton I agree, but the question clearly seems geared towards actual code being transferred to an MCU.
$endgroup$
– ccolton
Jul 19 at 18:13
$begingroup$
Thanks a lot to both of you, please let me ask like that then; I created a project on a PC for example. And for a reason I will change my PC let's say. Do I have to store the whole project folder to carry thecodewith me to load it into the MCU later from another PC? @ccolton @ChrisStratton
$endgroup$
– muyustan
Jul 19 at 18:21
$begingroup$
@muyustan If you need to modify the source code later, yes. If you just need one version of the code that you will never need to modify again, no.
$endgroup$
– ccolton
Jul 19 at 18:27
1
$begingroup$
@muyustan You just need the .hex/.bin file, those are the two biggest standards. Here is a forum link showing how to generate these. Then, all you need is ST-Link Utility to flash onto an MCU.
$endgroup$
– ccolton
Jul 19 at 19:15
1
1
$begingroup$
There are also schemes were a literal file is sent, there are many different ways possible, making the question fail the requirement of specific answerability.
$endgroup$
– Chris Stratton
Jul 19 at 18:11
$begingroup$
There are also schemes were a literal file is sent, there are many different ways possible, making the question fail the requirement of specific answerability.
$endgroup$
– Chris Stratton
Jul 19 at 18:11
$begingroup$
@ChrisStratton I agree, but the question clearly seems geared towards actual code being transferred to an MCU.
$endgroup$
– ccolton
Jul 19 at 18:13
$begingroup$
@ChrisStratton I agree, but the question clearly seems geared towards actual code being transferred to an MCU.
$endgroup$
– ccolton
Jul 19 at 18:13
$begingroup$
Thanks a lot to both of you, please let me ask like that then; I created a project on a PC for example. And for a reason I will change my PC let's say. Do I have to store the whole project folder to carry the
code with me to load it into the MCU later from another PC? @ccolton @ChrisStratton$endgroup$
– muyustan
Jul 19 at 18:21
$begingroup$
Thanks a lot to both of you, please let me ask like that then; I created a project on a PC for example. And for a reason I will change my PC let's say. Do I have to store the whole project folder to carry the
code with me to load it into the MCU later from another PC? @ccolton @ChrisStratton$endgroup$
– muyustan
Jul 19 at 18:21
$begingroup$
@muyustan If you need to modify the source code later, yes. If you just need one version of the code that you will never need to modify again, no.
$endgroup$
– ccolton
Jul 19 at 18:27
$begingroup$
@muyustan If you need to modify the source code later, yes. If you just need one version of the code that you will never need to modify again, no.
$endgroup$
– ccolton
Jul 19 at 18:27
1
1
$begingroup$
@muyustan You just need the .hex/.bin file, those are the two biggest standards. Here is a forum link showing how to generate these. Then, all you need is ST-Link Utility to flash onto an MCU.
$endgroup$
– ccolton
Jul 19 at 19:15
$begingroup$
@muyustan You just need the .hex/.bin file, those are the two biggest standards. Here is a forum link showing how to generate these. Then, all you need is ST-Link Utility to flash onto an MCU.
$endgroup$
– ccolton
Jul 19 at 19:15
|
show 3 more comments
$begingroup$
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).
edited Jul 20 at 8:58
ilkkachu
7145 silver badges8 bronze badges
answered Jul 20 at 2:04
old_timerold_timer
6,09216 silver badges28 bronze badges
$endgroup$
$begingroup$
well, I think I will explain this amazing answer of you in detail. Thanks for such effort.
$endgroup$
– muyustan
Jul 20 at 3:11
$begingroup$
@muyustan Where will you explain it?
$endgroup$
– Peter Mortensen
Jul 20 at 12:41
$begingroup$
@PeterMortensen misused word, it should have been "examine"
$endgroup$
– muyustan
Jul 20 at 12:45
add a comment |
$begingroup$
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).
edited Jul 20 at 8:58
ilkkachu
7145 silver badges8 bronze badges
answered Jul 20 at 2:04
old_timerold_timer
6,09216 silver badges28 bronze badges
$endgroup$
$begingroup$
well, I think I will explain this amazing answer of you in detail. Thanks for such effort.
$endgroup$
– muyustan
Jul 20 at 3:11
$begingroup$
@muyustan Where will you explain it?
$endgroup$
– Peter Mortensen
Jul 20 at 12:41
$begingroup$
@PeterMortensen misused word, it should have been "examine"
$endgroup$
– muyustan
Jul 20 at 12:45
add a comment |
$begingroup$
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).
edited Jul 20 at 8:58
ilkkachu
7145 silver badges8 bronze badges
answered Jul 20 at 2:04
old_timerold_timer
6,09216 silver badges28 bronze badges
$endgroup$
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).
edited Jul 20 at 8:58
ilkkachu
7145 silver badges8 bronze badges
answered Jul 20 at 2:04
old_timerold_timer
6,09216 silver badges28 bronze badges
edited Jul 20 at 8:58
ilkkachu
7145 silver badges8 bronze badges
edited Jul 20 at 8:58
ilkkachu
7145 silver badges8 bronze badges
edited Jul 20 at 8:58
ilkkachu
7145 silver badges8 bronze badges
7145 silver badges8 bronze badges
answered Jul 20 at 2:04
old_timerold_timer
6,09216 silver badges28 bronze badges
answered Jul 20 at 2:04
old_timerold_timer
6,09216 silver badges28 bronze badges
answered Jul 20 at 2:04
old_timerold_timer
6,09216 silver badges28 bronze badges
6,09216 silver badges28 bronze badges
$begingroup$
well, I think I will explain this amazing answer of you in detail. Thanks for such effort.
$endgroup$
– muyustan
Jul 20 at 3:11
$begingroup$
@muyustan Where will you explain it?
$endgroup$
– Peter Mortensen
Jul 20 at 12:41
$begingroup$
@PeterMortensen misused word, it should have been "examine"
$endgroup$
– muyustan
Jul 20 at 12:45
add a comment |
$begingroup$
well, I think I will explain this amazing answer of you in detail. Thanks for such effort.
$endgroup$
– muyustan
Jul 20 at 3:11
$begingroup$
@muyustan Where will you explain it?
$endgroup$
– Peter Mortensen
Jul 20 at 12:41
$begingroup$
@PeterMortensen misused word, it should have been "examine"
$endgroup$
– muyustan
Jul 20 at 12:45
$begingroup$
well, I think I will explain this amazing answer of you in detail. Thanks for such effort.
$endgroup$
– muyustan
Jul 20 at 3:11
$begingroup$
well, I think I will explain this amazing answer of you in detail. Thanks for such effort.
$endgroup$
– muyustan
Jul 20 at 3:11
$begingroup$
@muyustan Where will you explain it?
$endgroup$
– Peter Mortensen
Jul 20 at 12:41
$begingroup$
@muyustan Where will you explain it?
$endgroup$
– Peter Mortensen
Jul 20 at 12:41
$begingroup$
@PeterMortensen misused word, it should have been "examine"
$endgroup$
– muyustan
Jul 20 at 12:45
$begingroup$
@PeterMortensen misused word, it should have been "examine"
$endgroup$
– muyustan
Jul 20 at 12:45
add a comment |
$begingroup$
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.
answered Jul 19 at 20:00
alex.forencichalex.forencich
34.4k1 gold badge55 silver badges93 bronze badges
$endgroup$
$begingroup$
so, is this software and a .bin/.hex/.elf file is enough to load the instructions into the MCU?
$endgroup$
– muyustan
Jul 19 at 20:12
$begingroup$
Assuming the programming hardware you're using is compatible with st-link, then yes, that should be all you need.
$endgroup$
– alex.forencich
Jul 19 at 20:53
$begingroup$
yes it is, thanks.
$endgroup$
– muyustan
Jul 19 at 21:03
add a comment |
$begingroup$
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.
answered Jul 19 at 20:00
alex.forencichalex.forencich
34.4k1 gold badge55 silver badges93 bronze badges
$endgroup$
$begingroup$
so, is this software and a .bin/.hex/.elf file is enough to load the instructions into the MCU?
$endgroup$
– muyustan
Jul 19 at 20:12
$begingroup$
Assuming the programming hardware you're using is compatible with st-link, then yes, that should be all you need.
$endgroup$
– alex.forencich
Jul 19 at 20:53
$begingroup$
yes it is, thanks.
$endgroup$
– muyustan
Jul 19 at 21:03
add a comment |
$begingroup$
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.
answered Jul 19 at 20:00
alex.forencichalex.forencich
34.4k1 gold badge55 silver badges93 bronze badges
$endgroup$
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.
answered Jul 19 at 20:00
alex.forencichalex.forencich
34.4k1 gold badge55 silver badges93 bronze badges
answered Jul 19 at 20:00
alex.forencichalex.forencich
34.4k1 gold badge55 silver badges93 bronze badges
answered Jul 19 at 20:00
alex.forencichalex.forencich
34.4k1 gold badge55 silver badges93 bronze badges
answered Jul 19 at 20:00
alex.forencichalex.forencich
34.4k1 gold badge55 silver badges93 bronze badges
34.4k1 gold badge55 silver badges93 bronze badges
$begingroup$
so, is this software and a .bin/.hex/.elf file is enough to load the instructions into the MCU?
$endgroup$
– muyustan
Jul 19 at 20:12
$begingroup$
Assuming the programming hardware you're using is compatible with st-link, then yes, that should be all you need.
$endgroup$
– alex.forencich
Jul 19 at 20:53
$begingroup$
yes it is, thanks.
$endgroup$
– muyustan
Jul 19 at 21:03
add a comment |
$begingroup$
so, is this software and a .bin/.hex/.elf file is enough to load the instructions into the MCU?
$endgroup$
– muyustan
Jul 19 at 20:12
$begingroup$
Assuming the programming hardware you're using is compatible with st-link, then yes, that should be all you need.
$endgroup$
– alex.forencich
Jul 19 at 20:53
$begingroup$
yes it is, thanks.
$endgroup$
– muyustan
Jul 19 at 21:03
$begingroup$
so, is this software and a .bin/.hex/.elf file is enough to load the instructions into the MCU?
$endgroup$
– muyustan
Jul 19 at 20:12
$begingroup$
so, is this software and a .bin/.hex/.elf file is enough to load the instructions into the MCU?
$endgroup$
– muyustan
Jul 19 at 20:12
$begingroup$
Assuming the programming hardware you're using is compatible with st-link, then yes, that should be all you need.
$endgroup$
– alex.forencich
Jul 19 at 20:53
$begingroup$
Assuming the programming hardware you're using is compatible with st-link, then yes, that should be all you need.
$endgroup$
– alex.forencich
Jul 19 at 20:53
$begingroup$
yes it is, thanks.
$endgroup$
– muyustan
Jul 19 at 21:03
$begingroup$
yes it is, thanks.
$endgroup$
– muyustan
Jul 19 at 21:03
add a comment |
Thanks for contributing an answer to Electrical Engineering Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2felectronics.stackexchange.com%2fquestions%2f449120%2fwhat-is-actually-sent-loaded-to-a-microcontroller-stm32%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
$begingroup$
It is usually sent via some proprietary USB protocol to some on-(or off..)board proprietary USB to JTAG or SWD converter, which is sending the bitstream to the actual controller.
ELFfiles are pretty much unrelated, it is just a format that can contain the executable and meta-data. They are first converted to raw binaries and then sent as stated above.$endgroup$
– Eugene Sh.
Jul 19 at 17:26
$begingroup$
@EugeneSh thanks for the answer. However you did not mention about "what" is sent? I am actually expecting an answer for example like " A
.hex / .bin / .c / xyzfile is sent. " This question came my mind originaly from a video I watched in which -if I remember correctly- somebody was connecting its MCU(an stm32 board) to PC, and the PC sees it as a removable disk. Then he just dragged a file in that disk as if he was copying some file to a regular USB drive.$endgroup$
– muyustan
Jul 19 at 17:30
1
$begingroup$
Usually
binis the raw binary, so it is containing all and only data required for the programming. What you describe here seem to be something completely different - something like an already programmed STM32 which is emulating mass storage.$endgroup$
– Eugene Sh.
Jul 19 at 17:32
$begingroup$
@EugeneSh. hmm, understood. Maybe I am just not remembering correctly. So, I have to use a software to load my code to the MCU then.
$endgroup$
– muyustan
Jul 19 at 17:44
1
$begingroup$
I am essentialy looking something identical to a .exe file- That is exactly what the ELF file is. Whileexestands for "executable",ELFstands for "executable & linkable foramat" - it is a single file format for both executables and libraries (dll). It is the executable format of the Unix world and is theexeformat on Linux. What is sent to an MCU depends on weather it is running an OS. On bare-metal machine (no or before OS) the programmer would strip out the ELF header and just send the bytes of machine code inside the ELF file.$endgroup$
– slebetman
Jul 20 at 12:32