Всем салют! Есть нетривиальная задача: существенная часть RO данных выгружена во внешнюю память. Для справки, это псевдографические меню и строковые литералы (типа const char []), которые юзер видит, когда коннектиться к железяке через терминал.

Как отлаживать такой проект? Напрашивается сама собой идея: делается отдельный проект, в котором компилируются все строки, потом программатором или бутлоадером (я использую второй вариант) заливается в EPROM, затем в основном проекте пишется хедер файл, в котором дефайнятся адреса, куда эти строки легли в EPROM.

Неудобно. Много ручной работы.

Можно вставить данные в основной проект и написать на дельфях или плюсах примочку, которая после сборки, но перед дебагом, будет парсить линкеровский map и загружать из параллельно сформированного HEXа через бутлоадер эти данные, а уж потом будет запущен дебаггер, который "в подготовленной почве" запустит отладку. Эта идея самая привлекательная, но есть одна неприятность - дебаггер "видит" эти лишние данные и пытается их тоже как-то грузить через JTAG, в результате чего имеется масса предупреждений. причём в стандартном FLASH лоадере прописано ограничение на адреса 0000-7FFF, но похоже это загрузчик игнорирует.

Третий путь (самый правильный и долгий) - написать свой FLASH лоадер, но я не нашёл пока нигде Jlink'овскую dll и соответствующий хедер. Лицензия у сеггера стоит 495 баков за SDK, и я тоже пока как-то не совсем готов выложить эти денежки.

Какие идеи?

А какую среду вы используете?

Обычно такие данные складываются в отдельный сегмент/секцию. Потом можно из полученного после сборки файла вытащить эту скецию для прошивки во внешнее пзу. (метод зависит от среды/линкера).
Так же линкеру сообщается что эту секцию прошивать во флешь и грузить в озу не надо.

Как пример можно посмотреть IAR для AVR и как там реализованы константные данные в EEPROM ( их можно получить в виде отдельного HEX файла).

Если потом не использовать переменные в этой секции напярмую, а передавать их адрес специальным функциям можно все свести в один проект.




Да по поводу FlashLoader
если вы используете IAR - там есть framework и примеры flashloaderов.
И вы можете написать свой flashloader, который будет при запуске отладки шить и внтуреннюю флешь и внешнюю... (причем из разных файлов можно). Flashloader у IAR может считать любой файл с компа ( не IAR сообщает лоадеру куда чего шить, а лоадер запрашивает у IAR файл, читает его и пишет куда хочет...)

KRS, спасибо за подсказку. Действительно, это IAR, и я обнаружил в папке установки всё необходимое для написания flash loader под эту задачу, и покупать SDK не придётся (львиную долю работы выполнил сам IAR). А вот с опциями линкера пока не совсем понятно. Конкретной директивы вроде "не грузить в озу или флэш" я не нашёл. Однако путь похоже есть. Данные поместил в отдельную секцию (.map файл):

define region ROM_region = mem:[from 0x00000044 to 0x00006FFF];
define region EXTFLASH_region = mem:[from 0x00008000 to 0x00017FFF];
place in EXTFLASH_region { section EXT_FLASH};

испоьзование (.c файл):

#pragma location="EXT_FLASH"
const char foo[] ="foo"; // size up to 64 kb

Линкер генерирует данные для инициализации секции EXT_FLASH и пытается разместить их в ROM (не умещается), если только не использовать директиву

do not initialize { section EXT_FLASH};

В последнем случае в генерируемом дополнительном HEX данные есть (что уже хорошо - можно шить бутлоадером, как перед отладкой, так и в релизе), и стандартный flashloader не ругается, что не может загрузить данные в область несуществующую, в общем-то, область 0x00008000.

Осталось только, собственно, сделать как разжёвано во FlashLoaderGuide.pdf. Единственные непонятный вопрос - а найдёт ли flashloader данные, имеющие отношение к директиве do not initialize.

Специально для flash loadera IAR делает файл в формате IAR Simple Code, куда вытаскиваются данные для флеша из соотв. секций.
Вам наверное надо сделать второй файл для EEPROM, можно например в postbuild добавить. Там есть специальная утилита которая из ELF файлов выдергивает секции... В HELP у IAR было, так же можно посмотреть как IAR стандартно spile code для флешлоадера генерит и добавить по аналогии второй файл.

Только что бы 2 файла шил флешлоадер придется фреймворк доработать, он под одни файл заточен. Стандартный флешлоадер пишется очень быстро ( грубо говоря только функцию записи байта во флеш написать)