Дополнительные данные присутствуют во флэш-памяти после последней загруженной секции эльфа - PullRequest
0 голосов
/ 08 июня 2019

У меня есть проект STM32, который включает загрузчик.CRC начального загрузчика проверяет всю область приложения флэш-памяти, а затем сравнивает это значение с заголовком прошивки, хранящимся сразу после области образа приложения во флэш-памяти.

Я написал скрипт Python, который запускается после сборки двоичного файла.Сценарий берет файл elf, полученный в результате сборки, и загружает каждый раздел в образ «виртуальной флеш-памяти», который представляет то, что должно быть именно тем, что присутствует в mcu после обычной загрузки elf.Массив начинается с размера области приложения, с начальными значениями 0xff для каждого байта, так же, как флэш-память будет после полного стирания.Затем сценарий берет каждый раздел из elf и перезаписывает раздел изображений виртуальной флэш-памяти, в котором этот раздел должен находиться.

Наконец, сценарий CRC обрабатывает область приложения и вводит полученное значение в исходный elf.

Это все работает нормально, но я вижу дополнительные данные в реальном содержимом флэш-памяти mcu, из-за которых я не могу определить происхождение.Вспышка полностью стирается перед программированием эльфа, поэтому эти данные поступают от эльфа, загруженного на устройство.

Я предполагаю, что здесь происходит то, что в эльфе есть разделы, в которых мой скриптигнорируя, но они все еще записываются на флэш-память при использовании обычных средств.

Ниже приведен результат readelf в образе моего приложения:

Заголовки разделов: [Nr] Имя Тип Addr Выкл. Размер ES Flg Lk Inf Al

[0] NULL 00000000 000000 000000 00 0 0 0

[1] .isr_vector PROGBITS 08020000 010000 0001f8 00 WA 0 0 4

[2] .firmware_header_ PROGBITS 080201f8 0101f8 000004 00 WA 04

[3] .text PROGBITS 08020200 010200 01e11c 00 AX 0 0 64

[4] .ARM.extab PROGBITS 0803e31c 033a68 000000 00 W 0 0 1

[5] .exidx ARM_EXIDX 0803e31c 02e31c 000008 00 AL 3 0 4

[6] .ARM.attributes ARM_ATTRIBUTES 0803e324 033a68 000030 00 0 0 1

[7] .itWA 0 0 4

[8] .fini_array FINI_ARRAY 0803e32c 02e32c 000004 04 WA 0 0 4

[9] .firmware_header PROGBITS 0803e330 02e330 000008 00 WA 0 0 4

* 355[10] .data PROGBITS 20000000 030000 0009c8 00 WA 0 0 8

[11] .RxDecripSection PROGBITS 200009c8 0309c8 000080 00 WA 0 0 4

[12] .RxarraySection PROGBITS 20000a48 030a48 0017d0 00 WA 0 0 4

[13] .TxDescripSection PROGBITS 20002218 032218 000080 00 WA 0 4*

[14] .TxarraySection PROGBITS 20002298 032298 0017d0 00 WA 0 0 4

[15] .bss NOBITS 20003a68 033a68 045bc0 00 WA 0 0 8

[16] .heap PROGBITS20049628 033a98 000000 00 W 0 0 1

[17] .reserved_for_sta PROGBITS 20049628 033a98 000000 00 W 0 0 1

[18] .battery_backed_s NOBITS 40024000 034000 00000c 00 WA 0 0 4

[19] .комментарий PROGBITS 00000000 033a98 000075 01 MS 0 0 1

[20] .debug_frame PROGBITS 00000000 033b10 001404 00 0 0 4

[21] .stab PROGBITS 00000000034f14 000084 0c 22 0 4

[22] .stabstr STRTAB 00000000 034f98 000117 00 0 0 1

[23] .symtab SYMTAB 00000000 0350b0 009010 10 24 1646 4

[24] .strtab STRTAB 00000000 03e0c0 003dc8 00 0 0 1

[25] .shstrtab STRTAB 00000000 041e88 000132 00 0 0 1

Я загружаю следующие разделы в свой виртуальный флэш-образ: .isr_vector, .firmware_header_vector, .text, .exidx, .ARM.attributes, .init_array, .fini_array

Я заметил, что некоторые разделы имеют адреса 0. Возможно, некоторые из них просто добавлены во флэш-память?

1 Ответ

1 голос
/ 08 июня 2019

Дополнительные разделы, скорее всего, являются исходными данными для сегментов DATA. Код запуска большинства систем копирует содержимое в пространство ОЗУ, выделенное для этих сегментов. Таким образом устанавливаются статические переменные, инициализированные ненулевыми значениями.

Например, static int x = 23; должен дать вам сегмент с "23" в нем. Адрес этой «23» во флэш-памяти не является адресом x в оперативной памяти.

...