Всем привет!

Никто не пробовал загружать бутлоадер в RAM и уже от туда "править балом"?
Думаю написать код, который бы загружал по доступному каналу (в частности у меня USB устройство, так по USB и буду грузить) в память загрузчик и передавал бы ему управление.
Всё понятно, вот только ни разу даже не пытался исполнять код из RAM на STM32. Может есть какие примеры? По сути в памяти будет "программа" целиком с таблицей вектором и всем прочим. Только вот не могу ещё определиться всегда ли в одних и тех же адресах памяти или "как получится", но то что непрерывно это точно
Кто что скажет? Отговорите может от затеи?

То есть изначально неизвестно расположение в памяти?
Какая среда разработки?

Ну пока ещё всё видами по воде, и не могу с уверенностью сказать где оно будет.
Среда... ну есть и IAR и Keil, но как-то так получилось что пишу в Eclipse+GCC (видать привычка с Linux...)

Копать в сторону "Position independence", http://infocenter.arm.com/help/index.jsp?t...cc_bcfjjdfj.htm

Спасиб. Нашёл что-то похожее, но наоборот
https://gitorious.org/miosix-kernel/miosix-...otloaders/stm32
Тут как я понял ребята сделали загрузчик и выполняют код из памяти, у меня же всё наоборот, но реализация пригодится

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

Ну раньше у меня всегда так и было. А тут хочу чего-нить эдакого! Захотел изменить что-нить в алгоритме загрузки - на тебе, взял да поменял!
Ну да странно, но вот хочется

так это делается как раз заменой бута 2-го уровня

В STM32F4xx загружал основной код в RAM. Работает именно так, как и должно, граблей не обнаружено. В тот момент - keil, но ничего не мешает обучить линкер любого другого компилятора.

Другой вопрос. Кто и как загрузит этот бутлоадер? Основной код? Так проблема обычно в том, что в самый нужный момент этот основной код сломался, и его срочно нужно заменить.

При отладке небольшого firmware, у меня обычно есть отдельная конфигурация (icf-файл IAR с RO-секциями в ОЗУ) для выполнения кода в ОЗУ.
Для релизной сборки просто компилю тот же самый проект в другой конфигурации с icf-файлом с компоновкой RO-секций во флешь.
Грузится в ОЗУ JTAG-ом гораздо быстрее, так что отлаживать удобнее. Да и флешь лишний раз не протирается.
Никакой разницы в выполнении во флешь и ОЗУ не наблюдается (если конечно всё корректно написано).

Для чего-то другого использовать код в ОЗУ смысла мало. Имхо...

ну как.. скорость...
реально на ARM9 код из TCM выполняется раза в два быстрее, чем из флеш. Критические по скорости секции можно туда складывать

На ARM9 код редко выполняется из флешь. Обычно - из кеша.
И что-то я сомневаюсь, что из TCM у вас будет в 2 раза быстрее чем из L1-кеша.
У меня на ARM9 включение кеша кода практически уравнивает в скорости внутреннюю ОЗУ с внешней SDRAM.

PS: Да и вообще-то в топике STM32F103 где TCM, как я понимаю, не пахнет.

я имел ввиду (флеш|AHB RAM) супротив TCM. А L1 там нет вообще (LPC2919)

В Вашем нет, а в моём - есть 32K (OMAP-L137). А у топикстартера вообще Cortex-M3.

не стоит.
не из озу, из флэша, но адреса не определены заранее.
минусы:
1) отладиться на сях не прокатит.
2) при достижения некоторых размеров кода, компилятор иногда ставит явную адресацию, а иногда косвенную. всякие попытки явно сказать
ему чтоб не умничал - не увенчалось успехом. выход нашёл , но достаточно кривой.
3) Прелопачивать стандартные библиотеки, оси. На предмет статик данных и допиливания до Ваших извратов.
4) Тратить достаточно времени для проверки всех мест, обращения к таким данным.

на маленьких объёмах кода - в принципе не наблюдается.