Как поместить функцию по заданному адресу Flash памяти

[MarkTok]

Добрый день знатокам!
Использую среду разработки 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 перед этой функцией не работает, так как по видимому она предназначена только для переменных

[Martian]

https://stackoverflow.com/questions/187 ... get-stored

[MarkTok]

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

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

place in MY_FUNC { readonly MYSEGMENT };

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

[VladislavS]

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

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

[>TEHb<]

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

[VladislavS]

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

[MarkTok]

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

[COKPOWEHEU]

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

[Martian]

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

над самым безопасным диапазоном в памяти (достаточно и 1К байта) что бы потом во время работы МК не заципили динамически выделяемые переменые, стек и всё такое

похоже на страдание ерундой, не?

[MarkTok]

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

[VladislavS]

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

[Martian]

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

[COKPOWEHEU]

Martian писал(а):

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

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

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

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

там же и организовать проверку на правильность перезаписи (оставлять некую метку об успешности операции)

Зависит от алгоритма прошивальщика. Он может проверять корректность записи каждой страницы.

[Martian]

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

[COKPOWEHEU]

Martian писал(а):

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

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

[Martian]

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

[COKPOWEHEU]

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

[Martian]

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

[MarkTok]

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

[Martian]

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