Собственно, хотелось бы работать со встроенной оперативкой SRAM для повышения производительности МК, и в связи с этим возникли вопросы..

Как я понял при прочтении даташита, по дефолту SRAM расположена в области 0x0020 0000 - 0x002F FFFF, а после ремэпа к ней можно обращаться по адресу 0x0..

Так вот.. при прошивке МК через самбу мы можем закинуть программу в SRAM, однако как дать понять МК, что он должен грузиться из памяти по адресу 0x0020 0000? В случае выполнения проги с флеш достаточно было выполнить скрипт загружаться из флеш.. для SRAM же такого скрипта нет..

Если же ремэпить, то не совсем понятна последовательность действий: нужно ли ремэпить прямо в основной программе и записывать ее в флеш.. или на флеш записать программу с ремэпом, а в SRAM кидать основную программу?

В Самбе можно загрузить программу в RAM и сказать go. Список команд.


Для работы из RAM remap делать вовсе не обязательно - достаточно просто разместить код в нужной области средствами линкера.
Если remap все-таки нужен, то лучше его выполнить в стартап-коде сразу после сброса, а дальше уже спокойно работать с RAM.

загрузил программу в SRAM, проверил - говорит совпадает в точности...
затем говорю go 0x200000, он отвечает 0..
проверяю - программа не выполняется..

Программа, слинкованная для диапазона адресов флеш-памяти, при заливке в озу естественным образом работать не будет, и об этом Вам уже говорили:

Почитайте FAQ по армам, там есть на тему где рыть для исполнения из ОЗУ.

скачал из FAQ файл с вашим примером, прочел его.. написано обстоятельно, но все равно у меня осталось несколько вопросов..

если я правильно понимаю, sct-файл создается при компиляции и включает в себя информацию, прописанную заранее в разделе Project/Options for target '...'/Target или Project/Options for target '...'/Linker. Также при компиляции создается hex-файл, который мы затем шьем в МК..
Так вот собственно и непонятно: каким образом, в случае если мы вручную изменим sct-файл, это отразится на выходном hex-файле? Другими словами, что изменится в данной ситуации для МК?

Такой же вопрос с ini-файлом... Ведь конечный продукт - это hex-файл, тогда хотелось бы узнать подробней, что нужно сделать, чтобы информация об измененных sct и ini файлах добавилась в hex..

Только, если не используется внешний scatter-файл. Мне показалось удобным сначала собрать проект "по-дефолтовому", а затем растиражировать и подправить scatter-файл для всех необходимых целей (у меня это отладка из рамы и прошивка во флеш - соответственно, разные диапазоны и длины областей ro и rw). А потом эти файлы начали кочевать из проекта в проект, иногда изменяя имя
Ну, это если нам надо хекс. Я пока обходился без него, прошивая из объектника с помощью кейла и рди. И, кстати, при компиляции з каждого исходника сооздается свой объектник, при линковке все объектные файлы сводятся в один объектный файл (он уже исполняемый, хотя содержит еще и немало мусора - для отладки, но тут я еще не силен - не дорос до тонкостей объектных файлов), а хекс получается сторонней утилитой, в случае кейла это $KEIL\ARM\BIN30\fromelf.exe.
Для МК изменятся числа, соответствующие адресам функций и переменных, - все имена переводятся в адреса. Так же, если, к примеру, стартап слинкован во флеш, а какой-нибудь файл - в озу, то (в районе _user_initial_stackheap) добавится копирование функций из флеша в озу (чтобы все работало). И если мы просто изменим файл, кейл не обидится и перезапишет его Файл ему еще и скормить надо не забыть.
Ини - это сугубо для отладки (ну и прошивки камня из оболочки). На саму прогу инишник не влияет, он указывает среде, что ей делать при запуске Вами отладки, чтобы отладка таки началась. Если я дебажу из озу, необходимо делать ремап контроллера средствами оболочки, а не программы. Программа-то у нас базируется на 200к адресе, а флеш (100к), смаппированная на адрес 0 - ресетовый адрес, пустая или содержит хз что... Поэтому, чтобы программа стартовала прямиком из озу при чистом или неверном флеше, надо немного настроить периферию контроллера. В кейловских (или еще чьих-то) примерах я видел, что с помощью ини-файла инициализируют всю критичную периферию, типа вочдога, фапч, еще что-то. Мне хватает ремапа, все остальное делается уже в программе.

Итак, изменяю scatter-файл согласно примеру, предложенному Leen'ом, то есть привожу его к следующему виду:

; *************************************************************
; *** Scatter-Loading Description File generated by uVision ***
; *************************************************************

LR_IRAM1 0x00200000 0x00010000 { ; load region size_region
ER_IRAM1 0x00200000 0x00008000 { ; load address = execution address
*.o (RESET, +First)
*(InRoot$$Sections)
.ANY (+RO)
}
RW_IRAM1 0x00208000 0x00002000 { ; RW data
.ANY (+RW +ZI)
}
}

При этом две верхние строки в выходном hex-файле изменяются, то есть, по-видимому, они как раз и отвечают за линковку.. Далее пишу через самбу в SRAM, говорю go 0x200000 и.. ничего..

Что же сделано неправильно? Как я понял из слов aaarrr'а, этого должно было хватить.. или все-таки нужно делать ремэп?

Посмотрел сейчас в дизассемблере (симулятор)... Скаттер примерно такой же - начало ro-региона 0x200000.
Т.е. адрес прыжка - 0x00000018, а не 0x00200018. Поэтому ремап делать необходимо, судя по тому что я знаю. Причем, делать его надо до go 0x200000.
Ресетовая инструкция (в моих файлах) лежит в третьей строке, первая по счету. Она не изменяется, даже если поставить начало 0x900000. Изменения начинаются (с стартап-файлом кейла для рвст) с адресов перехода на обработчики исключений - андеф, сви, и т.д., которые я не переписывал. Там стоят тоже абсолютные адреса, ибо:
тут отличий в хекс-файле нет

а тут есть