VVB (29.04.2014 10:06 - 11:57, просмотров: 2869)Подскажите по Keil MDK-ARM Замучился с ним.
Оказывается, он в строке int i; переменную i кладёт не в .bss, а в .data. Ладно, день потратил, разобрался. Надо было дать опцию компилятора --bss_threshold=0.
Ещё проблема.
Есть часть кода, работающая из ОЗУ, я её размещаю в секции .fastcode. Программа не работает. Полдня рыл, и нарыл: при формировании hex (s19) файла из выходного .axf начинает появляться информация в области памяти FLASH, откуда она будет копироваться в ОЗУ стартапными кейловскими файлами. Соответственно, при запуске стартапный код берёт из флэша необходимые данные и тупо копирует её в ОЗУ, где размещается .fastcode. Логичное поведение. Однако, если я не формирую hex, а начинаю отладку посредством gdb из эклипса, то данные в флэш для секции .fastcode отсутствуют (их просто нет). gdbserver от JLink честно сообщает, что секция .fastcode выходит за границы ELF сегмента (warning: Loadable segment "ER_FASTCODE" outside of ELF segments).
Вопрос: кто виноват и что делать?
Вариант1: виноват кейл. Благо просмотр размера секций в выходном .axf файле показывает, что да, действительно, секция ER2 не содержит данных для инициализации других секций, и gdb сервер често выполняет свои действия по программированию секции ER2.
Почему в секции ER2 нет данных для инициализации секции .fastcode?
Прикладываю .map файл, а также вывод информации о размере секций в .axf файле.
.sct файл:
#! armcc -E
; code upper need to use #define
;-------------------------------------------------------------------------------------
; Keil scatter loading file
; For AT91SAM7A3
;-------------------------------------------------------------------------------------
#define FLASH_START (0x00100000)
#define FLASH_END (0x00140000)
#define FLASH_SIZE (FLASH_END-FLASH_START)
; адрес размещения сервисной таблицы
#define FLASH_SRVCTBL 0x0013E700
; адрес размещения таблицы преобразования "давление-поток"
#define FLASH_FEXPTBL 0x0013E800
; адрес размещения таблицы преобразования генератора потока
#define FLASH_FGTBL 0x0013F000
; Internal SRAM
#define RAM_START 0x00200000
#define RAM_END 0x00208000
#define RAM_SIZE (RAM_END-RAM_START)
; посчитанное значение стеков из файла SAM7A3.asm
; место резервируется в SAM7A3.asm в секции STACK
#define IRQ_STACKSIZE 0x540
; Load region for main program
LR1 FLASH_START FLASH_SIZE {
ER_SRVCTBL FLASH_SRVCTBL UNINIT (FLASH_FEXPTBL-FLASH_SRVCTBL) {
*.o(.rodata_service_flash)
}
ER_FEXPTBL FLASH_FEXPTBL UNINIT (FLASH_FGTBL-FLASH_FEXPTBL) {
*.o(.rodata_flow_sensor)
}
ER_FGTBL FLASH_FGTBL UNINIT (FLASH_END-FLASH_FGTBL) {
*.o(.rodata_flow_gen)
}
ER2 FLASH_START {
*.o (.reset, +First)
*(InRoot$$Sections)
*(+RO)
}
ER_STACK (RAM_END-IRQ_STACKSIZE) RAM_SIZE {
*.o(STACK)
}
ER_FASTCODE RAM_START NOCOMPRESS RAM_SIZE {
*.o(.fastcode)
}
ER3 +0 (RAM_SIZE-ImageLength(ER_STACK)-ImageLength(ER_FASTCODE)) {
*.o (.critical)
}
ER4 +0 (RAM_SIZE-ImageLength(ER3)-ImageLength(ER_STACK)-ImageLength(ER_FASTCODE)) {
*.o (.criticalCRC)
}
ER5 +0 NOCOMPRESS (RAM_SIZE-ImageLength(ER3)-ImageLength(ER4)-ImageLength(ER_STACK)-ImageLength(ER_FASTCODE)) {
*.o(+RW +ZI)
}
}
Вот ещё вывод arm-none-eabi-readelf -e tst.axf
ELF Header: Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 Class: ELF32 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: ARM Version: 0x1 Entry point address: 0x100058 Start of program headers: 743232 (bytes into file) Start of section headers: 743264 (bytes into file) Flags: 0x5000002, has entry point, Version5 EABI Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 1 Size of section headers: 40 (bytes) Number of section headers: 23 Section header string table index: 22 Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] ER_SRVCTBL NOBITS 0013e700 000034 0000ac 00 WA 0 0 4 [ 2] ER_FEXPTBL NOBITS 0013e800 000034 0007d0 00 WA 0 0 4 [ 3] ER_FGTBL NOBITS 0013f000 000034 000ea8 00 WA 0 0 4 [ 4] ER2 PROGBITS 00100000 000034 027ea8 00 AX 0 0 8 [ 5] ER_STACK NOBITS 00207ac0 027edc 000540 00 WA 0 0 8 [ 6] ER_FASTCODE PROGBITS 00200000 027edc 00187c 00 AX 0 0 4 [ 7] ER3 NOBITS 0020187c 029758 0000c4 00 WA 0 0 4 [ 8] ER4 NOBITS 00201940 029758 000004 00 WA 0 0 4 [ 9] ER5 PROGBITS 00201944 029758 000078 00 WA 0 0 4 [10] ER5 NOBITS 002019bc 0297d0 0047ac 00 WA 0 0 8 [11] .debug_abbrev PROGBITS 00000000 0297d0 0005a4 00 0 0 1 [12] .debug_frame PROGBITS 00000000 029d74 0049cc 00 0 0 1 [13] .debug_info PROGBITS 00000000 02e740 029ae8 00 0 0 1 [14] .debug_line PROGBITS 00000000 058228 018158 00 0 0 1 [15] .debug_loc PROGBITS 00000000 070380 00ba8c 00 0 0 1 [16] .debug_macinfo PROGBITS 00000000 07be0c 01e0d0 00 0 0 1 [17] .debug_pubnames PROGBITS 00000000 099edc 0090ec 00 0 0 1 [18] .symtab SYMTAB 00000000 0a2fc8 00ae10 10 19 1658 4 [19] .strtab STRTAB 00000000 0addd8 007214 00 0 0 1 [20] .note NOTE 00000000 0b4fec 000038 00 0 0 4 [21] .comment PROGBITS 00000000 0b5024 000650 00 0 0 1 [22] .shstrtab STRTAB 00000000 0b5674 0000cc 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings) I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown) O (extra OS processing required) o (OS specific), p (processor specific) Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000034 0x00100000 0x00100000 0x2979c 0x2fc74 RWE 0x8 Section to Segment mapping: Segment Sections... 00 ER22. Виноват gdb. Потому что информация об адресе загрузки ER_FASTCODE есть в .axf, но её не понимает gdb. Зато её понимает утилита fromelf, которая из .axf получает .hex. Похоже, что надо из .axf получать .hex, сторонней утилитой программировать, и затем отлаживать. GDB -- жалкая поделка финских студентов!!! (c) (tm) fk0
-
- А если использовать J-link и встроенный отладчик? - Vladimir Ljaschko(30.04.2014 21:59)
)