1. Can you set up remotely updatable functions/code in a statically linked MCU firmware? #

Absolutely you can—static linking doesn’t block remote updates, but you need to plan your firmware layout and update logic carefully. Here’s the core idea:

• Use function pointers for indirection: Instead of calling B() directly everywhere in your code, use a function pointer that points to the fixed memory address where B() lives. This lets you swap out the code at that address during an update, and the rest of your firmware will automatically use the new version.
• Partition your Flash: Split your MCU’s Flash memory into separate regions—one for your core, non-updatable firmware (like the main loop or critical initialization) and a dedicated, erasable/writable region for updatable functions like B(). This prevents bricking your device if an update fails.
• Add validation checks: Before using an updated function, always verify its integrity with a CRC or SHA check. Many MCUs also have Memory Protection Units (MPUs) you can configure to lock down the updatable region except during the update process.

Static linking just means all code references are resolved at compile time—but by using indirection (function pointers) to access updatable code, you can safely swap out that code after a remote update.

2. How to generate an update patch for function B() in your bare-metal C program #

Since you’ve already placed B() in a fixed-address custom segment, here’s a step-by-step workflow to build a targeted patch:

Step 1: Lock in your linker script #

Ensure your linker script explicitly places B() (and only B()) in your named, fixed-address segment. Example linker script snippet:

/* Define the fixed Flash address for B() */
UPDATABLE_B_ADDR = 0x08020000; /* Adjust to your MCU's valid Flash address */

SECTIONS {
  /* ... keep your existing .text, .data, .bss sections ... */

  .updatable_b : ALIGN(4) {
    *(.updatable_b) /* Only include code marked for this segment */
  } > FLASH AT> FLASH
}

Then mark B() in b.c with the section attribute:

__attribute__((section(".updatable_b")))
void B(void) {
  // Your updated function logic here
}

Step 2: Compile only the updated B() file #

Instead of rebuilding your entire firmware, compile just b.c into an object file (adjust compiler flags to match your MCU):

arm-none-eabi-gcc -c b.c -o b.o -mcpu=cortex-m4 -mthumb -O2

Step 3: Extract the patch binary #

Use objcopy to pull out only the content of the .updatable_b segment—this gives you the raw binary patch for B():

arm-none-eabi-objcopy -O binary --only-section=.updatable_b b.o b_patch.bin

Step 4: Package the patch for safe delivery #

Wrap the raw binary with critical metadata to make the update robust:

• Target Flash address of B()
• Length of the patch (so your update code knows how many bytes to write)
• CRC32 or SHA-256 checksum of the patch binary

Step 5: Verify the patch #

Use objdump to confirm the object file’s segment matches your fixed address:

arm-none-eabi-objdump -h b.o

You should see .updatable_b listed at your target address.

When applying the patch remotely:

1. Have your main firmware receive the packaged patch via your communication interface (UART, CAN, WiFi, etc.)
2. Validate the checksum matches the received patch data
3. Erase the Flash sector containing B()
4. Write the raw b_patch.bin to the fixed address
5. Re-verify the written data with the checksum before resuming normal execution

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