Как бы тогда перекинуть функцию записи в ОЗУ, и выполнить?

Вот так, к примеру:

Самый переносимый способ. Функцию можно сделать очень компактной, так что особого напряга быть не должно.

Или пользоватся встроенным бутлоадером, или сделать свой.
Основную программу разместить по другому аддрессу.
Тогда и внешняя РАМ не надо

Но не самый "прямой".

И все. Тело функции будет скопировано перед запуском main() заодно с инициализированными данными (как и ваше, кстати), но обращаться к ней можно напрямую - линкер при обращении к этой функции будет подставлять правильный адрес в ОЗУ, и не нужно писать эту функцию в машинных кодах. Для других компиляторов можно сделать аналогично.
Но сколько работаю с разными Cortex, пока что ни разу функция в ОЗУ не потребовалась.

Да, можно разместить "прошивальщик" в конце flash, например. И не трогать этот сектор никогда.

Нет, прошивальщик должен всегда стартовать по нулевому аддрессу, с рестарта. Иначе смысл теряется.
А вот программа может быть где угодно

Так стартовать можно, куда задашь. По нулевому адресу расположена таблица startup.
Хорошо, стартанул я в загрузчик. Настроил все нужные режимы, чтобы принять новую прошивку. Жду... а ее нет. Подождал, свалил в основную программу. Так?

Таблица векторов прошивальщика. Приложение со своей собственной таблицей может располагаться где угодно. При старте запускается прошивальщик, он проверяет целостность приложения, переключает VTOR на вектора приложения (для Cortex-M0 копирует вектора приложения в ОЗУ и делает ремап), грузит указатель стека из векторов приложения и передает управление на вектор Reset приложения. Приложение может отсутствовать вообще (или быть испорченным, недозаписанным), в этом случае прошивальщик весело мигая светодиодом ожидает новую прошивку для приложения, записывает ее и делает рестарт. После рестарта прошивальщик проверяет целостность... (далее читать с начала).

А если приложение целое, но хочу зашить новую прошивку? Чем подтолкнуть?
А целостность как определить - CRC посчитать? А размеры кода откуда узнать, хранить во flash, рядом с CRC?

В конце flash сектора большие, по 128 KB (речь идет про STM32F20x). Значит, загрузчик надо расположить в начальных секторах, или в OTP (страшно!).

Я делаю программный сброс из приложения. А загрузчик после обновления делает сброс по собаке. При старте загрузчика проверяю источник сброса и если он программный - ухожу на обновление, если нет - проверяю целостность и запускаю приложение.
Да, тем более что у STM32 есть и аппаратный расчет CRC и DMA.
Я размер храню сразу после области векторов приложения. У меня его туда линкет прописывает:



Разумеется в начальных секторах. Чтобы всегда, после заливки чего угодно он всегда стартовал первым и имел возможность залить другое приложения. Я предусматриваю одну из свободных ног для принудительного запуска загрузчика - если залито приложение, которое хотя и целое, но тем не менее нерабочее, то сняв питание, закоротив эту ногу и подав питание снова, я из кирпича получаю готовое к обновлению устройство.

В секторе 0 расположить загрузчик, основную программу начать с сектора 1.
А таблицей векторов нельзя ли одной обойтись? Запретить все прерывания при загрузке, и шабаш?

Именно.
Не вижу смысла. Вектора приложения все равно каким-то образом должны попасть на свое место - или через VTOR или через ремап. При этом содержимое векторов загрузчика никакой роли уже не имеет. Никаких плюсов от неиспользования прерываний в загрузчике нет.

И вчём смысл такого решения, если всё равно необходимо будет разобрать всё устройство (что порой бывает не просто), чтобы добраться до платы с процессором. Там уже что ножку коротить, что программатор подключить, особой разницы нету.

Это нормальное решение. Сам так всегда делаю.
Часто у устройств есть клавиатура или кнопочки, поэтому и без разбора прибора всё прекрасно получается.

Т.е. данная кнопка выносится на корпус и доступна любому пользователю? На мой взгляд, не есть хорошее решение. Если бы какой-то Master мог сделать это по внешней технологической команде, тогда ещё приемлемо.