Подскажите, кто знает, как в STM32F7 весь код загрузить вo внутреннюю ram и оттуда выполнять. Например в Keil. Для большей предсказуемости времени выполнения. Спасибо.

Я делал вот так:

Правда, у меня STM32F4 и GNU Arm Embedded.

Но вообще цель сомнительная. Не надо делать код, который должен быть предсказуем по времени выполнения.

В F7 в принципе код выполняется странно. Даже кол-во _nop точно не выдерживается.

Может есть смысл размещать в ОЗУ не весь код, а только тот, который этого требует?
Особенно выгодно по скорости выполнения размещать код в области ОЗУ, которая напрямую подключена к ядру (в STM32 она называется TCM RAM).
В KEIL это делается очень просто, почитайте мануал.
Если нужно весь код, то я бы сделал так:
пишем простейший загрузчик (стартуемый из FLASH), который копирует и возможно даже на ходу распаковывает сжатый код из FLASH в ОЗУ.
Делает ремап векторов (в NVIC поправить всего один регистр) и запускает загруженный код.

А сам код для исполнения в ОЗУ собирается уже с другими параметрами линкера (в скрипте линкера нужно лишь поправить несколько строчек кода).

После чего его (BIN файл) можно упаковать (при желании) и добавить в прошивку загрузчика как внешний файл. KEIL это умеет.
Нажмите для просмотра прикрепленного файла


Т. е. можно так настроить, что нужный HEХ при компиляции будет формироваться автоматически, для этого лишь нужно выбрать нужный режим (у меня обычно DEBUG/RELEASE) в выпадающем списке.
Нажмите для просмотра прикрепленного файла

На каком этапе этот загрузчик поместить в код?

На F7 (да и пожалуй на любом из старших ARMов) в принципе не надо писать код, основанный на времени выполнения NOPов.

Создаете ДВА проекта -
проект А - для формирования финальной прошивки (бинарник берем из проекта B ) вместе с простым загрузчиком.
проект B - для целевого кода, в сборке DEBUG выполняется и отлаживается как обычно из флэш, в RELEASE сборке - финальная прошивка с размещением всего кода в ОЗУ.

А почему не хотите переместить в ОЗУ лишь части проекта, которым это действительно необходимо?

А почему не хотите переместить в ОЗУ лишь части проекта, которым это действительно необходимо?


Код всего 56 кб, а ресурсов ему много надо. И к тому же скорость и повторяемость по времени выполнения. Иначе на экране дрожит сигнал.

Каких ресурсов?


Разметите критический важный кусок кода внутри отдельных функций, размещенных в отдельном С/CPP файле, поместите весь файл в секцию RAM (как это сделать, см. мануал на Keil).
Тогда не придется городить загрузчик лишь для того, чтобы весь код засунуть в ОЗУ.

Вы действительно полагаете, что перемещение ВСЕГО кода в ОЗУ поможет решить эту проблему?

Три четверти функций очень чувствительны и к скорости и к синхронности. Где-то так. Очень не хочется плиску ставить. Всё работает, но не хватает скорости совсем немного.
Отсутствие 5ти -6 ти waitstates может помочь.

Чисто праздный интерес: каким способом вы пришли к тому, что перенос кода в ОЗУ решит проблему?

Отсутствие задержки при чтении из флэш. А еще как-то надо отключить предугадыватель фрагмента, который он грузит в кэш. Может быть повторяемость времени исполнения улучшится.

Если не секрет, то о какому чудо-проекте идет речь? Любопытно ))

Ультразвуковой прибор. Внутренний ЦАП через ДМА управляет VGA, а внешний АЦП через DMA2 GPIO и TIM8 в режиме ШИМ оцифровывает сигнал со скоростью 20 MSPS. Приколы начинаются с того, что после излучения импульса 500 нс, почему-то проходит разное время до запуска дма. Хотя больше ничего не выполняется и systick выключен. От этого и дрожит сигнал. Потом еще бих фильтр полосовой, фильтр экрана нужен и вывод картинки.

Лютое решение (((
Конечно, уже поздно переделывать железо, но почему решили все это чисто на MCU, а не поставили хотя бы FPGA в связке с практически любым МК?

если 2/3 кода требуют работы из ОЗУ, так разместите этот код в отдельный файл, разместите его в секции ОЗУ, а все остальное оставьте во флэш.
Таблицу векторов желательно скопировать в ОЗУ с перенастройкой NVIC, причем кидать в TCM ОЗУ. Судя по размеру проекта, хватит всей TCM на весь код )))

А как получить задержку 5 тактов на 200 МГц?


В этом весь сок. Обойтись без плиски.

А в чем собственно проблема? Речь про некий академический тест (курсач)?

Существуют плиски со встроенными ARM ядром, флэшью и ОЗУ, т. е. по сути обычный МК ARM, но с плюшками.
Такой вариант не подошел?

Никак.
Руки поотрывать тем, кто на такое закладывается

Спасибо за идею.

Ответ на этот вопрос начинается с ответа на вопрос: задержку между чем и чем?

PS: Я тоже в одном из проектов делал УЗ-прибор с резонансной частотой преобразователя до 7МГц.
Формировал сигнал управления возбуждением средствами МК. И оцифровывал эхо встроенным АЦП МК на clk = 80 MS/s.
Без каких-то проблем. Естественно не НОПами.

у четвёрки флеш шире озу, а у семёрки ещё в два раза шире, поэтому никакое озу вам не увеличит скорость работы
а чтобы работа из флеша была детерминированной нужно уменьшать тактовую до 24 мгц
так что вы совершенно не в ту сторону копаете

М7 может выполнять код из ITCM в режиме шины AXI. Это нулевая задержка. Памяти мало, может уместиться вектора, перемывания и критический код. Стек нужно натравить на DTCM, что не совсем очевидно(стек ниже данных). Там-же расположить критические данные. А всё остальное - на свободные банки памяти и флеша.

Задержка 5 тактов на 200 МГц вполне возможна, однако бессмысленна. Чип обладает развитой периферией, в которой эти задержки программируются в режиме инстала. Разная память, разные правила, настраивать регионы памяти - обязательно. http://forum.ixbt.com/topic.cgi?id=48:11266:2178#2178

Этот с/срр файл можно сделать в существующем проекте среди других с/срр файлов?

Именно так и нужно делать, изменяются лишь свойства этого нового файла (см. мой первый пост в этой теме).
Вообще, все это есть в мануале на Keil - см. RAM function. Не ленитесь читать ))