Приветствую Уважаемые!
Есть дизассемблированный код процессора pic18ф4620/2620, пытаюсь собрать исходник обратно с помощью МПЛАБ IDE МPASMWIN, чтобы потихоньку разбираться что к чему и как работает.
Естественно вылазит куча ошибок.
Самая распространенная это Error[126] 32273 : Argument out of range (8423 not between FC00 and 03FF). В коде данных строк стоит переход BRA 720.
Про команду эту почитал, и вроде метка есть L720. Но ругается я так понимаю на диапазон. Как узнать почему ?
Та же ошибка, только тут уже не нравиться RCALL
L1903 RCALL 987
NOP
BRA L1850
BRA L1851
NOP
NOP
BNC L1852.

и еще

Error[126] 27724 : Argument out of range (9FF8 not between 0000 and FFFF) // CALL 0x0F9FF8,FAST
Error[126] 27769 : Argument out of range (D29A not between 0000 and FFFF) // GOTO 0x1ED29A


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

https://mega.nz/#!FMZlGLzZ!EtARv8iv...7F1VN1M4MkJKPFA

Сам код.

Встроенные в IDE дизассемблеры, как правило, не обладают хорошим интеллектом, поэтому спотыкаются об секции с данными, таблицами и тому подобным. И начинают дизассемблировать данные как код. Ессно получается лабуда.
Тут нужно или глазами эти куски смотреть, или применять сторонние интерактивные дизассемблеры.

Тут использовался не встроенный в МПЛАБ дизассемблер, с ним многие говорят что код получается нормальный, ничего подобного. Для дизассемблера использовался не он, как раз сторонний.

IDA. Посмотрите, возможно есть PIC.
Более удобного софта не встречалось.

А лучше (в 99% случаев, как мне представляется), проще, надежнее и дешевле - нанять специалиста, который напишет программу для этого ПИКа заново, с нуля. Идея с дизассемблированием и последующей перекомпиляцией крайне неудачна, ИМХО. Если, конечно, речь не идет о простейшем проекте вроде светодиодной мигалки ...

А в этом случае тем более проще с нуля написать. Чем ковыряться в много-десятко-килобайтной инициализации чего-нить посредством PICо-HALа, в которой потеряется само мигание на пару десятков команд.

Посмотрел листинг. Всего - около 500 страниц текста. Если убрать NOP - примерно 250.
Если есть возможность выделить код и данные, а также обработчики прерывания, возможно удастся сократить еще в несколько раз.
Ошибки могут лезть по причине "отработки" дизассемблера по участку данных, строк-литералов. Естественно, получается бредо-код.
Поэтому сперва просмотрите хотябы bin-образ прошивки в символьном виде напредмет нахождения литералов. В ASM этот блок пометьте как массив данных.
---------
Возиться с этим имеет смысл, если проект изначально писан на ASM и прикладная задача нетривиальная.
Если это код С(++) то лучше переписать.
ТС, какая прикладная задача прошивки ?

Да без разницы.
Любой дизассемблер не умеет отличать области кода от данных, таблиц и т.п.

В этом все и дело, сам код без проблем компилируется, а вот блок данных нет, именно в нем ошибки и идут. Как их вернуть в исходное или рабочее состояние. Код написан на АСМе, с данными там вообще не понятка, т.к если смотреть по IDA то видно слова типа "Подключение к БД", Меню и т д... Соответственно без данных программа включается, но не работает как надо и соотвественно 20% кода который компилируется в hex получается лажой.

литералы смотрите в FAR. По адресу или смещению находите эти блоки в IDA (или в вашем исходнике ASM) и помечаете их как данные.
Если литералы не видны - возможно юникод.
Если строки сишные - терминатор 0x00.
Компилируете свой ASM.
Из hex-модуля преобразуете в bin-образ памяти флеш.
Сверяете длину "нового" bin-образа с "старым"/исходным-образцом.
Если длина одинаковая - делаете побайтное сравнение fc f_new.bin f_old.bin /b >bin_log.txt
Если совпало - "правка" нового асм-файла корректна. Идем далее.
Если не совпало - смотрим в каком месте и что не совпадает.
и т д,, получаем удовольствие от процесса

Помнится проделывал подобное для 51 МК.
В принципе, выше вкратце уже сказали.
Единственно что, данные не обязательно являются текстом, а если являются, то вряд ли в МК будет юникод.
А собственно для чего Вам это надо?
У меня тогда стояла задача дополнить старт устройства дополнительной фичей.
Поэтому, немного разобравшись с программой (по дизасму), сделал в самом начале переход на конец программы (где было свободное место) и там уже написАл необходимую вставку с возвратом в точку перехода.
Дальше уже более для интереса, нашёл куски текста, указал дизасму адреса, дизассэмблировал.
Опять засунул в ИДЕ (точнее не весь, а только обновлённые куски, так как по ходу в листинге менял названия меток и добавлял коментарии), стал анализировать программу и находить блоки данных.
По-новой в дизасм и т.д.
Периодически, после изменений АСМа, компилировал в BIN и сверял с исходным (пользовался вот программкой Dronf).
И, да! Удовольствие получил обалденное.

Чтобы что-то дополнить нужно исходник иметь, для этого и делается, плюс для себя поразбираться в коде. Просто хочется сделать готовый исход, который можно будет править и добавлять в него. В Hex новое не запихнешь Данные то понятно они там есть точно, в сам процесс вникнуть не могу пока. Как данные пометить ? Нашел, да данные и текст даже есть, но не везде. Теперь как мне перенести все это правильно в компилируемый проект?
Под литералами что понимается? Сами данные. Вопросов больше чем ответов У меня вообще такое чувство что там типа базы данных. Либо вывод какой-то на дисплей, терминал. Чего изначально нет.
Может тут есть люди которые шарят в этом и могут подсказать как и что. Код на ассемблере был написал.

(1) изучаете ASM для Вашего процессора + сам проц., распределение памяти, портов, адреса векторов прерывания итд.
для абстрактного процессора - примерно так

(2) литерал - набор символов, как правило "читабельных" для вывода на экран, передачи на терминал итп.
Расположены в памяти последовательно, кодировки символов могут быть разные. "закрывающего" последнего символа может не быть (а может быть).
Литерал, за последним символом которого расположен код 00 - это "сишная" строка. (для 1-байтовых символов ASCII)
(3) Если для Вас приемлем (1) и будете отвечать на вопросы, а не "кодироваться".

В системе команд PIC18 (как и других PIC-ов) под литералом понимается константа в поле команды.
То есть в команде movlw 0x5C константа 0x5C является литералом. Отсюда и аббревиатура самой команды move literal to working register.

По поводу дизассемблирования.
Автоматические дизасмы - полная фигня. Для восстановления исходника на АСМе из бинарника требуется только текстовая декомпиляция и ПОНИМАНИЕ ФУНКЦИОНАЛА исследуемого прибора. Ну и знание архитектуры МК, естественно.

Как то у меня оказался утерянным последний исходник под dsPIC33, но остался экземпляр живого устройства с открытой прошивкой и исходник предыдущей прошивки. Строк кода - около 3000. Изменения касались лишь примерно 5 % исходника (по сравнению с предыдущим). Я пахал как папа Карло примерно 2 недели. Восстановил, но имена пары флагов так и остались бессмысленными. Примерно понимаю функционал, но сил и времени на эти флаги уже не осталось. Плюнул и оставил их как есть - безымянными.
Это я к тому, что даже свой собственный код с полным пониманием что куда и откуда декомпилировать крайне сложно и долго.
Порой гораздо проще и полезнее написать заново.

Перечитал определение из "кладезя мудрости". Если в "двух словах" - различные константы в исходном коде.
(ониже, - в машинных кодах команд). Бинарные константы "смотреть" в дампе достаточно проблематично,
а вот символьные и строковые - вполне комфортно. Поэтому я начинаю "разбор" с них.
Затем - удобно выделять константы во флеш формата float'32 (например массивы, таблицы достаточно легко идентифицировать).
Лично мне (почему-то) литералами бинарные значения float как-то называть некомфортно. Но это - уже психоанализ

Разбор обычно начинают с КОМАНД, а не с полей констант. Тем более, что таблицы констант в ассемблере PIC18 могут быть оформлены и как табличное чтение и как функция команды retlw <const>. Если последний вариант дизассемблируется достаточно очевидно (там нечего искать, достаточно начального адреса стандартного блока с retlw), то вариант с табличным чтением программного флеша совершенно неопределенное занятие без разбора адресующего эту таблицу кода. Ибо при побайтной упаковке таблицы во флеш эта таблица ничем от исполняемого кода внешне не отличается.

Под "разбором" с литералами-константами подразумевал следующее.
После получения "сырого" листинга disasm первоочередная задача - сократить его длину, убирая "бредо-код", соответствующий различным данным.
Самое простое - это просмотреть дамп бинарника в символьном виде и диапазоны адресов, которые явно не являются кодом, например строки для LCD,
определить в исходнике асм как DB. Если использовать IDA - значительную часть этой работы выполняется (полу)автоматически.
Процесс творческий и итерационный. У каждого процессора - свои ньюансы.

Извините, но Вы - жертва стереотипов.
С чего Вы взяли, что строки для LCD будут обязательно определены как DB?
Элементарно и целесообразно их определять как DW.
Но дело даже не в этом. Я не понимаю чем поможет восстановлению исходника отделение полей констант. Ну отделили, и что?
И LCD может быть графическим, и упаковка графики не иметь формата экрана, а состоять из примитивов...
Опять же главное в восстановлении исходника - восстановление глобального алгоритма, а так же выделение основных функций этого алгоритма.
Поэтому начинать надо с выделения main, то есть участка общей инициализации и главного цикла (суперлупа). И из функций вызываемых этим циклом развернуть остальной код.
А где будут константы, - укажут команды табличного чтения. Это элементарно и определяется В САМОМ КОНЦЕ реверсинжиниринга.

Не исключаю. Позволю себя процитировать Поскольку Вы хорошо знаете платформу (PIC), а я - нет (последние 5 лет "сижу" на MSP430) - Вы правы.
Да и ТС выкладывать прошивку не пожелал . . .