Moving isr_vector inside text section

[UriA]

Hi,

I just wanted to check if is it dangerous to move the isr_vector inside the text section like this:

.text :
{

. = ALIGN(4);
KEEP(*(.isr_vector))
. = ALIGN(4);
FILL(0x00000000);

. = ALIGN(4);
*(.text) /* .text sections (code) */
*(.text*)
*(.glue_7) /* glue arm to thumb code */
*(.glue_7t) /* glue thumb to arm code */
*(.eh_frame)

KEEP (*(.init))
KEEP (*(.fini))

. = ALIGN(4);
_etext = .; /* define a global symbols at end of code */
} >FLASH

I implemented a CRC32 integrity check and it doesn't work because the gap between the isr_vector and text section is always Fs when I debug with the CubeIDE, but if I download the .elf with CubeProgrammer, the gap is filled with 0s, and in that case it works.

TY for your help.

[TDK]

Yes, you can do this without any drawback or issues. The isr vector will still be at the start of the section, which is what matters.

[Saket_Om · Accepted solution]

Hello @UriA 

From a functional point of view, it is not dangerous to place the isr_vector inside the .text section, as long as the vector table is still located at the correct start address of Flash (typically 0x08000000) and the VTOR is configured accordingly.

If your CRC32 integrity check assumes that the padding area between the vector table and the rest of the code is filled with 0x00, you can enforce this padding explicitly instead of relying on the default filling behavior. For example:

__attribute__((section(".isr_padding")))
const unsigned char isr_padding[<PADDING_SIZE>] = { 0x00 };
In the linker script:

ld
. = ALIGN(4);
*(.isr_padding)
By defining a dedicated .isr_padding section filled with zeros and placing it right after the vector table in the linker script, you ensure that the memory gap always contains 0x00, regardless of whether the image is loaded via the debugger or via CubeProgrammer. This makes your CRC32 result consistent across tools.