Раньше я много работал с серией микроконтроллеров C2000 от Техаса.
Там был механизм (CCStudio), позволяющий разместить любую функцию в RAM. Это позволяло существенно ускорить выполнение критического кода, а также избежать остановки выполнения программы в процессе записи или стирания Flash. Механизм примерно такой:
1. Для информирования линкера создавалась специальная секция: размещение во Flash, запуск из RAM.
2. При компоновке линкер все адреса вызовов модифицирует так, как будто этот код уже располагается в RAM.
3. В процессе инициализации эта секция копируется в RAM стандартно, по аналогии с инициализируемыми переменными.
4. При выполнении, при обращении к функции происходит переход по адресу в RAM.
К сожалению для STM32 я пока не обнаружил аналогичного механизма.
Больше всего меня смущает не быстродействие (конвейер в STM32 достаточно хорош), а проблема, связанная со стиранием больших секторов. Например в STM32F4 время, на которое код зависает при выполнении из Flash, может достигать сотен миллисекунд.
Конечно можно весь код разместить в RAM, но не всегда это возможно из соображений размера, да и защита от несанкционированного копирования кода в этом случае имеет проблемы.
Хотелось бы более красивое решение.
Есть мысли по этому поводу? Может я просто не нашёл нужный документ или пример?

для gcc: __attribute__ ((section(".ramfunc")))

Обнаруживать Вам надо не в STM, а в компиляторе. Какой компилятор?


Использовать EEPROM (если таковая есть в Вашем МК) или внешнюю FLASH.

Да этот важный момент я упустил. среда программирования - IAR.

__ramfunc
https://www.iar.com/support/tech-notes/link...ewarm-5.x--6.x/

Зависит от того, что вы хотите делать в течение этих сотен миллисекунд. Если что-то нетривиальное, то обнаружите, что половину вашего кода, если не больше, нужно будет размещать в ОЗУ. Причём отделить нужное от ненужного будет ой как не просто.
Кстати, зачем стираете большие сектора? Я для эмуляции EEPROM выделяю 2 сектора по 16 кБайт. Там типичное время стирания сектора 250 мс. В моих применениях программа может подождать 250 мс.

Значит Вам повезло, потому что в папке doc есть файл EWARM_DevelopmentGuide.ENU.pdf.
Там есть описание как работает __ramfunc и какие изменения нужно сделать в конфиге линкера (initialize by copy { section .textrw }; ).

У меня примерно так: Первые два сектора по 16к - загрузчик. Следующие два сектора по 16к - EEPROM. Затем код основной программы. В конце два больших сектора под запись протоколов.
Устройство должно протоколировать все события в системе. Протоколы пишутся во кругу в два сектора. И всё равно когда то наступает момент, когда нужно стереть сектор. Я конечно стараюсь отложить этот момент на время, безопасное со всех точек зрения, но проблема существует.
По поводу того, что именно помещать в ОЗУ, да такая проблема есть, но решаемая. Обычно это прерывания, плюс несколько важных функций.
В нормальном режиме у устройства обмен по нескольким каналам связи со скоростями 5-10кбайт в секунду. Зависание на такое время (сотни миллисекунд) даже визуально проявляется на мониторе связи. Не говоря уже о таких процессах, как управление ШИМ-преобразователем.
Кстати ещё один вопрос: Если во время стирания флэш, произойдёт любое обращение к флэш, то программа зависнет до окончания операции стирания? Или обработка прерывания возможна? Скорее всего, даже для того, чтобы работали прерывания, нужно на время операции стирания исключить любые обращения к флэш. Так?



Спасибо, посмотрю. Наверное это то, что мне нужно. Хотя документ известный, вряд ли я мимо прошёл. Может чем то не устроил.

Как я уже писал - копеечная SPI (или I2C) FLASH спасёт отца русской демократии
Либо выберите другой МК, где есть встроенная EEPROM (или даже FRAM).
А ещё можно вообще не писать во FLASH, а накапливать в ОЗУ. Сделать монитор питания и по сбою питания быстро скидывать в FLASH (предварительно стёртую).

Да.


Нет.


Да.

Кстати, в том же STM32F427 есть такая штука, как два банка флеш. Пока один банк стирается, программа может выполняться из другого.
Или поставьте внешнюю флешку SOIC8 из 25-й серии. Их везде как грязи, и стоят они копейки.

Именно.

Т.е. читать можно, но это приведёт к приостановке выполнения программы до конца операции стирания или записи.
Именно это и происходит при обычном стирании/записи без перемещения программы в RAM.

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

Про два банка я в курсе. Но обычно при выборе контроллера масса разных критериев и удобство записи во flash не является определяющим.
Внешняя флешка, возможно это и правильно, но какой то не наш способ. Вроде потому, что не смог реализовать нормальный функционал на основной памяти контроллера.
Ведь многие применяют эмуляцию EEPROM, хотя внешняя микросхема EEPROM тоже стоит копейки.
Кстати я столкнулся с тем, что при наличии мощного источника помех, например вакуумный выключатель рядом, запись во внешнюю память (использовал SPI-FRAM) сопровождается сбоями.
Я рассчитывал, что запись внутри контроллера будет надежнее в этом плане.

Я тоже так думал, когда был моложе
Сложность разработки - не пустой звук. Цените своё время и труд. Плюс чем сложнее функционал, тем тяжелее его отладить и отловить все глюки, то есть надёжность легко может пострадать.


Внешняя EEPROM не отменяет необходимость проверять целостность данных, а примерно половина функционала эмуляции EEPROM именно этим и занимается.


Тут можно поставить фильтры (RC) и соответственно снизить скорость обмена.

Пинайте ваших схемотехников - пусть руки выпрямляют.
Наши счётчики э-энергии работают на подстанциях без проблем. А у них и SPI-FLASH и SPI-FRAM есть. И пишут туда в непрерывном режиме.


Проблема не в скорости, а в грамотной разводке платы.

Есть небольшая проблема: Я и есть тот схемотехник.
Дело в том, что устройство находится внутри коммутационной ячейки, практически на корпусе ВВ. И коммутируется 10кВ.
Больших проблем там нет, примерно один сбой на 100 коммутаций, да и исправляется это программно. Так как я сам управляю ВВ, то для гарантии я запретил запись на 100мс после коммутации.