Микроконтроллеры

Изначально я использовал C8051F120. Которая не только EEPROM (встроенный), но и свой flash успешно тёрла при удачном выключении питания. После пераразводки платы нормально с подключением ножки MONEN куда нужно стало конечно по-легче... Теоретически дублирование минимально необходимо. Оно позволяет вести запись как атомарную операцию, или произошла, или нет, тогда значит осталась старая запись. Фактически на NOR flash хранятся десятки записей (предыдущих конфигураций), например, но это уже не важно. Важно, что нет никогда такой ситуации, когда данные хранятся только в ОЗУ и нигде больше. Вообще нет. А с конденсатором есть. И вот это "УМВР" оно всегда работает до поры до времени. Начиная с того какой конденсатор ставить рядом с МК потребляюющим микроамперы в одном из режимов работы, например. Так чтобы конденсатор вообще потреблял хотя бы не на порядок больше МК. Как с конденсатором обеспечить адекватную скорость нарастания питающего напряжения при пуске, если источник питания ограничивает ток? Иначе некоторые микросхемы могут не запуститься. Что питать от этого конденсатора. Если только МК, то возникает вопрос, как это вообще работать будет при отключении остальных потребителей: выводы МК начинают попросту питать остальные схемы, что для них (выводов) может быть не полезно. А питать всю схему от конденсатора: нужен он воооот-таких размеров, что в корпус не вазит. А танталовые в ценник. И опять же утечки. А как оценить напряжение на конденсаторе, достаточно оно для проведения операции или нет? Гарантировать как-то потребляемый ток в данный момент невозможно. Масса параллельных процессов и неизвестно вообще, что произойдёт при записи. А у нас вот такая чудная штука сделана, что при снижении напряжения ниже некого порога, там порядка 10%, начинает потреблять сильно ток. Чтоб оные конденсаторы разрядить за пару секунд, для перезапуска прибора при фатальных сбоях. Одновременно источник питания отрубается на чуть большее время. Да и собственно MCU в brown out уйдёт, не дозаписав половины. Как быть? И самое главное. Это всё разбивается о другие причины. Я уже говорил, что на первом месте программная: запись занимает достаточно длительное время, чтоб за это время в программе могло произойти что-то фатальное, исключительная ситуация. И запись будет прервана, а после рестарта содержимое RAM утеряно. Или попросту по воздуху прилетит "помеха" и вызовет сброс. И если после такого "не работает" (калибровочные константы, принципиально необходимые настройки) и требует поездок в командировки, транспортировки приборов на гарантийный ремонт через три границы и прочие чудеса -- сам понимаешь... или массовые возвраты. Ничем не лучше.