откуда ж я знал что там 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 так не делает, говорит только или о его низком качестве или о том что он слишком универсальный.

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