Защита памяти, Нужно защитить переменную в памяти Опции

[Sergio66]

Доброго вечера!
Есть программа, для Меги32.
Уже пол-года в тестовой эксплуатации.
Возникает следующая проблема - иногда, (из 50 приборов за 4 месяца круглосуточной эксплуатации) 3 или 4 раза произошел сбой системного времни
Системные часы организованы по таймеру от задающего генератора (16МГц).
CStack программы выбран в соответствии с МАР файлом, RStack - аналогично. Однако, в программе используется ф-я printf.
И у меня есть подозрение, что для нее компиллер не может правильно оценить размер CStack, и она, при своей работе выходит за границы объявленного стека и портит рабочие переменные.
переменная системного времени (__no init) расположена, естесственно в ОЗУ.
Внимание вопрос - есть ли какие нибудь мысли, как расположить данную переменную так, чтобы никакая функция, вышедшая за границы стека ее не могла испортить.
Отловить ошибку средствами отладчика не представляется возможным. Ошибка довольно редкая.
И еще.
что происходит с CStack, когда он достигает дна. Где после этого будут размещаться локальные переменные?
Заранее благодарю.

[SasaVitebsk]

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

Внимание ответ. А что, если будет запорчена другая переменная, вам полегчает? А как вообще можно говорить о работоспособности программы, при проблемах со стеком?

Мне трудно судить о вашей программе, но, исходя из вероятности сбоя, мне кажется у вас проблемы с атомарностью доступа к переменной, достаточно редко используемой. Это можно проверить, блокируя участки кода запретом прерывания. Так можно локализовать "место порчи". Ну и классический способ: взять исходник, и думать, как машина.

[Sergio66]

Внимание ответ. А что, если будет запорчена другая переменная, вам полегчает? А как вообще можно говорить о работоспособности программы, при проблемах со стеком?

1. Все другие переменные восстанавливаемы. Все, кроме времени. Они восстанавливаются из контекста программы.
2. Вопрос ставился именно КАК защитить определенную область памяти от всяких случайных переполнений. Чтобы ВСЕ переменные не портились. Ну, на крайний случай - критические данные, типа времени.

Мне трудно судить о вашей программе, но, исходя из вероятности сбоя, мне кажется у вас проблемы с атомарностью доступа к переменной, достаточно редко используемой. Это можно проверить, блокируя участки кода запретом прерывания. Так можно локализовать "место порчи". Ну и классический способ: взять исходник, и думать, как машина.

Что касается доступа - то системное время мнеяется только в обработчике прерывания таймера, а во всех остальных случаях, только читается и переностится в лог.
Конфликт доступа исключен.
Причем, сбивается оно случайным образом - не предсказуемо на какое значение, а в обработчике прерывания оно меняется только на 1 (+1). Т.е. конфликт доступа, если бы он и был, то не приводил бы к таким последствиям.

И, возвращаясь к вопросу стека - при настройках из xcl-файла, CStack развивается в сторону младших или старших адресов? Судя по тому, как задан стек, мне кажется, что в сторону младших. Т.о., при выходе за 0х60 адрес, стек что будет портить? регистровый файл? Старшие адреса области данных? Старшие адреса RStack?