ну вектора исключений то у LPC23xx располагаются строго по фиксированному адресу.


так отладка стартует все равно по Reset вектору.
A iar просто по умолчанию брекпоинт на main ставит. (в опциях run to main)



ну main то уж точно точкой входа не может быть!
точка входа обычно в библиотеке находится, там стек инитится, сегменты и т.п.

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


Да, причём этот вектор указывает на boot loader. Он, boot loader, всё "инитит", что может,
проверяет валидность "настоящей" области векторов и передаёт туда управление.

IAR генерирует первую инструкцию, исполняемую после ResetVector, -
"B __iar_program_start" - переход в область update кода - то, что нужно.

Keil - делает что-то другое, там участвует выше упомянутый ("от Бога" даденный) файл lpc2300.s
На этом глубина моего познания Keil заканчивается и начинается мель проблем.

Внутренний голос мне уже подсказывает, что вы (команда уделивших внимание теме) сказали
достаточно полезных слов, чтоб я "дожал" проблему до внятного результата.
Тема, однако, пока не закрыта и если кто (например, aaarrr) сможет/захочет чего добавить,
упростить мне задачу - заранее спасибо.

Ваш проект имеет два load region'а, с адресами 0x00 и 0x20000. HEX получился совершенно корректный - двумя кусками с этими адресами. Так какие претензии к Keil'у?

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

Региона - да- два, а вот кусков в HEX-файле три. (правда, между вторым и третьим нет дырки)
Претензия к Кейлу - в том, что *каждый* из трёх HEX-кусков сопровождается RecType5. Нужны только RecType4.
RecType5 должен быть единственным - описывающим адрес старта.

А пепел сыплю голова потому, что моё предположение о том, что код должен *работать* было, похоже, ошибочным.
Нужно генерировать Update код целиком в Update сегменте, тогда стартовый адрес совпадёт с базовым адресом сегмента и
один из трёх RecType5 имени Keil укажет на него.
(Как бы ещё гуманно выбрать из трёх наилучший? По наибольшей похожести на "ноль"?)

Однако такой код запустить из-под uVision IDE и пройти "по шагам" едва ли получится.
Пожелание к Кейлу есть. Указать бы как-то стартовый адрес, отличный от базового адреса сегмента.
Тогда описанное неудобство исчезнет.

Спасибо, Ваш комментарий добавил уверенности в том, что нет грубого промаха в проекте.

Сообщение отредактировал svss - Jun 17 2011, 09:27

Если базовый адрес сегмента (и, следовательно, точка входа) заранее известны, то зачем искать RecType5, который его сообщит?


Получится. Отладчик uVision умеет много такого, о чём вы и не догадываетесь. Посказка: см. тут.

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

Ну так я и агитирую за вариант, при котором у подменяемого приложения точка входа была в самом младшем адресе двоичного образа. Тогда нет нужды искать эту точку в формате HEX. В конце концов, на загружаемый образ накладываются и иные требования (прежде всего разрешённый диапазон адресов, неплохо ещё добавить поле размера и контрольной суммы), так что фиксация точки входа не сильно затруднит.
Кроме того, есть интересная "уязвимость" формата Intel HEX, ведь в нём могут быть повторяющиеся или перекрывающиеся записи, а также записи с обратным порядком адресов. Так что должна быть гарантия, что файл прошивки пришёл из добросовестного источника, либо защита от дурака и/или хулигана.

Ну и делайте в startup, все, что душа пожелает. Но в общем это не проблема. Сдается мне, что вы своими руками изобразили какую-то кашу из загрузчиков-ядер-приложений в ОДНОМ, а не разных проектах и теперь думаете а чего это оно получилось-то такое????

Ну так заливаете шифрованные. Я в HEX лью обычно только вторичный загрузчик. Дальше работает он. Заливку в HEX он тоже поддерживает, если очень попросить, но с контролем адресов - себя затереть не даст.

Спасибо, у меня уже давно всё работает :-) Это я топикстартеру забот накидываю, чтобы не расслаблялся :-)

Хороший вопрос. (Правда я на него неявно ответил выше)
Действительно искать не нужно, если код отлажен и его не нужно ходить по шагам.
Иначе стартовый адрес, как известно, всегда равен нулю, а точку входа нужно искать самому,
либо уговорить Keil поместить нужное в RecType5.

(Спасиб за ссылк.)


Да, это дело.
Правда и у меня уже всё работает.

Тему можно было бы считать закрытой, но остался один вопрос, заданный в самом начале темы относительно
"правильного" lpc2300.s файла для Update кода. В случае его применения Update код можно отлаживать по
шагам.
Следуем правилу: "спросил-не ответили-ответь сам"

lpc2300_update.s

Лично я ни то, что спросили и уж тем более ни то, что Вы сами себе ответили зачем-то напрочь изуродовав startup, как минимум, вынеся из него всю инициализацию не понял. Ну да ладно.

Правильно будет настроить стек и кучу, а затем перейти на __main. То что вы привели не есть правильно, хотя при определенных условиях работоспособно.

Спасибо.
Я здесь же отвечу и zltigo.
Правильно ли, нет ли писать максимум кода на C, оставляя ассемблера не более, чем обойтись нельзя, наверное, спорить смысла нет.
Нельзя обойтись числом ассемблерных инструкций, меньшим одной.

То, что код из одной ассемблерной инструкции уродлив я предлагаю считать частным мнением автора высказывания,
зато он позволяет с помощью Keil получать результат эквивалентный IAR.

Тут нелишне пожаловаться на судьбу и на рок в лице заказывающего музЫку и объяснить, что я всюду имел в виду Keil 3.0.
Я это умалчивал, чтоб не исчез интерес пишущих к теме и избежать совета потребовать от свышестоящих заменить среду разработки.
Такие дела.

Нихрена, простите, Вы не поняли. И что творите не ведаете. Счастливо оставаться.