Всем добрый день.
Для камня STM32F407 взял эмулятор EEPROM с сайта st. Вложил в свой проект с оригинальными настройками как в примере. Всё вроде как работает нормально. Но там EEPROM эмулируется во втором и третьем секторах FLASH памяти (которые по 16к). Я в своём проекте перенёс эмуляцию EEPROM в первые два сектора и соответственно сдвинул таблицу векторов прерывания на второй сектор:

Необходимые изменения внёс в eeprom.h.

В своём проекте в начале вставил пример записи трёх переменных в память. Всё как бы работает, НО только с отладчиком из IAR контроллер стартует как надо. Если сделать сброс кнопкой, то уже не стартует.
Я пока перенёс эмуляцию EEPROM в последние два сектора, но они по 128к и откусывать пол флеша как-то не охота. В такой конфигурации всё работает как надо.

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

Программа стартует с адреса, указанного в векторе по адресу 4. Из адреса 0 берется начальное значение указателя стека. Эти адреса прибиты гвоздями. Переносите свою EEPROM в последние сектора. В первом (нулевом) должна находиться таблица прерываний.

Как уже сказано, первый сектор занять для эмуляции EEPROM не получится.
А чем не устраивают второй и третий секторы?

Про таблицу векторов понял. Тогда в нулевом секторе надо разместить начало таблицы прерываний. В прерывании сброса сделать переход на начало программы расположенной после Sector 1 и Sector 2, которые заняты под EEPROM. То есть основную программу расположить, начиная с Sector 3. Я правильно мыслю?



Вы имели ввиду Sector 2 Sector 3 или Sector 1 Sector 2 ? В примере эмуляция сделана в Sector 2 и Sector 3, а основной код закладывается с самого начала FLASH и, как я думаю, есть опасность перекрытия кода программы с секторами EEPROM. В линковщике я никаких мер по избеганию наложения не увидел (может плохо смотрел).

Я именно об этом. У линкера есть все необходимые средства.

В целом - да. Фактически в нулевом секторе вам надо расположить два первых элемента таблицы (указатель стека и адрес вектора сброса). А в основной программе все равно надо будет иметь полную таблицу векторов и в процессе запуска программы записать ее адрес в регистр VTOR. Но ради чего все это городить? Почему не выделить под EEPROM последние сектора? Тогда вам достаточно будет в скрипте линкера уменьшить доступный программе объем флеша.

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


также при эмуляции eeprom можно на получившийся адрес накладывать маску, которая позволит не "выпрыгнуть" за диапазон отведенных секторов



и loadregion разбивать не придется. Честно говоря, даже и не пробовал никогда собирать с "дырками"


хотя... эту область также можно в loadregion включить и получится без разрывов, только код в ней не размещать

Длительность стирания сектора 16К и 128К - 250 мс и 1000 мс соответственно (typ). Есть над чем подумать. Ну и кого-то жаба задушит: зачем разбазаривать 256К, когда можно обойтись 32К?

Два последних сектора по 128к. А это половина памяти МК. Не выгодно. Первые четыре сектора по 16к.




Я сейчас линковщику указал что доступная память начиная с 0x0800C000 это Sector 3.

Вектора по умолчанию в начало флеша. В настройках эмулятора EEPROM

это Sector 1.

В памяти основной код лёг с 0x0800C000. Основная таблица прерываний легла с 0x08000000.
По адресу 4 указатель на вектор прерывания, который расположен выше 0x0800C000. А там дальше SystemInit и стар основной программы.
Пока всё завелось и работает. Тестирую….

Но как-то не выгодно с этими секторами – получается, что первый сектор в 16к «гуляет почти свободным». Там сейчас всего не более 512 байт записано. Не рационально))))

Как указать линковщику, что бы он ничего не располагал с адреса 0x08004000 по 0x0800BFFF ? Тогда память будет выгоднее использоваться.

Я с Кейлом бы помог, но наверняка Ваш линкер имеет аналогичные механизмы

как-то так. То есть указали, что начало загрузки - 0x08000000, сразу (+0) с длиной 4000 идет секция, в которой располагается вся root секция с таблицей векторов и любой код, который поместится (.ANY(+RO)), потом пустая часть, и потом еще секция под код

В "старом" яровском линкере (XLINK) можно было сказать линкеру, чтобы размещал в разных кусках памяти, типа так: -Z(CODE)CODE=0x08000000-0x08003FFF, 0x0800C000-0x0807FFFF. И ведь реально работало.
В "новом" линкере (ILINK) я не разбирался, но думаю, что он тоже это умеет (заглядывал в мануал). Попробуйте подправить файл конфигурации линкера:
define region ROM_region = mem:[from 0x08000000 to 0x08003FFF] mem:[from 0x0800C000 to 0x0807FFFF];

Большое спасибо за наводку. Почитал доку на линковщик. Там много чего можно сделать, в том числе и регион с дырой. Я переделал так stm32f4xx_flash.icf :



Полёт нормальный. Но только в Sector 0 линковщик совсем немного кода добавил. Всё остальное уже после выделенной EEPROM памяти.

Всем спасибо за ликбезы))))

Наверное, это потому, что весь программный код складывается в одну большую сплошную секцию. Соответственно, в нулевой сектор попадают оставшиеся крохи: таблица векторов прерываний, константы, начальные значения статических переменных. Можете проверить это предположение, заглянув в MAP файл. Помню, что GCC умеет выделять отдельную секцию для каждой функции, а вот йар - не похоже...

Да, разложил линковщик так:


*******************************************************************************
*** PLACEMENT SUMMARY
***

"A1": place at 0x08000000 { ro section .intvec };
"P1": place in [from 0x08000000 to 0x08003fff] |
[from 0x0800c000 to 0x0807ffff] { ro };
"P2": place in [from 0x20000000 to 0x2001ffff] { rw, block CSTACK, block HEAP };

Section Kind Address Size Object
------- ---- ------- ---- ------
"A1": 0x188
.intvec ro code 0x08000000 0x188 startup_stm32f40xx.o [1]
- 0x08000188 0x188

"P1", part 1 of 2: 0x250
.rodata const 0x08000188 0x0 zero_init3.o [5]
.rodata const 0x08000188 0x0 lz77_init.o [5]
Initializer bytes ro data 0x08000188 0x24f <for P2 s0>
- 0x080003d7 0x24f

"P1", part 2 of 2: 0x10cdc
.text ro code 0x0800c000 0x2060 shell.o [1]
.text ro code 0x0800e060 0x1bc ip_addr.o [1]
.text ro code 0x0800e21c 0xc errno.o [3]
.text ro code 0x0800e228 0x110 xstrerro.o [3]
.text ro code 0x0800e338 0x36 strlen.o [5]
.text ro code 0x0800e36e 0x22 zero_init3.o [5]
.text ro code 0x0800e390 0x3f4 api_lib.o [1]
.....

будет место для констант и инициализаций. Их планируется не мало.

Я тут то же ковырялся с дырой для флеша в кейле. Ничего у меня с дыркой в регионе не вышло. Взял и тупо в ассемблерный файл, сразу после таблицы описания векторов, влепил SPACE(0x8000). Не красиво конечно, но времени не было.

С огнем играете. Сколько там циклов перезаписи?
У нас в старых STM32F107 уже ошибки записи выдает.
Если EEPROM интенсивно не использовать, то ничего, конечно..

Дык Кейл этого и не умеет. Там нужно руками раскладывать секции сверху и снизу от дырки.

сделал по такому примеру, всё работает, но есть следующий вопрос:
При такой записи регион с дырой получается, но есть одно НО, вектора прерываний разместятся с адреса 0x08000000, а код весь будет размещён после выделенных регионом под EEPROM. Т.е. такой записи (где используются сектора 1 и 2) код разместится с адреса 0x0800c000, а если назначить для эмуляции EEPROM сектора 2 и 3, то код разместится уже по адресу 0x08010000. Т.о. получается, если делать дыру во флеши для EEPROM надо использовать всегда сектора начиная с 1-го иначе будет потеря секторов флеши. И также 0 сектор тоже практически будет потерян по памяти, т.к. в нём кроме таблицы прерываний ничего не размещается (т.е. для эмуляции EEPROM будут потеряны 3 сектора, 2 сектора на EEPROM, а один будет гулять практически пустым). Можно ли это как то обойти, может ещё нужно в линкере чего-то прописывать? Прибивать ф-ции или массивы констант по конкретным адресам желания нет.
В данном проект памяти хватает и потеря 3-х секторов по 16К не критична, но на будущее хочется уметь использовать всю память

Мне сейчас неохота рыть документацию, но у F1xx при включении защиты от чтения первые два сектора автоматически защищаются и от записи. И переписать их можно только стерев весь кристалл. Здесь нет чего-то подобного? Как бы не получилось, что включив защиту от чтения вы поломаете работу этой эмулированной ЭСППЗУ. А в целом я бы отдал нулевой сектор загрузчику и забыл про него, а программу размещал бы целым куском уже после секторов эмуляции ЭСППЗУ.

+1. Собственно, с такой картой распределения секторов ничего лучше и не придумаешь.

ИМХО, такой фичи нет.


Ну так и не надо дёргаться раньше времени. Страшный день, когда кончится память, скорее всего никогда не наступит. Кроме того, как известно, "преждевременная оптимизация - корень всех зол".
А если когда-нибудь действительно припрёт, то ручками разложить секции не так уж и сложно.

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

не много не по секторам, но про эмуляцию.

Модернизировал то, что написано STM, добавил возможность писать не только 16, но и 8 и 32 битные данные (выбирается через дефайн).
И запустил их тестовый проект. Так вот, при записи 16 битных и 32 битных данных, проблем нет, а при записи 8-ми битных данных при переходе с одной страницы на другую страницу, заполненная страница не всегда полностью очищается, что приводит к дальнейшему неверному чтению данных.
Это происходит в ф-ции EE_PageTransfer(...) , где страница очищается ф-цией

Если ставить точки останова в ф-ции EE_PageTransfer(...), не важно в каких местах, то такой проблемы нет.
Другой вариант решения этой проблемы добавлением инструкции __DSB() или задержки (хватило где-то 35 NOPов)

либо отредактировать FLASH_EraseSector() в конце дописать __DSB(), на всякий случай