Метценгерштейн 0 29 марта Опубликовано 29 марта · Жалоба 2 minutes ago, aaarrr said: Потому что содержимое hash.o волшебным образом превратилось в RW. объявление выше привел. Оно const. Что делаем? 3 minutes ago, aaarrr said: Смешно, но это оно на volatile так реагирует. убрать этот volatile? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 63 29 марта Опубликовано 29 марта · Жалоба 1 minute ago, Метценгерштейн said: убрать этот volatile? Тогда нельзя будет пользоваться содержимым хеша из программы. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Метценгерштейн 0 29 марта Опубликовано 29 марта · Жалоба 1 minute ago, aaarrr said: Тогда нельзя будет пользоваться содержимым хеша из программы. Почему? Кто знает что там хеш? Там конст массив. Он для программы не изменяется. Volatile не нужен программе Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Метценгерштейн 0 29 марта Опубликовано 29 марта · Жалоба убрал volatile но прошивка такая же. Массив в том же месте- не уехал вниз. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 63 29 марта Опубликовано 29 марта · Жалоба 24 minutes ago, Метценгерштейн said: Он для программы не изменяется. Volatile не нужен программе В том-то и дело, что компилятор считает его неизменным, и вправе провести оптимизацию на основании своих представлений о содержимом. Это тот случай, когда volatile нужен. 11 minutes ago, Метценгерштейн said: Массив в том же месте- не уехал вниз. Верните hash_section в конец региона загрузки. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Метценгерштейн 0 29 марта Опубликовано 29 марта · Жалоба 8 minutes ago, aaarrr said: Верните hash_section в конец региона загрузки. можете уточнить? в скатере? вот сейчас он такой: LR_IROM1 0x00000000 { ; load region size_region ER_IROM1 0x00000000 { ; load address = execution address *.o (NUC_INIT, +First) *(InRoot$$Sections) .ANY (+RO) *.o (hash_section, +last) } RW_RAM1 +0 { ; RW_RAM1 start address is after ER_ROM1 (было + 0 в оригинале) .ANY (+RW +ZI) } } Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 29 марта Опубликовано 29 марта · Жалоба 10 минут назад, aaarrr сказал: В том-то и дело, что компилятор считает его неизменным, и вправе провести оптимизацию на основании своих представлений о содержимом. Это тот случай, когда volatile нужен. Достаточно передать указатель на этот массив в ассемблерную функцию (где-нибудь вызываемую естественно) и можно не беспокоиться, что оптимизатор создаст её копии и можно обойтись без volatile. Указатель на этот массив в си-шные функции лучше тоже передавать через ассемблерную прослойку. Костыль конечно, но не тяжёлый. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Метценгерштейн 0 29 марта Опубликовано 29 марта · Жалоба 5 minutes ago, jcxz said: Достаточно передать указатель на этот массив в ассемблерную функцию (где-нибудь вызываемую естественно) и можно не беспокоиться, что оптимизатор создаст её копии и можно обойтись без volatile. Указатель на этот массив в си-шные функции лучше тоже передавать через ассемблерную прослойку. Костыль конечно, но не тяжёлый. не решает задачу. RO становится, но массив все равно не в конце бин файла расположен. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 29 марта Опубликовано 29 марта · Жалоба 12 минут назад, Метценгерштейн сказал: не решает задачу. RO становится, но массив все равно не в конце бин файла расположен. Я вообще-то говорил о способе избавиться от необходимости volitile, а не о размещении. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 63 29 марта Опубликовано 29 марта · Жалоба LR_IROM1 0x00000000 { ; load region size_region ER_IROM1 0x00000000 { ; load address = execution address *.o (NUC_INIT, +First) *(InRoot$$Sections) .ANY (+RO) } RW_RAM1 +0 { ; RW_RAM1 start address is after ER_ROM1 (было + 0 в оригинале) .ANY (+RW +ZI) } ER_IROM2 +0 { *.o (hash_section, +last) } } Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Метценгерштейн 0 29 марта Опубликовано 29 марта · Жалоба да, в конце: вот он уже в мап файле разместился после RAM сектора Тогда в принципе, да, отлично. Еще раз спасибо всем! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Метценгерштейн 0 4 апреля Опубликовано 4 апреля · Жалоба On 3/29/2024 at 4:54 PM, aaarrr said: LR_IROM1 0x00000000 { ; load region size_region ER_IROM1 0x00000000 { ; load address = execution address *.o (NUC_INIT, +First) *(InRoot$$Sections) .ANY (+RO) } RW_RAM1 +0 { ; RW_RAM1 start address is after ER_ROM1 (было + 0 в оригинале) .ANY (+RW +ZI) } ER_IROM2 +0 { *.o (hash_section, +last) } } Так сработало, в конце прошивки размещен массив: Но вот в коде я его прочитать не могу. Само содержание памяти по этому адресу содержит нули. Вся прошивка при старте загружена в ОЗУ, содержимое совпадает, кроме этого куска. Как сделать чтобы и этот массив подгружался в ОЗУ? Сам массив объявлен так: #include <stdio.h> const volatile unsigned char fw_hash[32]; static unsigned char const volatile fw_hash[32] __attribute__((section("hash_section"), used)) = {94,94,94,94,95,94,94,94,94,94,94,94,94,94,94,94,94,94,94,94,94,94,94,94,94,94,94,94,94,94,94,94}; Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 63 4 апреля Опубликовано 4 апреля · Жалоба 2 hours ago, Метценгерштейн said: Вся прошивка при старте загружена в ОЗУ, содержимое совпадает, кроме этого куска. Как-то очень странно. Можете map приложить? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Метценгерштейн 0 4 апреля Опубликовано 4 апреля · Жалоба ============================================================================== Memory Map of the image Image Entry point : 0x00000000 Load Region LR_IROM1 (Base: 0x00000000, Size: 0x0001e5dc, Max: 0xffffffff, ABSOLUTE) Execution Region ER_IROM1 (Exec base: 0x00000000, Load base: 0x00000000, Size: 0x0001e054, Max: 0xffffffff, ABSOLUTE) Exec Addr Load Addr Size Type Attr Idx E Section Name Object 0x00000000 0x00000000 0x000000fc Code RO 692 * NUC_INIT startup.o 0x000000fc 0x000000fc 0x00000008 Code RO 977 * !!!main c_5.l(__main.o) 0x00000104 0x00000104 0x0000003c Code RO 1207 !!!scatter c_5.l(__scatter.o) 0x0001df2c 0x0001df2c 0x0000004f Data RO 323 .conststring ehci_iso.o 0x0001df7b 0x0001df7b 0x00000001 PAD 0x0001df7c 0x0001df7c 0x00000095 Data RO 434 .conststring support.o 0x0001e011 0x0001e011 0x00000003 PAD 0x0001e014 0x0001e014 0x00000040 Data RO 1203 Region$$Table anon$$obj.o Execution Region RW_RAM1 (Exec base: 0x0001e054, Load base: 0x0001e054, Size: 0x00075004, Max: 0xffffffff, ABSOLUTE) Exec Addr Load Addr Size Type Attr Idx E Section Name Object 0x0001e054 0x0001e054 0x00000018 Data RW 3 .data heap_2.o 0x0001e06c 0x0001e06c 0x00000004 Data RW 55 .data port.o 0x0001e070 0x0001e070 0x0000003c Data RW 126 .data tasks.o 0x0001e0ac 0x0001e0ac 0x00000003 Data RW 160 .data ff.o 0x0001e0af 0x0001e0af 0x00000001 PAD 0x00092efc - 0x00000018 Zero RW 739 .bss descriptors.o 0x00092f14 - 0x000000e4 Zero RW 934 .bss c_5.l(rand.o) 0x00092ff8 - 0x00000060 Zero RW 1070 .bss c_5.l(libspace.o) Execution Region ER_IROM2 (Exec base: 0x00093058, Load base: 0x0001e5bc, Size: 0x00000020, Max: 0xffffffff, ABSOLUTE) Exec Addr Load Addr Size Type Attr Idx E Section Name Object 0x00093058 0x0001e5bc 0x00000020 Data RW 683 hash_section hash.o ============================================================================== Image component sizes Code (inc. data) RO Data RW Data ZI Data Debug Object Name 64 8 0 0 0 537 check_firmware.o три куска подряд идут с мапа Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 63 4 апреля Опубликовано 4 апреля · Жалоба И по адресу 0x93058 нули? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться