Это хорошо! А то компилятор менять совсем не хотелось.


Dragon'ом


Да да, я присмотрелся к коду представленному выше, и похоже там промах с ILock (не в том месте стоит).



между проверкой на NULL и запретом прерываний slot мог обнулиться..
Написал так:



Оставлю на ночь с этим изменением, завтра отпишу рез-тат.
Большое спасибо за помощь



Дык и раньше эти два события были мало взаимосвязаны. Т.е. программа могла продолжать работать с неверным K, а это для меня гораздо хуже чем перезагрузка..

Ну наверное это все-таки как-то связанные события учитывая то что Вы заполнили перед этим
стек константой 0xA5, ну да ладно. не суть...

Лучше раскажите, удалось победить глюк, и если удалось то как победили и в чем он был ?
ilock ? или что-то другое

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

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

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

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

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

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

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

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

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

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

При умножении! (mul/fmul используют R0/R1)

типа того, к сожалению точно не помню(не пользуюсь умножением/делением
на авр без особой нужды)

но если не етот глюк, то hex все таки пните...
если этот то тогда не надо

Я бы блокировал прерывания прежде чем проверять очередь на наличие задачи, а не проверять результат после того как фунцкия выбрана из очереди, а дребезг подавлял бы до того как он сгенерирует событие. имхо.
Один вопрос - а Вы используете Ilock из прерывания ? Если нет то зачем статус регистр запоминать? Вроде бы Set_Callback для того чтобы запускать тасковые функции после прерывания.

Резонно.


Дребезг теперь сам-собой подавляется, из-за этих условий:
- два одинаковых события в очереди находиться не могут,
- время до запуска события - 20ms с момента попадания в очередь.
тобиш если приходит неожидаемое второе событие вызванное дребезгом - старое удалится - новое добавится, в очереди останется только одно такое событие.


Некоторые функции, например запись в eeprom, могут выполняться как в обработчиках прерываний так и вне, в них требуется запрещать прерывания. ILock/Unlock у меня сделаны так чтобы не задумываться где я сейчас нахожусь. Думаю они себя оправдывают, 1 команда (in rr, sreg) не велика цена за универсальность.

Еще можно добавить, что переменные, которые модифицируются в прерываниях положено объявлять как volatile - чтобы процессор правильно произвел оптимизацию обращения к этим переменным (не в регистры)