cancel
Showing results for 
Search instead for 
Did you mean: 

Issue with .elf file when linker section is not placed according to adress.

MKori.1
Associate III

Hello,

to store my SW build information I defined in the linker file a section with a fixed address. like this:

  /* placing my build information at a named section: */
  .BuildInformationSegment 0x0800F000 :
  {
    KEEP(*(.BuildInformationSection)) /* keep my variable even if not referenced */
  }

This works and creates the section containing the string in the .bin. and .elf.

even when I misplace this part and dont sort it according to its address.

When I load the .elf into the STM32CubeProgrammer it looks like the .map file (or similar information) is used to generate a different binary which, when flashed leads to an error.

Here in the screenshot (some details removed) a difference between the bin. and the .elf is visible. This difference only occurs in STM32CubeProgrammer as the .bin is directly generated from the .elf via arm-none-eabi-objcopy. It occurs on the spot where the section is visible in the .map file:

                0x000000000800bf22                STL_TM_RAM_BckUpBuf_MarchCXStep
 
.BuildInformationSegment
                0x000000000800f000       0x60
 *(.BuildInformationSection)
 .BuildInformationSection
                0x000000000800f000       0x60 ./Core/Src/production_testing.o
 
.rodata         0x000000000800bfa4     0x11a8

0693W00000aJC8UQAW.jpg 

I know how to fix this in my software (place my section on the correct spot in the linker file) but still find it critical that the STM32CubeProgrammer creates a difference between .elf and .bin and therefore can lead to unexpeced behaviour.

I cant share my code or binaries but it should be reproducable with the linker code above placed somewhere else than in the end of the flash.

Best regards

Martin

2 REPLIES 2
MKori.1
Associate III

Hi,

I might add the output for readelf to make my point a little bit clearer. Please see below.

Both outputs differ in the position of BuildInform but lead to working binaries:

The bad one:

C:\my_Project>arm-none-eabi-readelf -S my_prj_bad.elf
There are 31 section headers, starting at offset 0x10549c:
 
Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .isr_vector       PROGBITS        08000000 000034 0000bc 00   A  0   0  1
  [ 2] .text             PROGBITS        080000bc 0000f0 00a86c 00  AX  0   0  4
  [ 3] text              PROGBITS        0800a928 00a95c 00167c 00  AX  0   0  4
  [ 4] .rodata           PROGBITS        0800bfa4 00bfd8 0011a8 00   A  0   0  4
  [ 5] .BuildInform[...] PROGBITS        0800f000 00d180 000060 00  WA  0   0  4
  [ 6] .ARM.extab        PROGBITS        0800d14c 00d1e0 000000 00   W  0   0  1
  [ 7] .ARM              ARM_EXIDX       0800d14c 00d1e0 000008 00  AL  2   0  4
  [ 8] .preinit_array    PREINIT_ARRAY   0800d154 00d1e8 000000 04  WA  0   0  1
  [ 9] .init_array       INIT_ARRAY      0800d154 00d1e8 000004 04  WA  0   0  4
  [10] .fini_array       FINI_ARRAY      0800d158 00d1ec 000004 04  WA  0   0  4
  [11] backup_buffe[...] NOBITS          20000000 00d1f0 000020 00  WA  0   0  4
  [12] .data             PROGBITS        20000020 0100b4 00003c 00  WA  0   0  4
  [13] .bss              NOBITS          2000005c 0100f0 000480 00  WA  0   0  4
  [14] ._user_heap_stack NOBITS          200004dc 0100f0 000604 00  WA  0   0  1
  [15] .ARM.attributes   ARM_ATTRIBUTES  00000000 0100f0 00002e 00      0   0  1
  [16] .debug_info       PROGBITS        00000000 01011e 01343c 00      0   0  1
  [17] .debug_abbrev     PROGBITS        00000000 02355a 003a0e 00      0   0  1
  [18] .debug_aranges    PROGBITS        00000000 026f68 0011d0 00      0   0  8
  [19] .debug_ranges     PROGBITS        00000000 028138 001000 00      0   0  8
  [20] .debug_macro      PROGBITS        00000000 029138 0190b2 00      0   0  1
  [21] .debug_line       PROGBITS        00000000 0421ea 017d60 00      0   0  1
  [22] .debug_str        PROGBITS        00000000 059f4a 099c9f 01  MS  0   0  1
  [23] .comment          PROGBITS        00000000 0f3be9 0039dd 00      0   0  1
  [24] .iar.rtmodel      PROGBITS        00000000 0f75c6 000111 00      0   0  1
  [25] .iar_vfe_header   PROGBITS        00000000 0f76d7 000064 00      0   0  4
  [26] .debug_frame      PROGBITS        00000000 0f773b 004c38 00      0   0  4
  [27] .symtab           SYMTAB          00000000 0fc373 005990 10     28 1071  4
  [28] .strtab           STRTAB          00000000 101d03 003539 00      0   0  1
  [29] .shstrtab         STRTAB          00000000 10523c 000160 00      0   0  1
  [30] CRCs area         PROGBITS        0800ff00 10539c 000100 00  WA  0   0  4

The good one:

C:\my_Project>arm-none-eabi-readelf -S my_prj_good.elf
There are 31 section headers, starting at offset 0x10543c:
 
Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .isr_vector       PROGBITS        08000000 000034 0000bc 00   A  0   0  1
  [ 2] .text             PROGBITS        080000bc 0000f0 00a86c 00  AX  0   0  4
  [ 3] text              PROGBITS        0800a928 00a95c 00167c 00  AX  0   0  4
  [ 4] .rodata           PROGBITS        0800bfa4 00bfd8 0011a8 00   A  0   0  4
  [ 5] .ARM.extab        PROGBITS        0800d14c 00d180 000000 00   W  0   0  1
  [ 6] .ARM              ARM_EXIDX       0800d14c 00d180 000008 00  AL  2   0  4
  [ 7] .preinit_array    PREINIT_ARRAY   0800d154 00d188 000000 04  WA  0   0  1
  [ 8] .init_array       INIT_ARRAY      0800d154 00d188 000004 04  WA  0   0  4
  [ 9] .fini_array       FINI_ARRAY      0800d158 00d18c 000004 04  WA  0   0  4
  [10] .BuildInform[...] PROGBITS        0800f000 00f034 000060 00  WA  0   0  4
  [11] backup_buffe[...] NOBITS          20000000 00f094 000020 00  WA  0   0  4
  [12] .data             PROGBITS        20000020 010054 00003c 00  WA  0   0  4
  [13] .bss              NOBITS          2000005c 010090 000480 00  WA  0   0  4
  [14] ._user_heap_stack NOBITS          200004dc 010090 000604 00  WA  0   0  1
  [15] .ARM.attributes   ARM_ATTRIBUTES  00000000 010090 00002e 00      0   0  1
  [16] .debug_info       PROGBITS        00000000 0100be 01343c 00      0   0  1
  [17] .debug_abbrev     PROGBITS        00000000 0234fa 003a0e 00      0   0  1
  [18] .debug_aranges    PROGBITS        00000000 026f08 0011d0 00      0   0  8
  [19] .debug_ranges     PROGBITS        00000000 0280d8 001000 00      0   0  8
  [20] .debug_macro      PROGBITS        00000000 0290d8 0190b2 00      0   0  1
  [21] .debug_line       PROGBITS        00000000 04218a 017d60 00      0   0  1
  [22] .debug_str        PROGBITS        00000000 059eea 099c9f 01  MS  0   0  1
  [23] .comment          PROGBITS        00000000 0f3b89 0039dd 00      0   0  1
  [24] .iar.rtmodel      PROGBITS        00000000 0f7566 000111 00      0   0  1
  [25] .iar_vfe_header   PROGBITS        00000000 0f7677 000064 00      0   0  4
  [26] .debug_frame      PROGBITS        00000000 0f76db 004c38 00      0   0  4
  [27] .symtab           SYMTAB          00000000 0fc313 005990 10     28 1071  4
  [28] .strtab           STRTAB          00000000 101ca3 003539 00      0   0  1
  [29] .shstrtab         STRTAB          00000000 1051dc 000160 00      0   0  1
  [30] CRCs area         PROGBITS        0800ff00 10533c 000100 00  WA  0   0  4

Best regards,

Martin

MKori.1
Associate III

I now also tried it with the STM32_Programmer_CLI and get the same, bad results. When I flash the .elf and calculate the checksum it is clearly different from when I flash the binary copy of the .elf done with objcopy and the software doesn't run. When I download the flash contents to a binary I can see the same difference as above.

STM32_Programmer_CLI -c port=SWD -d DEBUG_bad.elf -v -checksum
  Flash Memory checksum calculating ...
  Flash memory [0x08000000 : 0x08010000] - Checksum : 0x005EAFAA
arm-none-eabi-objcopy -O binary DEBUG_bad.elf DEBUG_bad_objcopy.bin
STM32_Programmer_CLI -c port=SWD -d DEBUG_bad_objcopy.bin 0x08000000 -v -checksum
  Flash Memory checksum calculating ...
  Flash memory [0x08000000 : 0x08010000] - Checksum : 0x0049BBDB