Если была такая тема, то хотелось бы ссылку увидеть, поиск мне выдал добрые два десятка страниц.

Сейчас разбираюсь в загрузчике и есть вопрос по поводу контрольной суммы бинарного файла, скомпилированного в Keil'е. Где она хранится и какой алгоритм расчёта? Где можно почитать на эту тему?

Нет никакой контрольной суммы. Хотите её - лепите сами.

У кортексов М, есть контрольная сумма векторов прерываний, храниться где то в середине таблицы прерываний, является суммой самой таблице по 16 бит, кажется. Смотрите описание. А так в общем смысле суммы нет, как сделаете так и будет, куда положите там и возьмете

Это не у кортексов, а у NXP LPC. У них заводской загрузчик какую-то контрольную сумму считает. Процессор сам по себе здесь ни при чём.

"…у NXP LPC…" которые 7TDMI

Да? ну тоды ой%) помню что читал на arm.com, сейчас зашел, а там и правда про специфику LPC пишут

Такой суммы не может быть в принципе. Ибо только программист знает, где у него началась программа и где она закончилась. Где у него будет свой загрузчик, где будет приложение, где будут храниться настройки и что из этого ему нужно обложить контрольной суммой.

Не смотря на все вышеизложенное, в составе утилит того-же IAR (а раньше это делал линкер) есть утилита позволяющая генерить по заданным алгоритмам контрольные суммы и размещать их - IELFTOOL (IAR ELF Tool). И помнится все это из binutils растет? Я правда ей не пользусь, в отличие от линкера 4.x версий, поскольку в 5.x она была уродлива, но сейчас может подправили.

У меня это вызывает недоумение. Есть же srec_cat, он всё умеет. Наверное, если бы они про него знали, то не стали бы изобретать этот велосипед.

Нет, это СОВСЕМ разные утилиты. srecord нифига не знает ни о структуре прошивки ни об именах переменных. Поросто абстрактная работа с образом.
Так-что зря Вы про велосипед

Мне эта абстрактная утилита позволяет с успехом вставлять куда надо и размер прошивки, и контрольную сумму. Так что о переменных не тужу :-)

Только вот "куда надо" надо рукам указывать и только по фикированному адресу, как и области, которые подлежат контролю. Да и выбор алгоритмов из стандартных. Я как-бы тоже своей утилитой делаю, но тем неменее и iELFtool отдаю должное.

да такую программу написать - максимум пол-дня. Как надо так и будет считать и записывать.

Но она кладет туда, куда укажет программист. Контрольной суммы, которую компилятор кладет куда-то сам, нет.

Ну что "куда-то сам", я не утверждал. Но в общем-то на самом деле в определенном смысле и это так - кладет ПО ИМЕНИ ПЕРЕМЕННОЙ, котрую да, "укажет программист". А если, эта переменная будет ну где-нибудь в стартапе полученным вместе с компилятором, и которой большинство и в глаза не видели, то это будет "программист" или "компилятор" ?

- объявляем например в файле main.c

const int crc __attribute__((at(0x800)));

пусть у нас до адреса 0х800 будет загрузчик,а с этого адреса будет программа
- редактируем файл 1.ini (этот файл вне проекта и к нему никак не относится) Пусть у нас к примеру,адрес конца Flash-памяти нашего микроконтроллера 0х1000. также CRC считаем по простенькому алгоритму исключающего или,хотя можно запрограммировать и реальный crc32

map 0x800,0x800 read write

FUNC void calc_crc(void)
{
int i;
crc=0;
for(i=0x804;i<0x1000;i+=4)
crc^=_RDWORD(i);
}

calc_crc()

- подключаем этот файл 1.ini заходим в меню keil-a
"project-options fo target....-вкладка debug-поле initialization file" открываем этот файл
ну собственно говоря,компилируем,загружаем,наслаждаемся

Можно проконтролировать это дело-ввести в watch-окно отладчика переменную crc и проверить...

а результат нигде по 800 адресу сохранить не надо?

Так написано же всё

...
crc=0;
...
crc^=...

проглядел, const int crc __attribute__((at(0x800)));

В симуляторе прокатит, а насчет камня не уверен. Поскольку при загрузке HEX значение будет не определено.А последующая модернизация ПЗУ вещь специфическая. И даже если это прокатит, то такую прошивку можно зашивать только через KEIL и только с использованием данного ini-файла, что подходит только для разовой работы или мелкой серии.
Кроме того, если программа начинается с адреса 0x800, то хранить там CRC - преступление.Убивается точка входа в программу.

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

Да,еще один нюанс- наткнулся в помощи кейла на следующее,т.н. "Cortex-M signature" (меню Help->uvision help->вкладка СОДЕРЖАНИЕ->"книга" uvision user's guide->utilites->Signature Creator for NXP Cortex-M Devices)
Может быть это то,что нам и надо?

Гораздо проще настроить в КЕЙЛе проект так, чтоб после сборки запускалась утилита (хоть srecord, хоть самопал, хоть набор утилит из cmd-файла), которая будет пересчитывать CRC у созданного HEX файла.

Не знаю, проще ли, но логичнее. Запускаю после компиляции сначала преобразование в bin файл, а потом свою программу, которая для вычисляет CRC, размер файла, шифрует его...