Здравствуйте.
Столкнулся с непонятным явлением при обработке прерывания по переполнению таймера1.
Исходные данные:
сделаны часы на PIC16F74, используется статическая индикация и контроллер выбран просто из-за большого количества выводов
быстродействие не требуется абсолютно, поэтому установлен LP режим и кварц на 32768
при данной частоте и использовании предделителя, период переполнения таймера1 составляет 64 сек
поэтому данный таймер использован для подсчёта минутных интервалов
разрешено единственное прерывание по его переполнению, в процедуре обработки сначала старший байт таймера перезагружается значением 10Н (чтоб сократить период до 60 сек), затем увеличивается регистр минут, часов, напоследок сбрасывается флаг прерывания
основная программа просто непрерывно по кругу выводит часы и минуты в сегментном коде на порты и проверяет кнопки управления

Проблема такая:
в сутки хаотично добавляется от 5 до 20 минут
все попытки как то программно отследить происходящее эффекта не дали
рассматривался и вопрос ложных прерываний от другово источника (в обработчик вставлялась проверка флагов и вывод на индикацию если будет обнаруже отличный от переполнения таймера), и помехи по кнопкам управления (они просто выкидывались из исходного кода)
нет, происходит именно хаотичное двойное увеличение счетчика при обработке, такое впечатление что иногда не сбрасывается флаг и после выполнения RETFIE прерывание тут же вызывается снова

Проблема в принципе решена:
в итоге прерывание было просто запрещено, в обработчике RETFIE заменено на обычный RETURN, в начало обработчика вставлена проверка бита переполнения и выход если бит не обнаружен, во все циклы основной программы просто натыканы CALL 4
т.е. реализовано тоже самое прерывание, только тупо программной имитацией
все сбои сразу исчезли

Вопрос:
куда копать то?
задача текущая конечно закрыта, но надо на будущее как то понять всё же

ddd-ekb, слово "скрываете" я использовал в шутку. ViKo, однако прав, я давно на ассемблере не писал, вот и забылось.
Как я вам и писал - именно адресация страниц портится у вас, в обработчике прерываний. Уважаемый ViKo, навел на правильную мысль.
Попытайтесь поставить вот такую преамбулу обработчика прерываний и соответственно на выходе тоже обратный код:

да и чёрт с ней, с этой адресацией, пусть хоть вся перепортится
в данной программе на каждом проходе принудительно устанавливается состояние всей периферии
затем просто берутся значения из регистров минут и часов, перекодируются в сегментный вид и выплёвываются в порты
так что все сбои могут привести только к сбою индикации на от силы 50-100 миллисекунд
вобщем пока пусть проверяется, первые полчаса прошли нормально

из-за этого получаете несанкционированные входы в обработчик прерываний ... но как скажете.

на сейчас окончательно утряс причину возникновения повторного прерывания сразу при выходе из обработчика
несанкционированных входов нет
в основной программе есть периодическая инициализация регистра PIE1
MOVLW 1
MOVWF PIE1
на всякий случай, вместе с остальными TRISами и ADCONами
вдруг чего сбойнёт от помех и некому будет питание передёрнуть, а вачдог не сработает, т.к. программа то бегает по кругу, просто периферия переинициализировалась неверно из-за таджика-сварщика
раз уж методом тыка установлено влияние страниц, то логично предположить что обработчик и правда не восстанавливает страницу, тогда получается что при попадании момента прерывания между выбором страницы 1 и записью 1 в PIE, эта 1 отправляется в зеркальный относительно PIE регистр PIR и устанавливает этот самый флаг, который сразу же опять и вызывает прерывание
абсолютно понятно и логично, ура
теперь осталось понять в каком месте обработчика портится страница, т.е. бит 5 регистра статуса

единственная портящая статус команда тут MOVF, и портит она только бит 2
да и в принципе, если эта команда портит биты выбора страниц, то как ей пользоваться на ненулевых страницах?
на всякий случай повторюсь, buf1 и 2 имеют адреса 70Н и 71Н для однозначной адресации независимо от текущей страницы
так что половина непонимания остаётся пока

три тысячи чертей, они опять упрыгали на 2 минуты вперёд, с новым обработчиком прямо скопипастеным с даташита, со всеми этими SWAPами

вобщем точно выходит что обработчик не восстанавливает обратно 1 страницу, а оставляет 0 на которой сам работал

угу, абсолютно точно так, набил 50 нопов между выбором 1 страницы и записью в PIE1 (чтоб расширить окно ошибки), так прямо на глазах по 2 минуты плюсует

Сообщение отредактировал ddd-ekb - Oct 29 2015, 14:23

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

ура, всё, раскурил до конца
PCLATH не при делах, как и программная память
проблема как и было в итоге определено в неверном сохранении обработчиком номера страницы регистров
причина в том, что у 73\74 нет общеадресуемой памяти, в отличии от 76\77, а даташит общий
вот и не отразил сходу этот момент

усё, спасибо за попинывание и всякие мысли, тему закрыть, автора в бан