Hi Genome I apologize for butting into the thread (I have similar issues with loading two ISRs high) but you've got me and Dumitru a little confused with each other............but it seems like good advice for both of us regardless. With my similar issue the vars that are causing me the troubles are volatile (they are set by another ISR that reads button presses/switch closures on the port) and always have been because they originate/are set due to changes on inputs. Now I haven't tried removing the optimizations (I'm more than a little fuzzy on which optimizations settings do what exactly or which ones I'm using) but I certainly plan to as soon as time permits. Just for the record I'm in no position to turn down advice from anyone or to not try what ever is offered up. I'm just very pressed for time for the next few days so stand by I will let you know if it does or does not work for me. Let add how grateful I am for your help everyone else's! "Genius has its limitations, but stupidity knows no bounds" Phillip Things should be as simple as possible but no simpler Phillip Coiner CTO, GPS Source, Inc. Your source for quality GNSS Networking Solutions and Design Services, Now! -----Original Message----- From: piclist-bounces@mit.edu [mailto:piclist-bounces@mit.edu] On Behalf Of Genome Sent: Tuesday, December 05, 2006 12:39 PM To: piclist@mit.edu Subject: Re: [PIC] Problems with C18 interrupt code have you tried to use volatile as with my previous post.. use volatile in variables you use both in the interrupt and the main loop.. Its probable that ur using optimizations.. and the compiler is optimizing your code removing some of the code generated by "if and else or while" statements... or simply just try to disable all optimizations in the project->BuildOptions and see what happens... I did had a problem the same way yiu had... and this solved it... I dont see anything other than this in the code you posted that would cause the problem.. I dont think the save context thing is your problem as you dont want to save and restore the pulse_count variable because you want it modified in the interrupt routine and the change be seen on the main loop.. "Phillip Coiner" wrote in message news:003101c7189d$8fbba540$d2b5a8c0@mygpssource.net... Hi Jan-Erik In my case if I were to strip it out there is no way to check to see if the problem exists. The trouble is not that the ISRs don't read the serial ports and put the correct data in my buffers in either case the basic function of the ISRs works fine. The problem is weird behavior it causes with the rest of my code. What I mean by that is that the program will break out of loops when it should not. I can set a break point as I exit a loop. When I examine the variable that controls the exit from the loop it is not in the range to leave the loop but the code seems to have a mind of its own. So it wanders aimlessly doing everything it can at random. If I look at the serial port[s] buffers the data are just fine no dropped characters the read and write pointers are right where I expect them i.e. not pointing at strange locations in memory. If I load the one or the other ISR low then it straightens up and everything works as expected. This makes me think that the trouble is with the compiler not handling the entry and exit of the ISRs and corrupting the stack or registers is a good likely suspect. I have the gun to my head to finish this project I on and don't have time to check it out just yet (and I'm not really sure how to do it but I reckon I can start saving/restoring stuff and to see if it might fix my troubles) Phillip Things should be as simple as possible but no simpler Phillip Coiner CTO, GPS Source, Inc. Your source for quality GNSS Networking Solutions and Design Services, Now! -----Original Message----- From: piclist-bounces@mit.edu [mailto:piclist-bounces@mit.edu] On Behalf Of Jan-Erik Svderholm Sent: Tuesday, December 05, 2006 10:27 AM To: Microcontroller discussion list - Public. Subject: Re: [PIC] Problems with C18 interrupt code Hi! If possible, strip your application down into the simplest code possible that still shows the same "error". In 9 cases out of 10, the problem is solved at the same time... :-) Jan-Erik. Dumitru Stama skrev: > TR> Dumitru, > TR> Can you generate an asm output (lst file or whatsoever) so that some of us > TR> may could spot something that may not obvious looking at the source code > TR> only and/or a compiler problem? > TR> Tamas > > Sure, i have the lst file at home. In a few hours i will post it. The > only problem is it has ~40k and just to be sure i will not annoy > anyone i will upload it on a web page and then post the link here. > Thank you for your help > -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist