То есть в это место записать контрольную сумму?

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

Как получить отрицательное значение? Просто инвертировать?

По поводу сколько копировать можно из ОЗУ во Флэш: в даташите разрешены следующие размеры данных
Нажмите для просмотра прикрепленного файла

там выделено больше 4 байт.
Надо писать слово по адресу 0x14


Инвертировать и прибавить 1

Сейчас посмотрел - это я на Cortex имени LPC считал линкером. И там названия обработчиков да, фиксированные. А на ARM7 вообще не вижу проблемы - там области векторов всегда лежит один и тот же кусок кода, его контрольная сумма - константа, которую можно посчитать вручную и прибить в соответствующее место гвоздями.

точно, случайно выделил 8 байт

В моем случае я суммирую 18F09FE5 5 раз и получаю 7CB31F79. Если инвертировать то получится 834CE087. Соответственно, в 0x0000 0014 нужно записать 834CE088?

Как раз сегодня решаю такую задачу. Вот что получилось:


Добавлено:

"Машина должна работать, а человек - думать" (принцип IBM). Поручите расчет компилятору. Машина железная, ей считать нетрудно и она никогда не ошибается.

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

UPD: А обязательно вся прошивка должна писаться за один заход в ISP?

Появился сдвиг! Я сделал следующее: прошил через Keil и JTAG проект, из которого был взят HEX и затем посмотрел содержимое памяти по адресу 0x14. Было обнаружено следующее:
Нажмите для просмотра прикрепленного файла

506E20B9

Когда я эту сумму записал в свою тестовую прошивку - все заработало как следует. Значит, рассчитанная мной в предыдущих постах чек-сумма (834CE088) была посчитана по неправильному алгоритму. Вопрос: как считать правильно?

Так как написано в User Manual:

"…Criterion for valid user code: The reserved ARM interrupt vector location (0x0000 0014) should contain the 2’s complement of
the check-sum of the remaining interrupt vectors. This causes the checksum of all of the vectors together to be 0."

Нет! все совсем не верно!!

-(0xE59FF018*6+0xE51FF120) = 0xB9206E50

надо сложить не 5 значений!
а всю таблицу векторов, то есть 8 значений (c 0 gj 7), но пропустить 5 слово.
а потом инвертировать....

Вам надо сделать так, чтобы сумма первых 8 чисел (32 битных чисел) в итоге давала 0. Вот и рассчитайте какое там должно стоять число чтобы после суммирования стало 0.

очевидно что это сумма всех кроме 5 числа, взятая со знаком минус, суммирование без знаковое. Ну и надо не забывать что данные в памяти лежат в формате LittleEnadian то есть с младшего конца
то есть если в памяти лежит 0x11 0x22 0x33 0x44, то это число 0x44332211

откуда ж я знал что там Little Endian...

спасибо! теперь все стало на свои места!

Чаще всего, но не всегда. Чаще всего там конечно набор из LDR PC, [PC, #24], но никто не мешает сделать переход на один адрес из 2-х и более векторов или расположить код сразу за таблицей ISR, сделав переход обычным B.

Чем более вероятно событие - тем оно менее информативно, так что еще можно вопрошать "откуда же я знал что там Big Endian?", но обратное стыдно. Наиболее понятный и удобный формат для техники процессоров именно LittleEndian и если это не так об этом пишут ОГРОМНЫМИ БУКВАМИ!

Вы хотели сказать - использовать одну и ту же константу адреса для всех команд перехода из векторов? Экономия на спичках. выиграть максимум четыре слова программного кода, которые гораздо проще отыграть где-то в остальной программе.
Каждый сам себе злобный Буратина. Или приведенный простой кусочек кода, который решает проблему контрольной суммы и делает программу чуть короче и быстрее, либо выдумываем себе трудность и героически ее преодолеваем. Имея на выходе результат заведомо худший, потому что добавляется один лишний переход здесь и какое-то дополнительное количество кода на чтение VIC_ADDRESS и дальнейшее ветвление по нему. Я не вижу абсолютно никакого смысла в этих лишних движениях в программе, кроме как сделать из маленькой быстрой программы большую медленную.

В общем, обсуждавшуюся три страницы задачу я для себе решил минимальными усилиями. Кому не нравится - пусть делает лучше.

Этот процесс (подсчета и перезаписи контрольной суммы векторов прерываний) будет автоматизирован при помощи софта, который будет подготавливать прошивку, переводя её из традиционного HEX-вида в необходимый и удобный для записи + ещё будет шифроваться ключом AES (пока не решили какой битности). Дешифровка прошивки будет производиться в программаторе, который будет знать ключ шифрования, программатор будет защищён от чтения.

Такие пироги

Использовать не косвенный переход (LDR), а прямой - B. И выиграть не байты, а такты. Что в таких местах (прерывания) может быть очень актуально.
Мне случалось писать ISR с частотами до единиц МГц. Там каждый такт на счету.

Да и тут вроде разговор о прошивке сторонней программы посредством ISR. А как в той программе описана таблица векторов - заранее не известно я так понимаю.


Что помешает злоумышленнику воткнуться сниффером между вашим программатором и прошиваемым устройством и перехватить прошивку?


Какой лишний переход??? ISR располагаем сразу за таблицей прерываний, никакой VIC_ADDRESS не нужен (один источник прерывания).
Разработчики ARM7/9 видели смысл создать даже отдельный FIQ со своим контекстом только для того, чтобы как можно лучше минимизировать затраты времени на вход/выход в ISR.
А Вы не видите...
Для FIQ вообще всё шоколадно - вообще никакой B даже не нужен - ISR для него сразу с вектора можно расположить, сдвинув вниз все остальные адреса.

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

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

Обычно - да, но бывают исключения
Платформа выбирается под задачу, но вот задача сама имеет свойство меняться (разрастаться) в по ходу жизни изделия.

не инвертировать!
нужно дополнение до двух, а не до еденицы


Кроме IRQ где сразу из VIC грузится так и делаю!
у LPC не так много флеша что бы 23 бита смещения не достали.

А то что стандартный startup так не делает, говорит только или о его низком качестве или о том что он слишком универсальный.

под инвертировать имел ввиду, конечно, инверсию знака, блин как это правильно то называется? Отрицательнить взять со знаком минус, вот. Так правильнее...