IAR + RM9200 Опции

[Demeny]

Начал осваивать архитектуру ARM, есть отладочная плата с RM9200+DataFlash+SDRAM. Установил IAR (кажется, 4.40). Первый проект (по традиции) - мигание светодиодом, взят из примеров IAR - в процессе отладки во внутренней RAM работает (отладка через Wiggler), светодиод мигает. Но при попытке продвинуться дальше возникает ряд вопросов.
1. Если я залил проект в RAM и он работает, то я ожидаю, что по нажатию RESET (без выкл. питания) программа в памяти стартует заново, и светодиод продолжит мигать... Однако этого не происходит. Почему?
2. Пытаюсь добавить в функцию main() что-то типа

Код

printf("Init OK \n");

При сборке линкер ругается на стек, увеличиваю стек с 2000 до 4000, проект собирается нормально. Но при заливке в кристалл возникает ошибка уже на этапе заливки, и в правом окне отладки вместо внятных ассемблерных инструкций какой-то мусор.
3. Что из себя представляет mac-файл ? Насколько я понял, он заливается и выполняется в контроллер до заливки основной программы. Т. е. это и есть т. н. бутлоадер, или я ошибаюсь ?
4. Зачем в принципе придумано такое многоступенчатое разделение исполняемого кода - сначала .mac файл, затем Startup.s79, затем lowlevelinit, и только потом main() ? Разве нельзя сделать "по-простому" - начинаем сразу с функции main(), в которой и инициализируем всё low-level хозяйство и далее приступаем к основному коду ?

[Dron_Gus]

Отвечу, на те вопросы, которые знаю:
1) т.к. в кристале зашит bootloader. Именно он запускается при подаче питания (сбросе). Он ничего о Вашей программе в ОЗУ не знает и соответственно не передает ей управление.
3) что-то вроде скрипта. содержит описание действий отладчика перед отладкой. Настройка PLL, контроллера памяти и т.д.
4) перед выполнением Сишной main необходимо настроить хотя бы стек, желательно для всех режимов.

[S.E.V.]

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

[cf7k]

2. Пытаюсь добавить в функцию main() что-то типа

printf("Init OK \n");

Но при заливке в ..... вместо внятных ассемблерных инструкций какой-то мусор.

3. Что из себя представляет mac-файл ? Насколько я понял, он заливается и выполняется в контроллер до заливки основной программы. Т. е. это и есть т. н. бутлоадер, или я ошибаюсь ?

макросы (.mac) - это сугубо для IAR'вского C-SPY (в смысле отладчика). Пример: есть такой бит как REMAP - "выкидывание" ROM из начальных адресов и "подстановка" туды RAM. Если пытаться хотя бы заливать по JTAG не воспользовывшись этим REMAP на свежесброшенной системе - залить ничего не удасться. что собственно и наблюдается в пункте 2.

А то что им можно инициализировать SDRAM - это только удобство для оладки(как и PLL и прочее).

Основную прогу в принципе можно загружать только ROMloader'ом - тогда она должна быть маленькой (помещаться в IntSRAM) и может пользоваться SDRRAM.
Если прога побольше - то ее невозможно залить в SDRAM - ROMloader ничего не знает о SDRAM - он умеет только в IntSRAM. Вот тут и появляется многоступенчатость: сначала в IntSRAM - свой загрузчик; он подготовит SDRAM и сам загрузит большую прогу.
Дальнейшее увеличение "ступенчатости" - для универсализации: сначала маленький загрузчик, который готовит SDRAM для большой проги, потом большой загрузчик в SDRAM, который умеет не только из flash памяти, но и по USB и по Ethetnet, а уж только потом - основная прога. (при этом первые два зашиваются один раз и никого не беспокоят).

4. Зачем в принципе придумано такое многоступенчатое разделение исполняемого кода - сначала .mac файл, затем Startup.s79, затем lowlevelinit, и только потом main() ? Разве нельзя сделать "по-простому" - начинаем сразу с функции main(), в которой и инициализируем всё low-level хозяйство и далее приступаем к основному коду ?

А объединить это все в один вызов из main можно только в том случае если вся программа слинкована и влазит в Internal SRAM, но startup - это вспомогательный код, который идеологически не должен вызываться из пользовательской программы (он подготавливает "окружение" для основной программы)