Bootloader for STM32F401RC

[Am0k-GIT]

Hello.
I had no problems with my board (GRBL and Marlin firmware). Now I wrote a bootloader (<16Kb) that writes the firmware.bin file from the SD card to the MCU flash memory, starting from the ORIGIN address = 0x8008000 and passes control to it. So I have the following memory map:

0x8000000 - bootloader,
0x8004000 - EEPROM simulation,
0x8008000 - firmware.

This works fine in Marlin, but I could not compile a normal *.bin file for GRBL in PIO.

My *.ld script:

MEMORY
{
  RAM    (xrw)    : ORIGIN = 0x20000000,   LENGTH = 64K
  BOOT_FLASH    (rx)    : ORIGIN = 0x8000000,   LENGTH = 16K
  EEPROM_EMUL(xrw)      : ORIGIN = 0x8004000,   LENGTH = 16K
  FLASH    (rx)    : ORIGIN = 0x8008000,   LENGTH = 256K - 16K - 16K
}

_FLASH_VectorTable = ORIGIN(FLASH);
_EEPROM_Emul_Start = ORIGIN(EEPROM_EMUL);
_EEPROM_Emul_Sector = 1;

My ini:

[env:Halcyon_v1]
# With the default boot loader, you must deploy new firmware by copying
# .pio/build/<env name>/firmware.bin (produced by `pio run`) to the SD card.
board                = genericSTM32F401RC
board_build.ldscript = STM32F401RC_BL16K_FLASH.ld
build_flags          = ${common.build_flags}
  # See Inc/my_machine.h for options
                     -D BOARD_HALCYON_V1=
                     -D HSE_VALUE=8000000
                     -D HAS_BOOTLOADER=1
                     -D USB_SERIAL_CDC=1
                     -D SDCARD_ENABLE=1
                     -D _VOLUMES=1
                     -D EEPROM_IS_FRAM=1
lib_deps             = ${common.lib_deps}
					           eeprom
 					           trinamic
					           FatFs
					           sdcard
lib_extra_dirs       = ${common.lib_extra_dirs}

In terminal I see result:
Flash: [========= ] 85.1% (used 223204 bytes from 262144 bytes)

But in explorer I see "firmware.bin" (255 988 byte) in which 1 sector of the flash is completely filled with values 0x00000000.

How can I get a valid firmware file that will boot from 0x8008000 (my bootloader overrides SCB->VTOR) and use page 1 of the flash as EEPROM?

[terjeio]

PIO is not using the correct env: or a different .ld file?

The second word in the binary should be the address to Reset_Handler(), if not then linking is messed up?

[Am0k-GIT]

I use the same script and env that I used before without a bootloader, just adding
_FLASH_VectorTable = ORIGIN(FLASH);
to the script
and
-D HAS_BOOTLOADER=1
to the env.
The thing is that the file structure does not change depending on the flag
-D HAS_BOOTLOADER=1
I expected that the flag would make me use a third-party (my) bootloader, so the file would only contain the firmware, but for some reason it contains a 0-sector and a 1-sector, prepared as an EEPROM simulation.
Without the flag, I get a firmware that works when directly loaded into the board without any bootloader. With the flag, the firmware does not start when directly loaded, and it is impossible to load it using a bootloader (it is 32 KB larger than expected, that is, 2 sectors larger).
At the address 2 words I see 0x0803320D.

[Am0k-GIT]

This is my *.LD and *.ini files:
LD and INI.zip

[terjeio]

-D HAS_BOOTLOADER=1 only sets VTOR to the new address on startup. It is the linker that produces the binary, if this is incorrect then it did not get the information it needs.

At the address 2 words I see 0x0803320D.

This is at odds with this statement (if it is in the binary and not in the flash, or is it from a flash dump at 0x8008000?):

but for some reason it contains a 0-sector and a 1-sector, prepared as an EEPROM simulation.

Here are parts of the .map file for a bootloader image for a F407:

                0x20020000                        _estack = (ORIGIN (RAM) + LENGTH (RAM))
                0x00003000                        _Min_Heap_Size = 0x3000
                0x00001000                        _Min_Stack_Size = 0x1000
                0x08008000                        _FLASH_VectorTable = ORIGIN (FLASH)
                0x080e0000                        _EEPROM_Emul_Start = ORIGIN (EEPROM_EMUL)
                0x0000000b                        _EEPROM_Emul_Sector = 0xb

.isr_vector     0x08008000      0x188
                0x08008000                        . = ALIGN (0x4)
 *(.isr_vector)
 .isr_vector    0x08008000      0x188 ./StartupF407/startup_stm32f407vgtx.o
                0x08008000                g_pfnVectors
                0x08008188                        . = ALIGN (0x4)

.text           0x08008190    0x27d6c
                0x08008190                        . = ALIGN (0x4)
 *(.text)
 .text          0x08008190       0x40 C:/ST/STM32CubeIDE_1.5.1/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.13.3.rel1.win32_1.0.0.202411081344/tools/bin/../lib/gcc/arm-none-eabi/13.3.1/thumb/v7e-m+fp/hard/crtbegin.o

 .text.Reset_Handler
                0x080102ec       0x50 ./StartupF407/startup_stm32f407vgtx.o
                0x080102ec                Reset_Handler

and how it looks in ST-Link:

[Am0k-GIT]

Thanks for the answer.
The problem turned out to be quite superficial and is related to my inability to "properly prepare" *.LD files.
I simply changed the startup code section, specifying a new correct address (change BOOT_FLASH
to FLASH (0x8008000 instead 0x8000000)) and now I get a *.bin file with the correct structure and size at the output:

  .isr_vector :
  {
    . = ALIGN(4);
    KEEP(*(.isr_vector)) /* Startup code */
    . = ALIGN(4);
  } >FLASH

GRBL starts, but now there is no way to test everything on the hardware. After testing on the machine, I will create commits for my 2 boards and ask you to update their support files in the official branch.
Best wishes, Am0k.