WinAVR 200701.., Не могу понять где глюк Опции

[defunct]

Чип M168, компилирую с опцией -Os, с O0 использовать не могу т.к. hex получается больше 16k..
Девайс периодически перезагружается, MCUSR показывает Reset Source - 0 (прыжек на адрес 0), через ~1-8 часов работы..

В main при инициализации заполнил область стека тестовым паттерном 0xA5 после этого:
1. девайс начал иногда вместо ребута подвисать (через те же 1-8 часов работы), прерывания продолжают работать.. (WatchDog пока не включаю чтоб не мешал)
2. Заметил, что некая long переменная K, которую обновляю в основном цикле программы:
K = X; (где X long переменная равная xxxx, и X = (volatile long)Y; ) иногда принимает значение: 0xA5A5xxxx, когда ожидается 0x0000xxxx. (переменные X и Y - имеют правильные значения)

Промониторил стек после очередного ребута - за границу 256 байт - не выходит и не пересекается с другими структурами данных.
float, sprintf, printf в программе не применяю.

Собсно вопрос, может есть известные баги WinAVR 200701xx, которые бы могли это объяснить?

[defunct]

Да, проблема-таки была связана с ILock! С изменением приведенным выше девайс уже проработал 24 часа без ребутов.

Причина банальна - дребезг... Счетчик секунд который чуть-чуть опережал показание RTC это подтвердил.
Прерывание, которое должно происходить строго раз в секунду - иногда (очень редко) происходило едва ли не сразу после предыдущего. Если в момент запуска callback'а происходило повторное прерывание с повторной установкой этого же callback'a, то старый еще не запущенный но уже проверенный на NULL удалялся из очереди (у меня не допускается держать в очереди дубликаты событий) - ну а потом уже NULL() - и ребут....

Подправил расположение ILock и сместил время выполнения события на 20ms.
SetCallback( ..., 20, ...);
Теперь работает все как надо.

Еще раз спасибо всем кто принимал участие в обсуждении!

[singlskv]

Да, проблема-таки была связана с ILock! С изменением приведенным выше девайс уже проработал 24 часа без ребутов.

Причина банальна - дребезг... Счетчик секунд который чуть-чуть опережал показание RTC это подтвердил.
Прерывание, которое должно происходить строго раз в секунду - иногда (очень редко) происходило едва ли не сразу после предыдущего. Если в момент запуска callback'а происходило повторное прерывание с повторной установкой этого же callback'a, то старый еще не запущенный но уже проверенный на NULL удалялся из очереди (у меня не допускается держать в очереди дубликаты событий) - ну а потом уже NULL() - и ребут....

Подправил расположение ILock и сместил время выполнения события на 20ms.
SetCallback( ..., 20, ...);
Теперь работает все как надо.

Еще раз спасибо всем кто принимал участие в обсуждении!

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

типа статистику собираю, а Ваш случай интересный...

[defunct]

А стек при этом таки переполнялся или нет ?

Стек не переполнялся это 100%, и объяснить появление 0xA5A5xxxx я не могу, кроме как предположить, что GCC при оптимизации держит константу 0, где-то в памяти, а при моем вмешательстве с заполнием стека паттерном "заполнило" и ее. (у меня там была довольно существенная прослойка "гуляющей" памяти - байт в 200 между стеком и переменными).

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

[singlskv]

Стек не переполнялся это 100%, и объяснить появление 0xA5A5xxxx я не могу, кроме как предположить, что GCC при оптимизации держит константу 0, где-то в памяти, а при моем вмешательстве с заполнием стека паттерном "заполнило" и ее. (у меня там была довольно существенная прослойка "гуляющей" памяти - байт в 200 между стеком и переменными).

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

GCC держит константу 0 в регистре R1 кажись,
вроде бы были сообщения от userов что при определенных условиях там может оказатся не 0.
но это бабушка на двое сказала...

Вобщем если Вы пнете в меня своим hexом хотябы то мне будет очень интересно посмотреть
чего там протсходит, а если елфом то тады ваще очень интересно,
обесчаю перед прочтением Вашего кода его съесть...