Прошивки AT89S8252, как получить общий исполняемый файл прошивки? Опции

[Kofey Nik]

У AT89S8252 имеется прошивка внутренней флэш программ (8к) плюс внешняя ПЗУ (64к). Как получить целиковый файл исполняемой программы? По-идее, поскольку в таких случаях вначале исполняется внутренняя прошивка а потом вшнешняя, то надо наложить эти 8к на начало ПЗУ, но тогда исчезнут масса служебных строк, необходимых программе. А если состыковать файл ПЗУ в конец файла внутренней флэш, тогда размер прошивки превысит 64К - как процессору с 16-разрядной шиной адреса добраться до конца такой программы?

[Палыч]

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

Что значит "целиковый"? C какой целью Вы хотите получить такой файл?

По-идее, поскольку в таких случаях вначале исполняется внутренняя прошивка а потом вшнешняя...

Не обязательно в такой последовательности. При обращении по адресу бОльшем, чем максимальный адрес внутренней памяти программ, обращение производится к внешней памяти.

А если состыковать файл ПЗУ в конец файла внутренней флэш, тогда размер прошивки превысит 64К - как процессору с 16-разрядной шиной адреса добраться до конца такой программы?

Вполне возможно, что младшие 8К внешней памяти вовсе не используются... Тут уж - как построено ПО нужно смотреть...

Если - не секрет: что это за устройство такое?

[Kofey Nik]

Что значит "целиковый"? C какой целью Вы хотите получить такой файл?

Попробовать дизассемблировать - нужно исправить одно ограничение в прошивке. Опыт с 51-м был. Целостная прошивка - ну, в аппаратном виде носителей программы два, а мне нужно получить один непрерывный файл с непрерывным адресным пространством.

Не обязательно в такой последовательности. При обращении по адресу бОльшем, чем максимальный адрес внутренней памяти программ, обращение производится к внешней памяти.

Начиная с какого адреса во внешнем ПЗУ? Максимальный_адрес +1 ? Это я и имел в виду.

Вполне возможно, что младшие 8К внешней памяти вовсе не используются... Тут уж - как построено ПО нужно смотреть...

Первый байт равен 02 только во внутренней флэш, ПЗУ начинается с 20, следующий тоже 20 - это символы кодовой страницы ASCII - они нужны для работы программы, затенять их внутренней прошивкой чревато их исключением. Вот в чем проблема для меня.

если наложить внутреннее содержимое (из флэш) на первые 8К пространства внешнего ПЗУ программ, то при дизасе получается галиматья -

...
code:1FFA mov R6, #8
code:1FFC mov R1, #0x68 ; 'h' ; - после этой команды нет перехода на исполняемый код !!!
code:1FFC ; END OF FUNCTION CHUNK FOR start
code:1FFC ; ---------------------------------------------------------------------------
code:1FFE .byte 0x12
code:1FFF .byte 0x61 ; a
code:1FFF ; end of 'code'
code:1FFF
seg_01:00002000 ; ===========================================================================
seg_01:00002000
seg_01:00002000 ; Segment type: Pure code
seg_01:00002000 ;.segment seg_01
seg_01:00002000 ; .equ $, 0x2000
seg_01:00002000 ; START OF FUNCTION CHUNK FOR seg_01_4FC8
seg_01:00002000 seg_01_2000: .byte 0xFF
...


Сообщение отредактировал Kofey Nik - Apr 6 2011, 12:49

[Палыч]

Попробовать дизассемблировать - нужно исправить одно ограничение в прошивке. Опыт с 51-м был. Целостная прошивка - ну, в аппаратном виде носителей программы два, а мне нужно получить один непрерывный файл с непрерывным адресным пространством.

Э-э-э-э... Чего это вдруг - "с непрерывным адресным пространством"? В МК51 "адресных пространств" аж целых три штуки, и из них никак не получить одно непрерывное. При дизассемблировании нужно использовать два из них: дизасеммблибуются внутренняя flash и внешнее ПЗУ - каждое отдельно от другого, но с использованием результатов дизассемблирования другого...

если наложить внутреннее содержимое (из флэш) на первые 8К пространства внешнего ПЗУ программ, то при дизасе получается галиматья

Вовсе не обязательно, что выполнение программы плавно "перетечет" из внутренней flash во нешнее ПЗУ. Например, может быть, что во внешнем ПЗУ находится не исполняемый код, а некоторые данные (например, изображение, выводимое на некий экран), или набор процедур/подпрограмм, вызываемый из "основной" программы (программы, расположенной во внутренней flash).

Если подвести итог под вышесказанным: 1) необходимо дизассемблировать вначале прошивку внутренней flash, при этом обратить внимание на использование обращений к нешнему ПЗУ; 2) с учетом анализа дизассемблированного кода из п.1 произвести дизассемблирование прошивки внешнего ПЗУ.

Конечно, всё это с учетом замечания АНТОХИ

[Kofey Nik]

AHTOXA
Конечно же, ЕА=1. Не случайно же первый байт во флэш - команда стандарного для этих процессоров безусловного дальнего перехода ljmp (02h).

Э-э-э-э... Чего это вдруг - "с непрерывным адресным пространством"? В МК51 "адресных пространств" аж целых три штуки, и из них никак не получить одно непрерывное. При дизассемблировании нужно использовать два из них: дизасеммблибуются внутренняя flash и внешнее ПЗУ - каждое отдельно от другого, но с использованием результатов дизассемблирования другого...

Палыч, ну это же прописные истины, мне они ведомы. Я только не понял, как можно использовать результаты дизассемблирования одной прошивки для другой.
Для ядра микроконтроллера программа вместе с данными (получаемыми с помощью команды MOVC) представляет одно адресное пространство (если только не используется переключение между банками с помощью управляющих линий, но это совсем уж сложный случай, за такие я бы не взялся - там надо иметь поистине шахматическую память). В программе используются дальние переходы, которые могут быть физически быть из внутренней флэш во внутреннюю и наоборот. Вот его-то мне и надо получить, чтобы понять логику программы, чтобы исправить в нужных местах код.

Вовсе не обязательно, что выполнение программы плавно "перетечет" из внутренней flash во нешнее ПЗУ. Например, может быть, что во внешнем ПЗУ находится не исполняемый код, а некоторые данные (например, изображение, выводимое на некий экран), или набор процедур/подпрограмм, вызываемый из "основной" программы (программы, расположенной во внутренней flash).

Ну смотрите - если после команды

mov R1, #0x68

идет не следующая команда, а массив данных, этот код обрывается для процессора, и тогда он воспринимает данные за команды (например, байты 20 хх хх примет за код "JB имя_регистра адрес_ближнего_перехода"), в результате процессор просто стопорится или ресетится, дойдя до ситуации исключения.

Вот почему я был удивлен таким построением суммарной прошивки.

Если подвести итог под вышесказанным: 1) необходимо дизассемблировать вначале прошивку внутренней flash, при этом обратить внимание на использование обращений к нешнему ПЗУ; 2) с учетом анализа дизассемблированного кода из п.1 произвести дизассемблирование прошивки внешнего ПЗУ.

Обращения к данным можно просто отследить - для этого используется команда MOVX, если это не память программ, а в нашем случае это именно память программ (обращение в цикле получения команды по сигналу *PSEN). В том-то и дело, что во внешнем ПЗУ находится основной массив исполняемой программы устройства.

Сообщение отредактировал Kofey Nik - Apr 7 2011, 05:25

[Палыч]

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

На Вашем месте я бы получил хороший (в первом приближении) результат дизассемблирования прошивки внутренней flash (уж не знаю, что Вы для этого используете - рекомендую IDA - можно уточнять процесс дизассемблирования по мере понимания организации вычислительного процесса и размещения/назначения данных). По результату дизассемблирования внутренней flash определить исходные данные для дизассемблирования внешнего ПЗУ: адреса подпрограмм, данных, сруктура данных и т.п., и уже потом дизассемблировать внешнюю прошивку. Анализ внешней прошивки, возможно, уточнит что-то для понимания внутренней, и так - по кругу до полного понимания...

Ну смотрите - если после команды ... идет не следующая команда, а массив данных...

Вы должны понимать, что дизассемблеры, если что-то делают в автоматическом режиме, то не всегда верно! Вполне возможно, что команда, которую Вы привели в качестве примера, и не команда вовсе, а часть неких данных/констант - используемый Вами дизассемблер мог банально не разобраться с видом информации...

Обращения к данным можно просто отследить - для этого используется команда MOVX, если это не память программ, а в нашем случае это именно память программ (обращение в цикле получения команды по сигналу *PSEN). В том-то и дело, что во внешнем ПЗУ находится основной массив исполняемой программы устройства.

Данные из внешней памяти можно получить и командой movc
Последнее же Ваше заявление о программе во внешнем ПЗУ - голословно, поскольку Вы не имеете сколько нибудь приемлемого результата дизассемблирования внутренней flash. Или на сигнал PSEN смотрели, и там строго в каждом цикле обращение?

[Kofey Nik]

На Вашем месте я бы получил хороший (в первом приближении) результат дизассемблирования прошивки внутренней flash (уж не знаю, что Вы для этого используете - рекомендую IDA - можно уточнять процесс дизассемблирования по мере понимания организации вычислительного процесса и размещения/назначения данных). По результату дизассемблирования внутренней flash определить исходные данные для дизассемблирования внешнего ПЗУ: адреса подпрограмм, данных, сруктура данных и т.п., и уже потом дизассемблировать внешнюю прошивку. Анализ внешней прошивки, возможно, уточнит что-то для понимания внутренней, и так - по кругу до полного понимания...

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

Вы должны понимать, что дизассемблеры, если что-то делают в автоматическом режиме, то не всегда верно! Вполне возможно, что команда, которую Вы привели в качестве примера, и не команда вовсе, а часть неких данных/констант - используемый Вами дизассемблер мог банально не разобраться с видом информации...

Нет, код совершенно логически корректный, в нем используется в том числе команда lcall code_12E0, подпрограмма которой корректна, завершается командой ret, и на нее имеются ссылки из других фрагментов программы флэш с аналогичными инициализирующими параметрами. Это точно не данные, это код.
Кроме того, в последнем фрагменте кода флэш идет вызов подпрограмм по адресам 61AE и 61FF, которые физически располагаются во другом носителе программного кода (внешнем ПЗУ).

Последнее же Ваше заявление о программе во внешнем ПЗУ - голословно, поскольку Вы не имеете сколько нибудь приемлемого результата дизассемблирования внутренней flash. Или на сигнал PSEN смотрели, и там строго в каждом цикле обращение?

Слушайте, давайте не будем делать из меня наивного человека, который только вчера занялся цифровой схемотехникой. Системная плата вовсе не случайно имеет внешнее ПЗУ с подсоединением PSEN, кроме того аппарат просто не может работать в объеме программы 8 килобайт - это ему на один зуб не хватит. если уж так важны дополнительные доказательства, то уверяю Вас, выборка команд по формированию PSEN происходит регулярно.

Сообщение отредактировал Kofey Nik - Apr 7 2011, 07:14