LPC 2366 проблема в ISP, Не получается перезаписать начальные адреса Flash Опции

[lavrik]

Здравствуйте форумчане! Прошу помочь, т.к. уже не знаю что делать...

Пишу внутрисистемный (ISP) программатор для LPC 2366, и столкнулся с тем, что в процессе прошивки не получается стереть полностью весь флэш, адреса с 0x00 по 0x40 зарезервированы под вектора прерываний. При форматировании всего флэша посредством ISP-команды "E 0 14\r\n" в этом диапазоне остается что-то, все остальное как и положено - FF.

Согласно hex-файлу прошивки, которую я пытаюсь туда записать, в этом диапазоне должны находиться определённые данные, которые туда не записываются.

Вот то что надо записать в формате Intel HEX, адрес предшествует данным.


Вот как выглядит флэш после полного форматирования:


Вот что я пытаюсь записать из оперативной памяти во флэш по адресу 0x0:


Во флэше по указанному адресу это появляется в следующем искаженном виде:



Что скажете?

[Golikov A.]

Уже было тут недавно про не стираемое начало флеши на LPC
У вас ножка бут подтянута на штатную загрузку? тогда получается что у вас начальный регион должен на загрузчик быть замаплен, вроде как... не это ли у вас тут происходит?

[KRS]

Пишу внутрисистемный (ISP) программатор для LPC 2366,

у большинства LPC есть такая багафича в бутлоадере - по умолчанию 64 байта отмаплены на BOOT ROM. родному бутлоадеру этот мапинг не нужен, но и на flash он почему то его мапит только если вход в бутлоадер не произведен, для запуска пользовательской программы. Поэтому все программаторы в начале грузят и запускают код в озу, который записью в регистр мапит flash. Это достаточно сделать один раз, конечно если врублена защита в начале придется всю флешь стереть.
Непонятно почему NXP до сих пор не поправил это поведение. Например в LPC11C14 вообще бред получается - если войти в UART бутлоадер флешь на месте, а если в CAN - нет!

[Golikov A.]

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

[KRS]

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

Нет! у NXP при включении питания или по ресету всегда отмаплен загрузчик, первыми командами он отключает возможность отладки у NXP ARM7 чисто софтовая защита, потом проверяет можно ли включить отладку, потом проверяет ногу для запуска загрузчика по UART, если в загрузчик входить не надо мапит флешь и запускает пользовательскую программу.
Кстати это надо учитывать при отладке - и обходить место отключения ног отладчика в ARM7 если есть необходимость шагать с самого запуска (на самом деле после ресета отладчиком). Для cortex -ов я не разбирался как защита устроена, но схема очень похожа, не разбирался только как они блокируют возможность подключения по SWD пока ресет активен.

Так вот мапинг bootrom нужен только что бы стартовал загрузчик, загрузчик не использует прерывания и больше не обращается по 0ым адресам. По хорошему после старта надо мапить флешь, все равно загрузчик ее мапит перед запуском пользовательской программы и почему бы это не делать сразу непонятно. И в LPC11C14, например это происходит, но почему только для UART. в LPC17xx не происходит, там тоже надо всегда запускать программу.

Но это все надо делать только если хочется проверить запись флеша или считать его. Запись, стирание будет корректно и без мапинга.
По идее это - ближе к баге! Т.к. в даташитах расписан ISP - в частности команда чтения и нигде не указано что надо что то мапить!!! И родной бутлоадер без костылей не обеспечивает ее работу. А про костыли NXP умалчивает.

[Golikov A.]

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

[jcxz]

Но это все надо делать только если хочется проверить запись флеша или считать его. Запись, стирание будет корректно и без мапинга.
По идее это - ближе к баге! Т.к. в даташитах расписан ISP - в частности команда чтения и нигде не указано что надо что то мапить!!! И родной бутлоадер без костылей не обеспечивает ее работу. А про костыли NXP умалчивает.

Что-то странное Вы говорите....
Уже много лет пользуем в своих устройствах LPC2378. Прошиваем и стираем его FlashMagic-ом. В том числе и 0-сектор. И вроде проблем с этим никогда не было (если конечно P2.10 в нужном положении при снятии RESET).
И как Вы с ISP что-то отмапите? Это-же не IAP. ISP выполняет ROM-код он и должен рулить мапингом при необходимости.

[Golikov A.]

Вот и мне так кажется...

Единственное что я сейчас подумал, а как проверить что в 0 сектор флеши записано? если на чтение замаплин бутлоадер?

[Сергей Борщ]

Единственное что я сейчас подумал, а как проверить что в 0 сектор флеши записано? если на чтение замаплин бутлоадер?

Теоретически, в ISP есть команда Blank check sector(s) <sector number> <end sector number>. Если она вдруг будет сравнивать с отраженными векторами загрузчика - бомбить письмами техподдержку. Они английским по белому в руководстве пользователя обещали, что сравниваться будет именно с флеш.

[Палыч]

ТС знает ли о существовании CRP (Code Read Protection) ?

[Golikov A.]

Blank check

Не что-то вы обманываете

UM10601 (первый какой нашел)

This command is used to blank check one or more sectors of on-chip flash memory.
Blank check on sector 0 always fails as first 64 bytes are re-mapped to flash
boot block.
When CRP is enabled, the blank check command returns 0 for the offset and value
of sectors which are not blank. Blank sectors are correctly reported irrespective of
the CRP setting.

Или же когда он будет выкидывать не совпавший контекст он весь сектор выкинет с правильными данными? Да еще игнорируя CRP?

Интересно как FlashMagic проверяет целостность записи прошивки...

а для 1768 уже такая приписка к этой функции пропала...

[Сергей Борщ]

Не что-то вы обманываете

Да, виноват, не дочитал

[lavrik]

ТС знает ли о существовании CRP (Code Read Protection) ?

Спасибо за быстрый отклик! Сейчас уточню некоторые моменты, т.к. вижу что это необходимо.

Если верить даташиту, то CRP включается следующим образом:


По указанному адресу при залитой прошивке лежит следующее:


Когда отсылаю в ISP "E 0 14 \r\n" то это место как и положено записывается FF FF FF FF.

В ISP я же вхожу зажиманием P2.10 на "0", потом последовательно "0" и "1" на RESET, затем "1" на P2.10 и начинаю отсылать стандартные команды ISP-бутлоадера.

Хотелось бы услышать следующее: важны ли эти самые первые 64 байта? если важны, то как их туда записать?

Если надо могу написать всю последовательность высылаемых команд.

P.S. Еще такой вопрос возник по ходу дела: это нормально, что после сброса в оперативной памяти с самого начала лежит какой-то мусор?

UPD Вспомнил: когда поторшил HEX прошивки в конце нашел такую запись:

:04 0000 05 00000234 C1, что мною было интерпретировано после гугла как "Линейный адрес старта: начало программы по адресу 0x00000234." Это имеет какое-то отношение к проблеме?

Сообщение отредактировал lavrik - Mar 26 2015, 11:10

[Golikov A.]

чудно однако....

ведь FlashMagic реально сначала пишет, потом проверяет... может Campare читает из пользовательской флеши?

[KRS]

Что-то странное Вы говорите....
Уже много лет пользуем в своих устройствах LPC2378. Прошиваем и стираем его FlashMagic-ом. В том числе и 0-сектор. И вроде проблем с этим никогда не было (если конечно P2.10 в нужном положении при снятии RESET).
И как Вы с ISP что-то отмапите? Это-же не IAP. ISP выполняет ROM-код он и должен рулить мапингом при необходимости.

Вот подключитесь снифером и посмотрите! FlashMagic грузит в озу программу и запускает ее! Эта программа мапит флешь на адрес 0! И только после этого все проверки работают!

Я с самого появления АРМ еще у Philips работаю с ними, когда еще и баги в бутлоадере были, которые позволяли защищенный флешь читать

CRP начинает действовать только после перезагрузки и фактически это всего лишь отключение ног отладчика! И запрет бутлоадеру выполнять определенные команды.

Хотелось бы услышать следующее: важны ли эти самые первые 64 байта? если важны, то как их туда записать?

Записать их не проблема!
Они запишутся! Проблема с чтением и проверкой, что бы это с работало надо загрузиь в ОЗУ и выполнить простую подпрограмму которая запишет регистр и отмапит флешь на адрес 0! Все это делается с помощью команд бутлоадера. Это можно сделать сразу после подключения если CRP не было или сразу после стирания...

Еще важно не забыть посчитать контрольную сумму векторов прерываний, не все тулчаины ее при сборке рассчитывают, если ее не будет программа не будет запускаться чип в бутлоадер будет переходить!

[KRS]

Это-же не IAP. ISP выполняет ROM-код он и должен рулить мапингом при необходимости.

Должен, но он этого не делает!
Все программаторы, если они хотят счтитать или проверить первые 64 байта флеша, при помощи команд ISP грузят в ОЗУ подпрограмму которая мапит флеш на адрес 0! После этого все работает как ожидается.

Да и кстати это, по крайней мере не у всех серий, не ROM - а флешь. У первых серий это вообще была последняя страница флеша. Для некоторых серий NXP выкладывал апгрейд бутлоадера.

[jcxz]

Все программаторы, если они хотят счтитать или проверить первые 64 байта флеша, при помощи команд ISP грузят в ОЗУ подпрограмму которая мапит флеш на адрес 0! После этого все работает как ожидается.

Ну что-ж - вполне правдоподобно. Значит ТС может сделать то же самое.

[KRS]

Кроме того если нужно ускорить прошивку. можно загрузить в ОЗУ подпрограмму которая принимает данные из UART по другому протоколу - например просто принимает напр 4 кб данных и возвращает контрольную сумму для проверки и возвращается в бутлоадер, а программатор потом вызывает команду записи флеша, потом опять подпрограмму загрузки для следующей старницы и т.д.
Причем подпрограмму можно грузить один раз ни бутлоадер ни IAP не портят память, они используют те области которые указаны в даташите.

Ускорение полезно для больших прошивок, особенно когда к чипу через USBUART идет подключение.

[lavrik]

Ну что-ж - вполне правдоподобно. Значит ТС может сделать то же самое.

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

[KRS]

загрузить в ОЗУ, например по адресу
0x40000200
24 байта
(0x0C, 0x00, 0x9F, 0xE5, 0x01, 0x10, 0xA0, 0xE3, 0x00, 0x10, 0x80, 0xE5, 0x0E, 0xE0, 0x81, 0xE1, 0x1E, 0xFF, 0x2F, 0xE1, 0x40, 0xC0, 0x1F, 0xE0,)

Потом дать бутлоадеру команду
"G 1073742336 A"

код этот не очень "красивый", взят ЕМНИП снифером из первого филисовского программатора.

Код

     LDR     R0, =0xE01FC040  
     MOV     R1, #1            
     STR     R1, [R0]          
     ORR     LR, R1, LR        
     BX      LR

но тут оптимизации не к чему Работает вроде на всех LPC2xxx.

[jcxz]

но тут оптимизации не к чему Работает вроде на всех LPC2xxx.

На всех, у которых ROM-код исполняется в Thumb. :-)

ЗЫ: Его можно оптимизировать по размеру, переписав в Thumb. :-)

[KRS]

На всех, у которых ROM-код исполняется в Thumb. :-)

ЗЫ: Его можно оптимизировать по размеру, переписав в Thumb. :-)

А у всех LPC ARM7 boot код в THUMB, а что IAP (который часть boot rom) в THUMB - так явно в даташите указано.

Инструкция
ORR LR, R1, LR
лишняя, если конечно в какой то версии бутлоадера не было баги в реализации команды G.

А так можно смело в THUMB запускать, кстати удобно тесты железа запускать еще до прошивки.

[lavrik]

Спасибо всем огромное! В очередной раз форумчане выручают начинающего чайника!)

[lavrik]

Думал что на этом эпопея закончится, ан нет...

Новый виток: перед тем как шиться выполняю из оперативной памяти код, который скинул форумчанин KRS, получаю всю память в FF как и желаю, пишу первый блок в 256 байт, он записывается как положено, потом дописываю все остальное (всего чуть больше килобайта). Записываемая программа должна моргать диодом с периодом в 1-2 секунды. Что происходит по окончании прошивки: диод начинает моргать циклично, но период увеличен раз так в 10-20, и после выключения-включения питания первые 64 байта опять переписываются как им удобно и код перестает работать.

Что здесь можно предпринять?

[KRS]

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

Именно переписываются? Или все таки это бутлоадер туда отмаплен?

Контрольная сумма векторов прерываний посчитана?

[Golikov A.]

Надо отпустить ногу бута.

[lavrik]

Надо отпустить ногу бута.

Порт 2.10? Отпущен.

[KRS]

Если контрольная сумма векторов прерываний не посчитана, чип будет переходить в бутлоадер в любом случае!

[lavrik]

Именно переписываются? Или все таки это бутлоадер туда отмаплен?

Контрольная сумма векторов прерываний посчитана?

Я думал, что в готовой прошивке все должно быть посчитано....

Вот что в даташите написано по этому поводу


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

[KRS]

При записи по 0 адресу:

Код

        uint32_t s;
        s=((uint32_t*)buf)[0]+
            ((uint32_t*)buf)[1]+
            ((uint32_t*)buf)[2]+
            ((uint32_t*)buf)[3]+
            ((uint32_t*)buf)[4]+
            //((uint32_t*)buf)[5]+ !!skip!!
            ((uint32_t*)buf)[6]+
            ((uint32_t*)buf)[7];
        ((uint32_t*)buf)[5]=-s;

[Golikov A.]

а записать ее надо в серединку таблицы прерываний в адрес 0х14 если от нуля
UPD, не заметил ее там уже пихают в 5 ячейку

[lavrik]

При записи по 0 адресу:

Код

        uint32_t s;
        s=((uint32_t*)buf)[0]+
            ((uint32_t*)buf)[1]+
            ((uint32_t*)buf)[2]+
            ((uint32_t*)buf)[3]+
            ((uint32_t*)buf)[4]+
            //((uint32_t*)buf)[5]+ !!skip!!
            ((uint32_t*)buf)[6]+
            ((uint32_t*)buf)[7];
        ((uint32_t*)buf)[5]=-s;

пока что не очень понятно....

[KRS]

пока что не очень понятно....

Я не знаю "архитектуру" Вашего программатора, но логично предположить...
что есть функция которая записывает блок флеша, на вход подаются данные и адрес, так вот если адрес = 0, buf - указатель на данные надо перед отправкой данных вставить этот код.

[lavrik]

Там же возможна запись из ОЗУ во Flash только блоками по 256 байт минимум...и это ограничение от NXP

[KRS]

Там же возможна запись из ОЗУ во Flash только блоками по 256 байт минимум...и это ограничение от NXP

Да все равной какой размер! Главное что первый блок будет больше 32 байт и перед передачей его в ОЗУ для записи надо вставить этот код, который заменит одно слово.

[Golikov A.]

В вашей прошивке в начале лежит таблица прерываний, в 0x14 - это 5 ячейка если ее мерить 32 битными словами, должна лежать контрольная сумма этой таблицы, такая что сумма по всей таблице должна давать 0.

То есть после того как вы получили файл прошивки, с ним выполняете указанные действия считаете сумму всей таблицы кроме 5 ячейки. И отрицательное значение записываете в 5 ячейку, таким образом сумма по всей таблице станет 0. После этого такую поправленную прошивку пихаете во флэш и все будет!

[jcxz]

Там же возможна запись из ОЗУ во Flash только блоками по 256 байт минимум...и это ограничение от NXP

В LPC17xx минимум == 16 байт. Скорей всего в LPC23xx так же.

[Golikov A.]

да не в размере дело, а в том что надо поправить 4 байта с адреса 0х14 в прошивке, это надо сделать еще до записи всей прошивки, так что абсолютно не важно какими блоками потом ее записывать...

[KRS]

В LPC17xx минимум == 16 байт. Скорей всего в LPC23xx так же.

флеш 128 битный с ECC поэтому меньше 16 байт = 128 бит нельзя.
Но это только если Вы умеете сами писать. Через документированное API нельзя! И в LPC17xx тоже

[Golikov A.]

так же как нельзя писать в не стертую флэшь (если мы конечно хотим верных в ней данных) потому дописать ничего не получиться, надо писать с 1 раза.

[jcxz]

Но это только если Вы умеете сами писать. Через документированное API нельзя! И в LPC17xx тоже

Можно. Если предварительно считать страничку. У меня так даже журналы (с размером записей кратным 16 байт) в эту флешь пишутся.

так же как нельзя писать в не стертую флэшь (если мы конечно хотим верных в ней данных) потому дописать ничего не получиться, надо писать с 1 раза.

Можно дописывать. Только элементами выровненными по границам 16-байтных кусочков.

[Golikov A.]

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

[den_po]

Можно. Если предварительно считать страничку. У меня так даже журналы (с размером записей кратным 16 байт) в эту флешь пишутся.

Одно время столкнулся с проблемой на LPC2368: когда дописывал таким образом, иногда получал случайно запорченные данные по соседству.

[jcxz]

Одно время столкнулся с проблемой на LPC2368: когда дописывал таким образом, иногда получал случайно запорченные данные по соседству.

Писали невыровненные на 16 байт данные.

[KRS]

Можно. Если предварительно считать страничку.

да в общем можно и не считывать, а просто заполнить FF, кроме нужных 16 байт, может в таком случае и писать быстрее будет.

Только вот способ не гарантированный, теоретически NXP может поменять технологию флеша.

[jcxz]

Только вот способ не гарантированный, теоретически NXP может поменять технологию флеша.

Вряд-ли. Так как у самой NXP есть какой-то AN где так и советуют делать.

[den_po]

Писали невыровненные на 16 байт данные.

Нет, точно выровненные

[Сергей Борщ]

А я заставил линкер gcc считать контрольную сумму. Убил двух зайцев - нет описанных выше проблем с дополнительной обработкой прошивки и программа работает после загрузки отладчиком (OpenOCD), который про контрольную сумму векторов ничего не знает и считать не умеет.

[jcxz]

Нет, точно выровненные

Возможно в LPC23xx были какие-то проблемы. На LPC1758/68 у меня уже в нескольких проектах ведутся журналы во внутренней флешь таким образом. И никаких проблем.

[KRS]

А я заставил линкер gcc считать контрольную сумму.

А у Вас названия обработчиков прерываний фиксированные?
Или в скрипте линкера всетаки как то можно получить доступ к данным по определенному адресу...

[lavrik]

В вашей прошивке в начале лежит таблица прерываний, в 0x14 - это 5 ячейка если ее мерить 32 битными словами, должна лежать контрольная сумма этой таблицы, такая что сумма по всей таблице должна давать 0.

То есть после того как вы получили файл прошивки, с ним выполняете указанные действия считаете сумму всей таблицы кроме 5 ячейки. И отрицательное значение записываете в 5 ячейку, таким образом сумма по всей таблице станет 0. После этого такую поправленную прошивку пихаете во флэш и все будет!

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



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

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

[KRS]

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

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

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

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

[Сергей Борщ]

А у Вас названия обработчиков прерываний фиксированные?

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

[lavrik]

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


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

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

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

[Сергей Борщ]

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

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

Код

        .section .vectors,"ax"
        .global _start
        .code 32
_start:
        LDR     PC, reset_addr      // Reset
        LDR     PC, undef_addr      // Undefined instruction
        LDR     PC, swi_addr        // Software interrupt
        LDR     PC, pabort_addr     // Prefetch abort
        LDR     PC, dabort_addr     // Data abort
        .word   0 - (5 * 0xE59FF018 + 0xE51FFFF0 + 0xE59FF010)
        LDR     PC, [PC, #-0xFF0]   // Read vector address from VIC
        LDR     PC, fiq_addr        // FIQ interrupt
reset_addr:
        .word reset_handler
undef_addr:
        .word undef_handler
swi_addr:
        .word swi_handler
pabort_addr:
        .word prefetch_abort_handler
dabort_addr:
        .word data_abort_handler
fiq_addr:
        .word fiq_handler
        .ltorg

Добавлено:

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

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

[lavrik]

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

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

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

Сообщение отредактировал IgorKossak - Apr 9 2015, 16:48

Причина редактирования: избыточное цитирование

[lavrik]

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


506E20B9

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

[Obam]

Так как написано в 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."

[KRS]

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

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

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

[Golikov A.]

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

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

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

[lavrik]

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

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

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

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

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

[jcxz]

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

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

[Golikov A.]

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

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

[Сергей Борщ]

но никто не мешает сделать переход на один адрес из 2-х и более векторов

Вы хотели сказать - использовать одну и ту же константу адреса для всех команд перехода из векторов? Экономия на спичках. выиграть максимум четыре слова программного кода, которые гораздо проще отыграть где-то в остальной программе.

или расположить код сразу за таблицей ISR, сделав переход обычным B.

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

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

[lavrik]

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

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

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

Такие пироги

[jcxz]

Вы хотели сказать - использовать одну и ту же константу адреса для всех команд перехода из векторов? Экономия на спичках. выиграть максимум четыре слова программного кода, которые гораздо проще отыграть где-то в остальной программе.

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

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

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

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

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

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

[Сергей Борщ]

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

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

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

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

[IgorKossak]

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

[jcxz]

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

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

[KRS]

а потом инвертировать....

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

Использовать не косвенный переход (LDR), а прямой - B.

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

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

[Golikov A.]

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