Здравствуйте, коллеги ARMатурщики.

Пришла нужда, сделал я, было, LPC2368/78 firmware upgrade (IAP+UART/IPMI) методом заливки Intel HEX файла и
интерпретации его на контроллере. По дороге заливщик/загрузчик вылавливает из HEX-потока стартовый
адрес (EPT) и хранит его вместе с дескриптором "upgrade"-кода во flash для последующих boot up.
Получаю HEX-файл с помощью IAR.

Ладно было дело, пока не заставила жизнь получить тот же HEX-файл с помощью Keil. Всё хорошо кроме одного:
не могу догадаться, где в полученном HEX-файле ловить EPT.

Если кто использует Intel HEX файл, полученный Keil, для прошивки fw upgrade, поделитесь, пож., опытом.

Спасибо.
---

В принципе можно чуть продолжить для порядка: форум я читал, следов ответа найти не удалось,
знаю, что EPT попадает в HEX-файл из LPC2300.s, только попадает в "шифрованном" компилятором виде,
а уж дизассемблер на контроллере делать - вовсе тухлое занятие.
Потому и совет хочется. (Идеальный совет - "правильный" LPC2300.s,- только кто его даст... )

Возьмите описание Intel HEX формата и реализуйте его ПОЛНОСТЬЮ. И настанет Вам счастье и независимость.

Смешно

Я знаю, что Вы любите больше давать советы, чем отвечать на вопросы. Спасибо, но тема не про то.
Intel HEX формат я давно "взял", реализовал "полностью" и оно даже работает.

Если у Вас есть сомнения или возражения (например, Вы знаете конструкцию HEX, описывающую EPT), не сочтите за
труд ткнуть меня туда носом явно, а не намёком.

Если Вы найдёте время и силы для написания совета без отсылки к "сделай сам", спасибо.

Ну это уже просто неприлично. См. тут: Wikipedia: Intel HEX
Внимательно смотрим на record type 03, record type 05.
А вообще можно зафиксировать точку входа и не париться.

Не 02 а 03

Я понимаю, что тема про моветон вечна и потому приведу для Вас специально
отрывок от HEX-файла имени Keil, о котором и тема (она - не про Википедию, как Вам показалось)


(секции с кодом "0" и "1" по понятным причинам опущены.)
Всё, других секций нету.

Так вот, Record Type 5 не имеет ничего общего с EPT, а Record Type 2 (и 3) в файле от Keil отсутствуют вовсе.
Возможно, проблема с проектом.

(для справки - огрызок от map-файла:
"Image Entry point : 0x0000016c" - стартовый адрес factory code (Image Validation &bootstrap). - он нам не нужен, его контроллер найдёт сам.
"main 0x00020035 Thumb Code" - очень похоже на то, что надо, но этот адрес есть только "зарытый" в виде индекса в инструкцию,
напоминающую branch(R0). Прошу прощения, я мнемонику ассемблера ещё на память не выучил всю ))
Это я к тому, что Rec type 5 не описывает EPT, да и наличие двух стартовых точек комментировать таки просто неприлично.

(PSPS)
К предположению об ошибке в проекте - скриншот. Подскажите, если знаете, пож., что там плохо и где.
Второй файл - тот самый HEX от Keil - для сомневающихся в моём утверждении. Rec Type 5 там не две, а примерно четыре.


Это я не понял. Разжуйте несчастному, как ея зафиксировать: возможно о том и плач.

Не знаю, что Вы за три буквы http://www.google.lv/search?client=opera&a...channel=suggest упорно твердите, но 3 или 5 это именно Start Address в одном из двух форматах 20 или линейном 32bit. Для ARM использование '3' странновато, но как-то встречал.

Решите для себя и хотя-бы попытайтесь объяснить кто это такая "ея".

Ея (старорусск) - её, стартовую точку то есть. Ея её предлагали зафиксировать.
Не хочется предполагать, что предлагали с помощью "дырявить" код.

Слово из трёх букв EPT в переводе с иностранного означает Entry Point (Table).
http://www.acronymattic.com/EPT.html
Это - не менее распространённое сокращение, чем RTFM.
(В первом посте перевод был уже дан, правда без ссылки)

Что касается Record Type 5, то он имеет отношение к Start Address для Intel x86, а в нашем случае (я файл выложил) указывает на начало
сегмента и к делу не относится, imho.
Вы, увы, не ссылаетесь на свой опыт. Гугль- не панацея, википедия - не кладезь.

Можете верить, можете не верить, мне все равно, но это он и есть.

Мой опыт простирается от использования Intel HEX формата со времен когда писал загрузчики с перфоленты в 8080 и до нынешнего времени, когда использую его-же для загрузки Firmware в ARM. Полегчало?

Ммм... Причём их четыре, да? По-моему не смешно.
Тут вопрос не столько в вере сколько в здравом смысле и в генерируемом коде.
Я абсолютно не сомневаюсь, что Вы знаете, о чём пишете (просто потому, что я читаю этот форум давно: пишу редко),
однако мне Keil не показывает стартовый адрес в (единственной, я надеюсь) RT5. Как его "уговорить" я пока не догадался.


А как же! Родственная душа, всегда приятно. Я впервые парсил Hex во времена до 8080. Такой программатор был, Intellec назывался.
Крутая машина, чисто импортная, жгла ПЗУшки 256*4 (для Intel3000), понимал Hex-формат.
А в какой ARM Вы грузите FW и чем HEX получаете?


(ЗЫ) Я начал тему с того, что всё сделал и всё получилось из-под IAR. Сейчас глянул - действительно там (в HEX от IAR) -единственная
запись Type 5, и в ней - правильная точка входа. Как-то всё "само" работало, и я просто не интересовался, а тут - нате Вам... Keil.
Его, Кейла, ругать нельзя, его многие любят. (Но что-то в тему пока не пишут) :-;

Не верю.

В LPC,ST,TI IAR/Keil/GCC

Это не программатор, это отладочная система. Программатор там среди прочего. Как и HEX формат в первую очередь создавался не для программаторов а для ЗАГРУЗЧИКОВ, посему адрес по которому передавать управление после загрузки вещь обязательнейшая.

Справедливо не верите, я плохо посчитал. Там их не четыре, а всего три. Файл - выше, о какой вере речь?


Я пользовал только программатор, о нём и написал. Да, это была пара стоек, в одной из них компьютер Hewlett Packard...

Собственно, спасибо Вам за труд и время. Надеюсь я был не слишком назойлив.
Доктор сказал: "в морг", значит - в морг. Если никто не подскажет как победить Keil, я напишу пост-процессор для HEX-файла, стирающий
лишние RT5 и внедряющий одну правильную. Коль нет автомата, поможет лопата.

я тоже первый раз слышу про EPT в данном контексте.
Причем здесь вообще таблица?
Используется понятие точка входа (entry point) без всяких таблиц, в данном случае.
И кстати типы записей 2 и 3 (с сегментами) я уже очень давно не встречал в HEX файлах.
А часть программ вообще с ними криво работает, особенно если сегменты перекрываются.

А если у вас в HEX файле несколько точек входа указано - значит проблема в исходниках.

Лингвистика сложна, ну её к Microsoft. (Это у них я научился называть точку входе EntryPoinT)
Table - обобщение. У контроллера LPC*subj это таки таблица. Таблица векторов прерываний. (Предлагаю измерение длины остановить и считать меня виноватым)


Возможно. Причём IAR этого не замечает, оба (IAR & Keil) через Jlink всё правильно заливают и отлаживают, и только Keil чего-то видит, но молчит и генерирует бессмысленный (если верить Вам и zltigo - а не верить тоже нехорошо) HEX-файл.
Вообще, я предпочитаю отделять вопросы религии от вопросов настройки проекта и багов-глюков инструментов.

Как, зачем компилятор (простите, скорее тут дело в линкере), будучи популярен и не убит молча генерирует три HEX записи типа 5?
Как исходные тексты, где нет и намёка на точку входа (кроме секретного слова "main") могут убивать компилятор линкер?
Простите эмоции. Желательна идея. Где, в каком месте проекта Keil я должен явно указать, что main() - точка входа?
Ну, или не main, а что-то другое (что, где)?

Наверное я слегка перегрелся и нуждаюсь в отдыхе с последующим чтением мануала от Кейл - чтоб он сдох был здоров.
У нас тут в Сибири уже 3 часа ночи, я пошёл спать. Завтра вернусь, всего вам.

Приложите лучше получившиеся scat и map. Галки и визарды - это всегда плохо.

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

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

Если базовый адрес сегмента (и, следовательно, точка входа) заранее известны, то зачем искать 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.
Я это умалчивал, чтоб не исчез интерес пишущих к теме и избежать совета потребовать от свышестоящих заменить среду разработки.
Такие дела.

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