STM32F404烧录Makefile中OBJCOPY=arm-none-eabi-objcopy的作用是什么？

Question #

I have an STM32F404 development board and am working through a tutorial to flash it. My project's Makefile includes these rules:

$(PROJ_NAME).elf: $(SRCS)
	$(CC) $(CFLAGS) $^ -o $@
	$(OBJCOPY) -O ihex $(PROJ_NAME).elf $(PROJ_NAME).hex
	$(OBJCOPY) -O binary $(PROJ_NAME).elf $(PROJ_NAME).bin
burn: proj
	$(STLINK)/st-flash write $(PROJ_NAME).bin 0x8000000

I've set OBJCOPY=arm-none-eabi-objcopy, but even after checking the tool's manual, I'm still confused about its specific role in this workflow.

Answer #

Let’s break this down clearly—since the official docs can feel a bit abstract, I’ll tie everything directly to your STM32 setup.

First, let’s start with the .elf file your compiler ($(CC)) spits out. That file is a fully-featured executable packed with debug symbols, section headers, and extra metadata that’s perfect for debugging with tools like GDB, but it’s way too bulky and not in a format your STM32’s bootloader can parse. That’s exactly where arm-none-eabi-objcopy comes in: it’s a specialized tool that copies and translates binary object files into formats tailored for specific use cases.

1. Generating the .hex file with -O ihex #

The Intel Hex (ihex) format is a human-readable text format that encodes binary data alongside memory address information. It’s a legacy format that some older programming tools still rely on, and it’s handy if you ever want to inspect your program’s raw data (you can open it in any text editor to see addresses and byte values). You’re not using this for your current burn target, but it’s a useful fallback.

2. Creating the .bin file with -O binary #

This is the step that makes your flashable image work. The -O binary flag tells objcopy to strip all non-essential data from the .elf file—think debug symbols, section headers, and any metadata that’s only useful for development tools. What’s left is pure, raw binary data that’s optimized to run on your STM32.

But it’s more than just a simple strip-and-copy:

• Your .elf file has distinct sections (like .text for executable code, .data for initialized variables, .bss for uninitialized variables). objcopy rearranges these sections to match the memory layout defined in your linker script—ensuring code goes to flash, initialized data goes to the right RAM addresses, etc.
• For the STM32F404, your program needs to start at 0x8000000 (the base address of the onboard flash memory). The .bin file objcopy creates is exactly the sequence of bytes that needs to be written to that address for your board to boot and run your program correctly.

In plain terms: Without arm-none-eabi-objcopy, you couldn’t take the compiler’s debug-friendly .elf file and turn it into a compact, bootloader-ready image that your STM32 can actually execute.

内容的提问来源于stack exchange，提问作者Mouin