Добрый день знатокам!
Использую среду разработки IAR и микроконтроллер STM32F103C8T6. Пытаюсь одну из функций проекта поместить по заранее заданному адресу Flash памяти, а не как себе «решит» компилятор, все остальные функции пусть располагает как он считает нужным.

При стандартном объявлении функции: void ReadUART1(void) {…}
после компиляции если смотреть в файле *.map, видно что эта функция помещается компилятором во Flash памяти по адресу 0x0800'01d7, что означает достаточно не далеко от начала Flash памяти.

После попытки объявления функции: void ReadUART1(void) @ "MYSEGMENT" {…}
после компиляции если смотреть в файле *.map, видно что эта функция переместилась компилятором во Flash памяти по адресу 0x0800'd929, а это уже по сути в самом конце проекта.

Не могу понять, ГДЕ и КАК задать "MYSEGMENT" необходимый адрес, например 0x0800'F000.

P.S. директива #pragma location = 0x0800F000 перед этой функцией не работает, так как по видимому она предназначена только для переменных

На основе приведенного примера в соответствующих разделах файла *.icf установил следующие строки:

define region MY_FUNC = mem:[from 0x0800F000 size 0x0800];

place in MY_FUNC { readonly MYSEGMENT };

но линкер выдает ошибку в последней строке Error[Lc003]: expected "}"
и судя по всему с параметром «readonly» недопустимы другие приставки/переменные и т.п.

Во-первых, в штатном icf посмотрите как сделано для секции .intvec. Она как раз по фиксированному адресу располагается.

Во-вторых, если вам потребовалось расположить функцию по фиксированному адресу, то вы явно что-то делаете не так!

Уж не таблицу ли векторов прерываний перенести нужно?

Нет, самую главную функцию прошивки - ReadUART1(). Зачем, меня не спрашивайте.

Ваууу получилось!!! Спасибо огромное VladislavS!
И правильно догадались о чем идет речь, о бутлоадере … и я уже пошел чуть дальше, запихнул его в RAM память что бы не мешал перезаписывать всю Flash, вот только сейчас думаю над самым безопасным диапазоном в памяти (достаточно и 1К байта) что бы потом во время работы МК не заципили динамически выделяемые переменые, стек и всё такое

Какой смысл от загрузчика, который выключение питания не переживает, как им пользоваться?

COKPOWEHEU, полагаю, имеется ввиду работа из ОЗУ, что даёт возможность перезаписать самого себя. Риск "окирпичивания" этим повышен в разы...
похоже на страдание ерундой, не?

Martian, о риске «окирпичивания» уже начал догадываться, а Вы подтвердили это, спасибо значит нужно вернуться во Flash, там же и организовать проверку на правильность перезаписи (оставлять некую метку об успешности операции)

MarkTok, похоже на страдание ерундой. Делаете отдельным проектом бутлоадер, который видя целостность прошивки передаёт на неё управление. Основная прошивка просто с другого начального адреса линкуется и всё. Единственное, она должна правильно таблицу векторов прерываний настроить и переферию более надёжно сбросить перед инициализацией. Больше никакой разницы из-под бутлоадера прошивка работает или без нет.

Согласен. Но это иногда неудобно. Но зависит от конечной цели устройства...

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

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

если загрузчик не успеет чего-то там подменить, то снова "кирпич". Не, расположение его изначально первым практически исключает риск.

Как он может не успеть что-то подменить?! Там же нет никакой гонки.
Ну и удобство писать потом код как будто никакого загрузчика нет, не стоит исключать.

ну фиг знает. питание скакнёт или ещё что, и криво переписал.
а вообще, разве в STM32 уже нет всяких бутлоадеров внутре?

Есть, конечно. В f103 можно прошиваться по UART, а в более сложных и по USB. Но это надо дергать BOOT0 и RESET, что не всегда удобно.

сплошное неудобство. вектор переназначить - неудобно, выводы замкнуть - неудобно... ну, дёрните их программно.

Вы все однозначно более профессиональны в данном вопросе, поэтому я возможно просто ещё не вижу скрытых камней на своем пути, хочу сначала попробовать то что задумал, а потом уже сказать что получилось … ну или не получилось ))) Но уже даже сейчас можно сказать что Martian прав, вероятность «окирпичивания» в момент прошивания всё таки будет при скачке питания или т.п.

на мой взгляд, написание бутлоадера - это очень хорошая практика независимо от результата