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

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

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

Сообщение отредактировал IgorKossak - Oct 7 2014, 14:11

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

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

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


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

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

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

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

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

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