Това, което виждам с дебъгера, е че фалговете не се чистят. Аз имах проверка при влизане в дадено прекъсване дали въпросния флаг е сетнат, но въпреки че дебъгера ми дава флаг 1, тази провека не минава. Предполагам пак не ми изобразява правилно регистрите! Има ли значение кога изчисвам флага на дадено прекъсване? До сега го правех накрая - примерно чета UART буфера и чак тогава изчиствам флага. Предполагам, че понеже имам няколко приоритета, когато влезе в едно прекъсване и друго го override-не (по-висок приоритет), се изпълнява второто без да се върне в първото за изчистване на флага(което не е логично, но аз така си го обяснявам!). Реално само 2та UART-a са по-дълги за изпълнение, защото чета няколко пъти буфера. Гледам, че единия UART е с най-нисък приоритет 3(понеже е на 9600), а таймерите са с 5, но другият UART е с приоритет 6 и прави същото парче! Него няма какво да го override-не. В момента разкарах проверката за флаг и първо чистя въпросния флаг. Ще тествам днес да видим дали ще направи същия проблем.
Ако се сещаш нещо за ситуацията, която описвам, моля да споделиш!
Благодаря!

Нещо не съм написал правилно прекъсванията! До колкото разбирам, флагът трябва да се чисти след като се елиминира причината за прекъсването! Т. е. трябва да го правя след като прочета буферите. Само за таймерите не съм съгурен защо става, но може би ако изчиствам прекъсването след като сетна PR регистъра ще стане работа...
Оставам отворен за идеи!

основен принцип за приоритети в общия случай:
късо време за обработка - висок приоритет... (и все пак зависи от логиката)

не знам какво става в системата ти - пасни код

Времето е късо, но примерът, който си дал по-горе не е ОК. При всички прекъсвания първо трябва да се обработи причината причиняваща прекъсването, а после да се забърше флага. Прекъсването за грешка при UART е на обратно и аз го взех на готово. Промених го и за сега нямам проблеми. Предполагам, че е ставала някаква врътка с приоритетите и понеже не е се чете буфера, процесора постоянно влиза в това прекъсване. И обяснява защо ставаше произволно - като стане фал по UART.
Благодаря!

нямам си на идея какво си писал... имай на в предвид че никога не ми се е случвало да чукне оверфлоу грешка по уарта
все пак 24-ките имат 4 байта, а 32-ките 8 байта фифо буфери, което ти дава повече време за обработка на прекъсването

Не мога да обясня! Имам абсолютно същия код за PIC18 и там даже не правя проверка за грешки и работи чудесно. Тук, освен да променя мястото на изчистването на флага, друго не съм пипал и проблемът го няма...

Ъпдейт по темата!
Горепосоченият проблем явно се дължи на някакво буфериране на данни. Почти сигурен съм, че е в MPlab. Става следното - програмата си работи и достига някакъв брейк поинт! Но понеже контролерът е закачен към други у-ва(през двата UART-a), те продължават да си пращат данни. Съответно тези нови данни се буферират някъде и след като продължи програмата трябва да се изчетат, което обаче отнема време. Доста!
Тук предполагам Wizard има повече инфо! Може би ако ги нямаше външните източници, голяма част от бъговете и крашовете нямаше да ги има...

няма буфери за брек-поинт

бъговете и крашовете са от JAVA, лапа много памет и върви БААВНО

Това е класически проблем - периферията тича а дебъга спира ядрото и то не може да обслужва. Смислените процесори имат някой екстри - например да спират таймерите и други периферии при спиране на ядрото (на брейкпоинт). С уарта няма да помогне (освен ако има flow control ? ) Но истината е че спреш ли на брейкпоинт не можеш да си сигурен че след това като пуснеш няма да е омазано нещо. Затова спираш, анализираш каквото си видял, ресетваш/спираш, слагаш нови брейкпоинти (и променяш/билдваш ако искаш) и пуснак отначало. В твоя случай това значи да рестартираш и насрещния контролер който ти праща по уарта - което е лесно ако са закачени на jtag chain и ги контролираш от един дебъгер. Ама това дали мплаба го може е много съмнително?
А джавата може да е проблемна само ако са ровили майсторите от майкрочип... Същата жава клати хиляди други приложния (примерно - еклипс) и няма кахъри. Същите простотии ги имаше и преди джавата да им стане проблем - още в 8-цата и по-ранните на мплаб-а.
И макар опита ми с нетбиймс да не е голям извън мплабх, не съм видял проблеми в чистия му вид (java развой и RCP приложения на базата му). Затуй си мисля че "подобренията" с произход Финикс ще да са тегавото.

като пуснеш Еклипса - виж си в таск меринджея дали имаш Java(TM) Platform....

В смисъл? Ако твърдиш че не е джава приложение ще е голям смях.
Еклипсът ми ползва локален JRE в неговата папка. Редът на търсене на JRE (java runtime env) е първо в локална папка където е еклипса с име "jre", после на път сочен от JAVA_PATH променлива на обкръжението.
Пускането става от платформено специфичен Launcher което под виндоус е exe - то наглася обкръжението и пуска джава класа който е указан в ini-то.

не съм казал че не е писан на Java...
еклипса ми лапа 200 меги, а хикса 2 ГИГИ, чак се чудя кво намушиха в тея гиги за под 1к сорс на XC8

Да питам- в моя телевизор ли е грешката или в MPLAB?
Ситуацията е горе-долу следната:



Това горното работи докато N1 е по-малко от 4096, ако е по-голямо най-старшия байт го прави на 0xFF ?!?
В опциите на MPLAB XC8 е зададено long = 32bit (по подразбиране е 24), така го и компилира. Чипа е PIC16F1938. Изместването надясно си работи коректно.

то не е много ясно какво точно искаш да направиш с този код,
със същия успех можеш да напишеш само:
Number = N1 | N2;

може би искаш да кажеш:
Number = N1;
Number = Number << 16;
Number = Number | N2;

Да, извинявам се, поправих го.
То и с един ред се прави, ама съм направил грешка като съм го писал по-бавно:
Number = (N1<<16)|N2;