Какую память использовать для хранение настроек в stm32f407? Думал прицепить память spi но в самом микроконтроллере 1мб памяти, для всех настроек 10кб хватит вполне. Опасение если использовать память программ вдруг в момент записи пропадет питание или еще что то, не хотелось бы что бы повредилась программа, как правильнее сделать?

Вообще делать контроллер без еепрома это свинство (не могу опять не пнуть СТМ), но если у вас именно настройки, значит они пишутся под контролем юзера (при подключении к хосту через юсб, скажем), так что вполне можно во флэш писать.

Дык, эстешники вам в ответ апликуху - "эмуляция eeprom". Если питание пропало и какая-то настройка не сохранилась остается ее предыдущее значение.
Я правда, эмулирую eeprom по-своему (не как ST предлагают), но за много лет использования косяков не заметил.
Даже циклический журнал событий держу в контроллере. Кста, с записью событий "появилось питание", "пропало питание" - по сработке PVD,
времени сохранить запись хватает.

Я тоже изменяемые данные сохраняю во флеш. Правда, в отличие от, скажем, STM8, STM32 не позволяют перезаписывать области произвольного размера — только кратные размеру страницы.
На STM32F103 о 100 ногах мне пришлось пойти на хитрость: выравнять не только размер структуры на 2кБ, но и ее начало (чтобы четко 1 страницу заняла). И вот так из-за десятка новых байт приходится 2кБ перезаписывать. Благо, нечасто.
Кстати, для обозначения конца структуры (а также выравнивания) мне подсказали интересную штуку, которую я и использовал: "массив нулевого размера".

В F407 страница вообще по 16кБ, а настройки у меня 64 байта занимают (степень 2).
Страниц минимум две (больше - лучше).
Находим первое пустое место после записей. Пишем туда. Если при этом запись попадает на новую страницу, то предыдущую стираем.
Все разумеется в терминах "кольца".

Надежность (10к перезаписей страницы) * (16к размер страницы / 64 байта размер структуры) * (2 число страниц) > 5М перезаписей.

Если писать по кругу, то где-то придется как-то сохранять указатель на актуальную запись. Как?

Не придется, если записи внутри пронумерованы.

И как узнать номер последней актуальной? Перебирать по NULL-terminated все?

Да, перебрать все. Выполняется один раз на старте и много времени не занимает.

Поддерживаю мысль.
Так-же реализовал. Кольцевой, по три банки. одну пишем, вторую переносим в ту что пишем(лениво), третью по надобности стираем.
Хвост ищем при подъёме. Времени не очень много занимает. Для бОльшей скорости записи делаю индекс в памяти на существующую картину.

Если подужать до 4кб, и используете встроенные часы с батарейкой, то можно просто писать в backup RAM.

Ой. Так не всегда годится. Что будет при смене батарейки? Все настройки потеряются?

Ненадёжно. При сбое питания/перезагрузке в момент записи потеряете все данные.
Журнал с несколькими записями однозначно надёжнее: если не валидна последняя запись (из-за прерывания записи перезагрузкой), читаете предыдущую, валидную.

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

Я во флеш храню настройки как на старых железках на LPC23xx, так и на новых на процессорах STM 407/417, целостность данных контролирую CRC, жалоб на пропадание настроек пока не поступало. Партии около 1000 изделий, но это правда на LPC23xx, думаю на STM будет результат не хуже.

Это не довод. Вероятность низкая, но всё равно не годится если нужна надёжность. 1000раз не случилось в 1001й раз попадёт сбой во время записи.
Если не проблема переконфигурить устройство при таком случае - то тогда на страшно.
Но если ответственная область, где важна надёжность работы и трудно будет переконфигурить заново - не годится.

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

Буду использовать внутреннюю память. Скачал исходники eeprom emulation протестировал немного мне не подходит как там реализовано, переделал вроде все работает, только почему то FLASH_EraseSector() не стирает, стирание должно заполнять сектор 0xff ? А там прошлая запись остается. Если вначале стираю потом записываю данные, данные сохраняются проблем нет. Но после стирания должно же быть 0xff? Не писать же в цикле 0xff если есть стирание.

Это запись в обычную память, вероятность сбоя не больше, чем запись в любую ячейку памяти и уж куда меньше, чем процедура записи во флеш, т.к. там пишет не байтами, а страницами. Если произойдет сбой при записи в память, то потеряете байт или 4 байта, а в случае флеши - всю страницу.

Забавная выдумка. Не обманывайте неокрепшие умы.
Флеш стирается постранично. А запись происходит гораздо меньшими порциями. У тех же STM32 в зависимости от подсемейства может быть и побайтовая запись, и запись 16-битными словами. Это очень удобно для эмуляции EEPROM, реализации всяческих журналов и т.п.
Это только убогие флеши типа как у LPC требуют записывать гораздо более крупными пачками, потому что каждая пачка защищается кодом коррекции ошибок.

О как! Оказывается, наличие ECC свидетельствует об убогости.

Пачка 16 байт всего. Не сказал бы, что это сильно мешает эмулировать EEPROM.

Под "сбоем" я имел в виду сбой питания (или перезагрузку по иной причине: помеха и т.п.).
И вообще это относилось к Вашему подужать до 4кб, и используете встроенные часы с батарейкой, то можно просто писать в backup RAM
Если так сделать, то при любом прерывании записи потеряется вся структура хранения (так как резерва по ёмкости нет).
Будут потеряны все настройки и устройство возможно перестанет функционировать.
Если использовать журнал, с несколькими записями и несколькими минимальными элементами стирания (>=2), то потеряется только последняя структура хранения.
Но всегда будет валидная предыдущая.
И при сбое питания не портится вся страница, только записываемая часть её.

Ирония в том, что при эмуляции EEPROM в STM32 я это тоже делаю, но своими ручками.

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

Именно так. Приблизительно как калека легко распознаётся по наличию костылей. А здоровый человек и без костылей может передвигаться.


Что, прямо настоящий код, исправляющий ошибки? Или банальная контрольная сумма, как у всех?

LPC177x, 178x вроде достаточно свежий? Упоминания про 16 байт в руководстве пользователя не нашел.
Нет, я помню про раскрученный много лет назад встроенный загрузчик, и тем не менее 16 байт можно записать только недокументированными методами. Или я что-то неправильно понял?

То, что выглядит как костыль, совсем не обязательно таковым является.

Конечно, калека может внушить себе, что его костыли - вовсе не костыли, и вообще это классно и модно. Но это его личные проблемы :-)

Действительно, у них такого нет. Для LPC11, LPC13 написано явно.


То есть серверную технику и всякие поделия на Cortex-R4 с ECC всего и вся записываем в калеки автоматом?

Тут уж надо или представлять данные о (не)надежности флеш NXP, или не заниматься домыслами.

У нас свобода слова, так что извините. Что хочу, то и говорю.
Ну и то, что мнения по этому вопросу у нас отличаются, - тоже не проблема, у нас же разрешён плюрализм мнений :-)

Банальная сумма, т.к. модель сбоев flash в STM32 мне неизвестна, и шансы скорректировать отдельные битые биты ничтожны.
Я готовлю запись, считаю сумму, записываю во flash, считываю. Если считанные данные совпали с записанными, то возвращаю "успех", иначе "ошибка".

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

И тем не менее - так и есть. При попытке дописать к 16 байтам ранее записанным, получите мусор. Так что писать только кратно 16.

Прочитать эти самые 256 | 512 | 1024 | 4096, модифицировать в них требуемый участок, выровненный на 16 и записать. Только документированные методы.

В lpc использовал для хранения настроек внешнюю память в некоторых есть модуль spif.

Для LPC17 этот метод все же не является документированным. Сравните с LPC13/11, где есть явное описание.

Господа, не отвлекаемся от темы: LPC, а уж тем более страны к сути топика не имеют никакого отношения.

Напомню исходный вопрос: есть stm32f407, где хранить настройки? во внутренней flash или во внешней. Большинством голосов пришли к выводу,
что во внутренней можно. Страницы, ECC и т.п. большой роли не играют, т.к. при грамотной реализации у людей, использующих эмуляцию eeprom
в stm32, нет проблем с надежностью.

Из тонких моментов можно обсудить: "большие" страницы у некоторых МК; задержка(?) доступа к flash при стирании/записи.

Да, есть такое. А ещё бывает dual bank, когда длительное стирание не создаёт задержки в выполнении программы. Ну что тут сказать? Всё зависит от требований в конкретном применении. Может статься, что длительная задержка неприемлема. Тогда уж извините.
И ещё я бы не стал недооценивать сложность кода эмуляции EEPROM. В зависимости от сложности схемы эмуляции там может быть много разных условий и граничных случаев. Напрашивается автоматизированное тестирование. Иначе глюк может вылезти в поле в самый неподходящий момент.

И соответствующий пункт в ES (правда, для f42x, f43x):

Ага. Почесал за ухом - аукнулось в пятке. Бывает, что уж там. Это не повод посыпать голову пеплом и уходить в монастырь :-)

круто что эта нога вообще ничто... как так они умудрились...

В ревизии 3 пофиксили. Мне интересно как вообще обнаружили такое поведение?

Интересно, такое проявлялось только в f42x, f43x. Т.к. использовал Эмуляцию eeprom от ST, изменив её выбором через дефайны какой тип данные используется для записи/чтения 8/16/32 бит. А также изменил оптимизировал некоторые ф-ции при вкл./выкл. блокировки флешь.
Отладил, всё заработало, но в устройствах на 405 и аккумуляторном питании, периодически наблюдается сброс всех настроек и перезапись непонятными данными по 2-м используемым страницам флеша. Использовались 2-ая и 3-ая страницы. Вычитывал их ST-Link(ом) после сбоя. И стационарное устройство на 407 на нём всё в порядке.
На 405 ножка PA12 используется, на 407 ножка PA12 не используется. На аккумуляторном устройстве (тот что на 405) стал думать, что в момент разряда аккумулятора (такое может быть хоть каждый день) мк часто перезапускается внешним супервизором (хотя задержка такого запуска ~ 1 сек.) и я, где-то, что-то в программе не учёл, и поэтому портятся данные. Но при включении записи нет есть только чтение, откуда берется перезапись 2-х страниц флеша мне не понятно. Пока эксперименты были отставлены из-за других дел. Но как вернусь к ним обязательно буду смотреть в сторону ножки PA12 в том числе.

В ES описано, что данные из flash могут быть вычитаны с ошибкой. К стиранию/записи это не относится.
Чтение с ошибкой из flash скорее всего проявится как сбой программы, т.к. будет вычитана некорректная инструкция.
Лучше прочитать всю ES.