Добрый день !
Вопрос следующий.
Каким способом при старте можно проверить, что часы реального времени в LPC не сбились ?

Ну только если завести еще парочку - для сравнения... Нет, серьезно - а как это проверить, если не сравнением с другими? Если же вопрос стоит - не сбросились ли они - запоминать куда-нибудь при выключении, а при включении сравнивать - больше ли времени, чем было до выключения, хотя это и ненадежно...

Ну скажем, год 3310. Боюсь, что не доживу до этого.

Так а что подразумевается под "сбились"? Уход от реального времени вследствие погрешности (постоянной/переменной, скажем, температурный уход частоты) задающего генератора или обнуление из-за сбоя питания? Если обнуление - то запоминать. Тем более, если часы считают годы - если век не соответствует записанному в энергонезависимую память, то точно пропадало питание часов. Ну а если просто уход на +/- полкилометра - то имхо только сравнение с эталоном, а как еще?

Ну например.
30 июня
при этом это
356 день года.

Хм. Ну если для вас сбой - это разница показанийй двух параллельных счетчиков - так это как раз проверить крайне просто. Можно контролировать по таблице длин месяцев (для простоты) - например, есть массив количества дней: в январе, в январе + в феврале (здесь и далее - год не високосный), по март, и т.д. Смотрим, какой месяц сейчас - берем соотв. число дней до этого месяца + кол-во дней из счетчика. Если нынче високосный год и февраль закончился - плюсадиним, сравниваем со счетчиком дней года. Вроде просто.
А вот отставание или опережение из-за плохонького китайского часового кварца - это да, это проблема. Нужен эталон (который может быть дороже всего остального - цезиевые часы с термостабилизацией, или какие сейчас самые точные), или просто человека заставить иногда поправлять время, ориентируясть на радио Маяк.

Вот и вопрос. Насколько это универсально.

В пределах одного семейства, если по железу - тут же привязка к конкретной избыточчности.
Из-за чего могут рассинхронизироваться два счетчика, тактируемые одним источником (часовым таймером в д.с.)? Да еще и так, чтобы ни один не был нулевым. Мне все же представляется, что такая ситуация - более редкое явление, нежели уход частоты тактов или пропадание питания (ионистор был бракованный). Ну только если сильные радиошумы, или радиация.

Вероятнее, банальное пропадание контакта от батарейки.

Ну если все-таки от пропадание напряжения, то они собьются синхронно, не так ли? Тогда смысл такой проверки нулевой - оба счетчика будут (после приведения к общей единице) иметь одно и то же содержимое. Тогда либо оператора-человека, либо второй ртс. Кстати, от пропадания контакта на батарейке есть неплохие ионисторы - 2,3 В х 40 Ф. Маленькие, всего 14х18х(40+12 на выводы)Хватит может и не до 3310 года, но надолго Тип К58-16. Вроде даже на 47 Ф уже выпускаются. Как раз думаю, не использовать ли

Из моего опыта - только проверять валидность (диапазона) данных. Есть там один информационный бит, но при сбое (отключении батарейки) он то "слетал", то нет.

Я при старте всегда проверяю корректность данных в разрезе диапазона. Когда имею дело со внешней RTC то при каждом чтении. С LPC имел проблему следующего характера - бывало криво тикало. Подлечилось путем начального обнуления всех регистров RTC.

Я тоже склоняюсь к такому решению.

какой?

1. Срок изделия допустим 50 лет. Т.е. год в диапозоне 2007-2057.
2. День года должен соответствовать числу. Например: 31 декабря 2008 года - 366 день.
Это - то, что на поверхности.