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, а даташит общий
вот и не отразил сходу этот момент

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