Есть достаточна большая программа. Вся программа работает из внешнего ОЗУ. Грузится bootloaderom из внешнего ПЗУ. Вначале программы есть модуль проверяющий корректность программы. Он подсчитывает CRC всей программы (находящуюся в ОЗУ) и сверяет с заранее установленным значением. Все переменные находятся вне прошивки, и поэтому не влияют на подсчёт. В старых версиях IAR (4…) всё работало прекрасно. Но поставил версию 5.1 и на тебе, CRC всё время не совпадает. Начал копать и выкопал что, во всей прошивке меняется один адрес (4 байта), находящийся по адресу 0x34. Посмотрел ассемблерный текст, а по этому адресу такая строка:

Я нигде в программе не использую этот адрес. В настройках линкера никаких checksum не задействовано. Пытался найти, что за зараза туда лезет в дебагере, но ничего не вышло. Приходится пропускать большие аппаратно зависимые участки кода, а в месте программы, где в железе уже есть изменения этого адреса, в дебагере нет изменений. Господа, какие будут мысли?

ИАР может добавлять в код какие-то свои идентификаторы, пару байтов. Я когда-то на это натыкался, но посколько это ни на что не влияло, не разбирался.

Да в моём случае это влияет на подсчёт CRC. Прикол в том, что если я по этому адрессу размещу данные, то они затираются!

А это случайно не контрольная сумма для LPCxxxx?

Нет.
В LPC контрольная сумма, находится по адресу 0x14. Кроме того IAR в выходной файл эту сумму не сохраняет, это делает загрузчик при прошивке флеша.

Процессор SHARP LH525. Вообще странное явление. Анализировл эту переменную, так при старте программы(несколько функций после main), она меняест своё значение, покрайней мере 2 раза. А если бы прога не из RAM, а из flash выполнялась, тогда что?

icf в студию. И раз уж отладxиком залезли, то не вижу проблем в локализации команды, модифицирующей память. Именно память, а не переменную, так как линкер никогда в .intvec переменную не поместит.

/*###ICF### Section handled by ICF editor, don't touch! ****/
/*-Editor annotation file-*/
/* IcfEditorFile="$TOOLKIT_DIR$\config\ide\IcfEditor\a_v1_0.xml" */
/*-Specials-*/
define symbol __ICFEDIT_intvec_start__ = 0x0;
/*-Memory Regions-*/
define symbol __ICFEDIT_region_ROM_start__ = 0x44;
define symbol __ICFEDIT_region_ROM_end__ = 0xFFFFF;
define symbol __ICFEDIT_region_RAM_start__ = 0x100000;
define symbol __ICFEDIT_region_RAM_end__ = 0x900000;
/*-Sizes-*/
define symbol __ICFEDIT_size_cstack__ = 0x1000;
define symbol __ICFEDIT_size_svcstack__ = 0x100;
define symbol __ICFEDIT_size_irqstack__ = 0x400;
define symbol __ICFEDIT_size_fiqstack__ = 0x400;
define symbol __ICFEDIT_size_undstack__ = 0x100;
define symbol __ICFEDIT_size_abtstack__ = 0x100;
define symbol __ICFEDIT_size_heap__ = 0x8000;
/**** End of ICF editor section. ###ICF###*/


define memory mem with size = 4G;
define region ROM_region = mem:[from __ICFEDIT_region_ROM_start__ to __ICFEDIT_region_ROM_end__];
define region RAM_region = mem:[from __ICFEDIT_region_RAM_start__ to __ICFEDIT_region_RAM_end__];

define block CSTACK with alignment = 8, size = __ICFEDIT_size_cstack__ { };
define block SVC_STACK with alignment = 8, size = __ICFEDIT_size_svcstack__ { };
define block IRQ_STACK with alignment = 8, size = __ICFEDIT_size_irqstack__ { };
define block FIQ_STACK with alignment = 8, size = __ICFEDIT_size_fiqstack__ { };
define block UND_STACK with alignment = 8, size = __ICFEDIT_size_undstack__ { };
define block ABT_STACK with alignment = 8, size = __ICFEDIT_size_abtstack__ { };
define block HEAP with alignment = 8, size = __ICFEDIT_size_heap__ { };

initialize by copy { readwrite };
do not initialize { section .noinit };

place at address mem:__ICFEDIT_intvec_start__ { readonly section .intvec };

place in ROM_region { readonly };
place in RAM_region { readwrite,
block CSTACK, block SVC_STACK, block IRQ_STACK, block FIQ_STACK,
block UND_STACK, block ABT_STACK, block HEAP} ;

Ну я мог бы ещё предположить, что это пользовательский код (т.е. мой) изменяет этот адрес. Но я никогда не пользовался этим адресом. Насторожило и то, что по этому адресу, IAR-овский коментарий "Reservid adres".

"Reservid adres" как раз понятно почему. Если откроешь стартап с таблицей векторов прерываний, то увидишь, что между Data abort и IRQ нет одного вектора, а это как раз 0x34. В icf вроде все в порядке. Кроме как поймать в отладчике вариантов не вижу. Чудес не бывает. Если до main память дошла неизмененная, то дальше только косяки программы. Кстати, не совсем понятно зачем программа проверяет свою цнлостность? Разве это не дело загрузчика? Хотя это и не отменяет поиск барабашки!

Только адрес у него, не 0x34, а 0x14

Ну да, вы правы. Вектор действительно 0x14. По нему команда ldr pc,[pc,#24], а по адресу 0x34 собственно адрес функции-обработчика. Так IAR-вский стартап устроен. Я как раз это и подразумевал - не думал, что надо разжевывать очевидное.

Как раз в IAR стартапе, этот адрес пропущен! что видно в исходниках от 5.xx

Чего? Кто пропущен? А по какому адресу в вашем примере будет IRQ_Addr: DCD IRQ_Handler ?

В примерах из состава IAR 5.11 этих стартапов больше сотни. Все немного разные. Вы какой-то нетипичный нашли. Вот другой пример: