Как сделать, чтобы в среде IAR контрольная сумма считалась не до конца флеш или сегмента CODE, а только непосредственно до конца программы (до последнего байта программы)?

В простейшем случае приходит в голову следующий алгоритм.
1. В командном файле линкера установить сегмент CHECKSUM не в конце адресного пространства CODE, а в конце приложения (= вместо #).
2. Собрать приложение и в map файле посмотреть где заканчивается приложение. Скорректировать стороку в командном файле линкера , т. е. вместо _..X_FLASH_END указать реальный адрес окончания приложения.

PS при пересборке нужно сначала восстановить максимальное значение, а потом снова вписать реальное.

Каким образом можно решить проблему подсчета контрольной суммы прошивки, если код написан в кейле? Там такой фишки как в яре к сожалению нет. Каким сторонним инструментом можно воспользоваться, чтобы узнать CRC фирмвари?

ИМХО, если действительно нужно иметь CRC прошивки, то проще написать свой инструмент и запускать его из bat-файла в post-linker.

Ну, или записывать вручную только для релизов.

недавно приперло и написал утилиту для подсчета всевозможных CRC и КС для бинарных файлов.
Толком не тестировал в полном объеме. Если кому пригодится, выкладываю.
Ежели что, пишите о замеченных несоответствиях, лучше в аську.
За корявый английский в хелпе тоже прошу прощения.

Нажмите для просмотра прикрепленного файла

Спасибо, большое! Попробую воспользоваться.

Планируется ли портирование под Linux? ЗЫ Ну пожааалуйста...

А для каких целей то нужна эта контрольная сумма?
А то тот же md5 вполне многие пользуют.
man md5sum

Да я под виндой то пишу только когда припрёт.
Мне уж проще спортировать на микроконтроллер какой
Могу просто выложить исходник, портируйте сами.



Так это для MD5, а надо бывает всевозможные CRC и просто варианты арифметических сумм.
Ту же утилиту, что я привел, можно использовать, к примеру, для подсчета КС векторов прерывания для LPC-шных АРМов, можно из мейкфайла запустить последовательно дважды, в первый раз подсчитать и сохранить КС векторов, а второй раз - CRC всего файла, и сохранить в файле же в нужном адресе.

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

Не ново, конечно, но мой вариант был таков:
1. Имелась двухконтроллерная система на LPC. Был мастер и слэйв МК. Моя часть проекта - слэйв.
2. Для предоставления мастеру (и другому программисту) я генерил в IAR bin-файл с заполнением до конца прошивки 0xFF (контроллер всего 32К был)
3. В xcl-файле прописал адрес, в который IAR должен был помещать CRC16.
4. В итоге я мог из своего кода всегда прочитать по этому адресу CRC и мастер так же мог убедиться в том, что слэйв требует обновления ПО (плюс по соседним адресам располагалась версия ПО).

vesago
Для бутлоадеров использовал свою отдельную прогу, которая "подписывала" контрольной суммой полученную от IAR прошивку.

Подниму тему).
Пролиставая доку STM32 наткнулся на модуль CRC.
Раньше, работая с 51контроллерами, всегда проверял контр.сумму флеша в начале программы. Т.к. ИД была Кейл, то приходилось пользоваться конвертерами ХЕКС<->БИН и колькулятором CRC, кот. вставлял её в конечный файл прошивки.
Ну и вопрос, собственно,: Кто и как проверяет CRC программы? Как на практике применить модуль CRC, при проверке целостности кода?
PS: желательно, относительно работы в Кейле.

По причине отличия встроенного алгоритма от известного CRC-32, расчёт ведётся по одному слову, каждое из которых изменяется, как и результат.
Потому же не получилось использовать готовую функцию CRC_CalcBlockCRC.
описание проблемы и метод решения


Ещё и данные этой функции надо скармливать по 32 бита. В результате отказался от этого модуля и применил программный расчёт с википедии.

Сам я этот аппаратный калькулятор CRC не ковырял, но заявленный полином совпадает с тем, который используется при генерации CRC-32 программой SRecord. Поэтому можно при помощи SRecord добавлять CRC к прошивке и попробовать разные варианты генерации CRC аппаратным калькулятором, пока значения не совпадут. Там можно менять начальное значение CRC, делать инверсию результата, и, возможно, в разном порядке скармливать данные (MSB или LSB first, хотя могу и ошибаться). Короче, придётся повозиться.
Но вообще с трудом представляю, где может понадобиться аппаратный калькулятор CRC. Обычно программный калькулятор достатотчно быстрый и компактный.

Ну, мы пользуем аппаратный CRC32: зарядил DMA по буферу, а ядро спать отправил - экономия батареек, однако

Как то задавал вопросы по этой теме, потом сам все сделал сам. Аппаратный расчет CRC32 у контроллера куда быстрее программного (даже табличного), в теме тыс
Сообщение #9 выложены исходники как применить. Пользуюсь по сей день.

В CortexM3 нет аппаратной проверки CRC кода, в отличие от ARM7, или я не прав?

Этой штуки нет ни в Cortex-M3, ни в ARM7. Зато она присутствует в STM32.

Очень нужен порт под линукс, если возможно поделитесь исходником

и ещё вопрос: она работает с форматом Intel?

Если в проекте включить Use MicroLIB, то весь подсчет коту под хвост.