работа с SRAM, AT91SAM7X Опции

[Sergei_K]

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

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

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

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

[aaarrr]

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

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

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

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

[Sergei_K]

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

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

[Leen]

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

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

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

[Sergei_K]

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

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

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

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

Сообщение отредактировал Sergei_K - Nov 9 2007, 06:36

[Leen]

если я правильно понимаю, sct-файл создается при компиляции и включает в себя информацию, прописанную заранее в разделе Project/Options for target '...'/Target или Project/Options for target '...'/Linker.

Только, если не используется внешний scatter-файл. Мне показалось удобным сначала собрать проект "по-дефолтовому", а затем растиражировать и подправить scatter-файл для всех необходимых целей (у меня это отладка из рамы и прошивка во флеш - соответственно, разные диапазоны и длины областей ro и rw). А потом эти файлы начали кочевать из проекта в проект, иногда изменяя имя

Также при компиляции создается hex-файл, который мы затем шьем в МК..

Ну, это если нам надо хекс. Я пока обходился без него, прошивая из объектника с помощью кейла и рди. И, кстати, при компиляции з каждого исходника сооздается свой объектник, при линковке все объектные файлы сводятся в один объектный файл (он уже исполняемый, хотя содержит еще и немало мусора - для отладки, но тут я еще не силен - не дорос до тонкостей объектных файлов), а хекс получается сторонней утилитой, в случае кейла это $KEIL\ARM\BIN30\fromelf.exe.

Так вот собственно и непонятно: каким образом, в случае если мы вручную изменим sct-файл, это отразится на выходном hex-файле? Другими словами, что изменится в данной ситуации для МК?

Для МК изменятся числа, соответствующие адресам функций и переменных, - все имена переводятся в адреса. Так же, если, к примеру, стартап слинкован во флеш, а какой-нибудь файл - в озу, то (в районе _user_initial_stackheap) добавится копирование функций из флеша в озу (чтобы все работало). И если мы просто изменим файл, кейл не обидится и перезапишет его Файл ему еще и скормить надо не забыть.

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

Ини - это сугубо для отладки (ну и прошивки камня из оболочки). На саму прогу инишник не влияет, он указывает среде, что ей делать при запуске Вами отладки, чтобы отладка таки началась. Если я дебажу из озу, необходимо делать ремап контроллера средствами оболочки, а не программы. Программа-то у нас базируется на 200к адресе, а флеш (100к), смаппированная на адрес 0 - ресетовый адрес, пустая или содержит хз что... Поэтому, чтобы программа стартовала прямиком из озу при чистом или неверном флеше, надо немного настроить периферию контроллера. В кейловских (или еще чьих-то) примерах я видел, что с помощью ини-файла инициализируют всю критичную периферию, типа вочдога, фапч, еще что-то. Мне хватает ремапа, все остальное делается уже в программе.

[Sergei_K]

Итак, изменяю 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'а, этого должно было хватить.. или все-таки нужно делать ремэп?

Сообщение отредактировал Sergei_K - Nov 12 2007, 11:14

[Leen]

Посмотрел сейчас в дизассемблере (симулятор)... Скаттер примерно такой же - начало ro-региона 0x200000.

Код

0x00000000  E59FF018  LDR       PC,[PC,#0x0018]]

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

Код

Vectors         LDR     PC,Reset_Addr        
                LDR     PC,Undef_Addr
                LDR     PC,SWI_Addr
                LDR     PC,PAbt_Addr
                LDR     PC,DAbt_Addr
                NOP                           ; Reserved Vector
;               LDR     PC,IRQ_Addr
                LDR     PC,[PC,#-0xF20]       ; Vector From AIC_IVR
;               LDR     PC,FIQ_Addr
                LDR     PC,[PC,#-0xF20]       ; Vector From AIC_FVR

а тут есть

Код

Undef_Handler   B       Undef_Handler
SWI_Handler     B       SWI_Handler
PAbt_Handler    B       PAbt_Handler
DAbt_Handler    B       DAbt_Handler
IRQ_Handler     B       IRQ_Handler
FIQ_Handler     B       FIQ_Handler