eerimoq
commented
2 years ago Looks like bincopy should use "Program Headers:", which is does not do today. Does the physical addesses in the program headers section look correct?
$ readelf -a dev_hid_mouse_freertos.elf
...
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .interrupts PROGBITS 00000000 010000 000400 00 A 0 0 4
[ 2] .flash_config PROGBITS 00000400 010400 000010 00 A 0 0 1
[ 3] .text PROGBITS 00000410 010410 008fdc 00 AX 0 0 16
[ 4] .ARM ARM_EXIDX 000093ec 0193ec 000008 00 AL 3 0 4
[ 5] .init_array INIT_ARRAY 000093f4 0193f4 000004 04 WA 0 0 4
[ 6] .fini_array FINI_ARRAY 000093f8 0193f8 000004 04 WA 0 0 4
[ 7] .data PROGBITS 1fff0000 020000 0001ac 00 WA 0 0 4
[ 8] .bss NOBITS 1fff0200 020200 00887c 00 WA 0 0 512
[ 9] .heap NOBITS 20000000 030000 000100 00 WA 0 0 1
[10] .stack NOBITS 20000100 030000 002000 00 WA 0 0 1
[11] .ARM.attributes ARM_ATTRIBUTES 00000000 0201ac 000030 00 0 0 1
[12] .debug_info PROGBITS 00000000 0201dc 02470d 00 0 0 1
[13] .debug_abbrev PROGBITS 00000000 0448e9 004d53 00 0 0 1
[14] .debug_aranges PROGBITS 00000000 049640 000fd8 00 0 0 8
[15] .debug_ranges PROGBITS 00000000 04a618 000e38 00 0 0 1
[16] .debug_line PROGBITS 00000000 04b450 00ddb4 00 0 0 1
[17] .debug_str PROGBITS 00000000 059204 00a265 01 MS 0 0 1
[18] .comment PROGBITS 00000000 063469 000076 01 MS 0 0 1
[19] .debug_frame PROGBITS 00000000 0634e0 003e34 00 0 0 4
[20] .symtab SYMTAB 00000000 067314 004480 10 21 765 4
[21] .strtab STRTAB 00000000 06b794 002b93 00 0 0 1
[22] .shstrtab STRTAB 00000000 06e327 0000e4 00 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
L (link order), O (extra OS processing required), G (group), T (TLS),
C (compressed), x (unknown), o (OS specific), E (exclude),
y (purecode), p (processor specific)
There are no section groups in this file.
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x010000 0x00000000 0x00000000 0x00400 0x00400 R 0x10000
LOAD 0x010400 0x00000400 0x00000400 0x00010 0x00010 R 0x10000
LOAD 0x010410 0x00000410 0x00000410 0x08fec 0x08fec RWE 0x10000
LOAD 0x020000 0x1fff0000 0x000093fc 0x001ac 0x001ac RW 0x10000
LOAD 0x020200 0x1fff0200 0x00009600 0x00000 0x0887c RW 0x10000
LOAD 0x030000 0x20000000 0x20000000 0x00000 0x02100 RW 0x10000
...
Gargy007
Hello, I have found an issue within parsing of ELF file generated for ARM Cortex M4 MCU generated by GCC compiler (IAR has same issue).
The issue is following: As a ELF file has a lot of sections that should be placed in ROM area of MCU memory map, and one is BSS section (part of initial data that should be copied into RAM after MCU start) that is place after last .text section, but the BINCOPY placed it into address where will be copied after startup.
To simplify it:
The bin copy place this section on 0x1fff_0000 address instead of ~0x0000_9400.
To proof that I generate from GCC as ELF file (dev_hid_mouse_freertos.elf) as Intel HEX file(dev_hid_mouse_freertos.hex) both those file I convert by bincopy into S19 files(dev_hid_mouse_freertos_elf.s19, dev_hid_mouse_freertos_hex.s19) and compare that (See picture above). And to be sure that ELF file is correct I also convert ELF file by "arm-none-eabi-objcopy.exe" from GNU Tools and get binary file that's is using just right lower addresses (dev_hid_mouse_freertos.bin).
I guess that there is some issue with using of final address of data after MCU startup (any mark of reallocation in ELF probably) and address where is stored in ROM. bincopy issue.zip
Thank you Petr