Использую прерывания по переполнению таймера. В обработки прерывания подсчитываю часы реального времени. Переменные часов это однобайтовые ячейки SRAM. Кроме переменной DS – она двух байтовая.
В основном цикле есть условие которое не должно никогда выполнятся - если R4 = 20 то перейти в подпрограмму Obr. При этом R4 всегда 0. Но, тем не менее, при обработки на кристалле я попадаю в подпрограмму Obr, при этом R4 = 0. И еще, я заметил, если переменную DS сделать однобайтовой то переход в Obr происходит реже.
В чем прикол? Причем данный алгоритм я проверял на разных кристаллах: ATMega88p, ATMega48, ATMega8, ATMega128. И везде одно и тоже…

Я в таком интерфейсе не работал, но то, что в нем могут быть бока -нельзя исключать.
Эти облегчения программ всегда боком вылазят.
Мож в timer_0_Over пишет число 20 в этот регистр ?
На выходе Hex файл дает прошивки ?
Если да, проверяйте в протеусе регистр R4 с этот момент. Желательно в момент перехода на obr программе зависнуть и увидете, если там число 20, то тогда глюка нет, и действительно где-то оно записалось, если другое чисо, то тогда какой-то баг

___________
вообще теней много, надо только в симуляторе смотреть что там пишется в регистр. Да и теж 2-х байтовые переменные, они же тоже сначала в 2 регистра пишутся, а потом в ОЗУ. В прог этого не видно как оно происходит на самом деле. По сути это исковерканный ассемблер

Суть понятна.
HEX файл есть, но каким ПО с ним работать? И как я понимаю, что в данной ситуации нужно отлаживать на кристалле. Соответственно понадобится соответствующий программатор.

О... Algorithm Builder... Знакомо... Нужно отслеживать состояние регистра R4. Но этого изменения вы можете и не увидеть при отладке на кристалле. Не исключаю также, что этот регистр используется самим компилятором, например при отладке. Может используется для какой-то переменной. То что R16 и R17 используются компилятором и для своих целей их нельзя использовать - знаю точно...

Посмотрите руководство пользователя по Algorithm Builder, где-то на сайте автора было вроде. Попробуйте использовать другой регистр, или попробуйте зарезервировать этот регистр для себя (клавиша F12 - определения переменных и регистров).

Можно попробовать, как сказал Схемопай, дополнительно в протеусе прогнать прошивку.

Компилируем проект в Algorithm Builder, получаем HEX-файл, собираем схемку на микроконтроллере в протеусе, загружаем прошивку в него и делаем пошаговое выполнение программы, наблюдаем за проявлением глюка и состоянием регистров...

Все нормально ребята, всем спасибо. Просто нужно было загонять в стек Sreg, r16, r17. Вот пробовал загонять все кроме R17. Про R17 как то замылилось и то же не работало. Сейчас все норм всем спасибо.

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

Ну в Algorithm Builder не так много подводных камней. Этот наверное самый заморочный.
После компиляции при наведении на строку видна ассемблерная конструкция, которую компилятор вставит в код и регистр R16 частенько используется при отправке в стек регистров ввода-вывода и других, например SREG.
Поэтому при отправке в стек данных регистр R16 и R17 отправляйте первыми, а потом всё остальное, а то восстановите их из стека, а компилятор при восстановлении других данных использует R16 или R17 и затрёт их.