Необходимо иметь возможность хранить буквально несколько байт. Девайс low-density. Почитал на форуме про методики хранения в main flash memory - громоздко и не гибко. Собственно flash состоит из трёх блоков main(var), system(2kb) и option bytes(8b). В последнем блоке есть 8 байт памяти:
"4 for write protection, 1 for read protection, 1 for configuration and 2 for user data storage"
Ну два байта(user data), понятно, можно использовать, хочется ещё первых четыре заюзать(WP которые). Собственно, из документации понял что при активации read protection(RP) первые несколько страниц(количество зависит от density) основного flash блокируются на запись, а оставшиеся страницы могут быть перезаписаны только программой(не отладчиком).
Так ли необходима защита от записи основной памяти? Если в программе нет кода совершающего такие действия, то даже при слёте PC по идее прошивка не будет испорчена. Или я ошибаюсь?

Такой способ, по идее, позволит сохранять информацию минимальным кодом(и без какой либо опастности для программы). А загрузка происходит вообще автоматом(в "регистры": FLASH_OBR и FLASH_WRPR)

PS: с ARM'ами только начинаю работать и железа ещё не видел - выясняю необходимый минимум внешних деталей.

Что значит low density в контексте микропроцессорной техники? Поясните, чтот-то я пропустил...
А насчет хранения данных... Откройте для себы FRAM - гуглить по словам FM25L04, например. И по названию фирмы.

low-density это применительно конкртено к линейке МК серии STM32. Это не столь важно, просто размер флэша ограничен(low <= 32kB), и не хочется засорять его лишним кодом.
А насчёт FRAM(уже смотрю): именно этого и не хочется, чтобы для хранения нескольких чисел(которые будут очень редко изменяться, за время жизни устройства от силы раз 10 ) использовать внешние микросхемы.

гы, а в LPC23 случаем нету тоже каких пару байт энергонезависимой и чтобы без IAP и батареек? мечты

слово density там только один раз встретилось -
improved performance with better code density
так что я все равно не понял... но звучит непонятно и красиво. Больше вопросов нет.

Плохо смотрите. Откройте любой даташит на STM32 и в первой же строке будет, к примеру для STM32F103xB -

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

Идея понятна, но универсальности хочется - не считать же, сколько раз производилось сохранение новых параметров (при возникновении сбоев иногда приходится покрутить их в ту или иную сторону по нескольку раз). Да и кода будет больше чем в моём варианте (загрузка данных будет с перебором до первых FF'ов). То что ничего внешнего цеплять не нужно уже уяснил .

Подскажите документ, по которому Вы ориентировались по работе с Flash-памятью,плиз

ИМХО, надуманная проблема. Кода совсем немного требуется. Сделайте правильно - но пожалеете. "Правильно" - это как Вам посоветовали :-)