Yes I agree. I do the same thing of sorts by stripping out every piece of code that is not necessary and then go thru it slowly and carefully and then adding code pieces back in till it breaks. What bothers me is first off....copied code from another project working in the same chip, second is the only reason the ISR can't be executed is either the chip is in reset, or the interupt is turned off and neither is true (at least as much as I can prove it so far). But no doubt, it will be something simpy and silly. Jinx wrote: > I would agree.....since I've done this many a time but it does indeed > keep the timers from incrementing (and the LED from flashing) in the > ISR. I can do the return...everything is fine. The quickest (and probably most efficient and character-building) thing you could do would be to go through the code very carefully line by line, assuming nothing, and comment and explain to yourself every instruction and its effect/consequences. When checking your own code for bugs you have to be very disciplined. That's why buggy code presented to the list is usually sorted pretty quickly. An error is often more easily spotted by someone else. It is just too easy to miss errors, like a MOVFW instead of MOVWF, if you assume and skim -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist --------------------------------- Expecting? Get great news right away with email Auto-Check. Try the Yahoo! Mail Beta. -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist