On Thu, Mar 10, 2011 at 8:13 AM, Olin Lathrop w= rote: > It's rather hard to believe the hardware isn't setting INT2IF. =A0Instead= of > invoking strange gremlins in the PIC, think about what in your firmware > could cause this symptom. =A0Could something be resetting the flag? =A0Co= uld the > flag be getting set but the code not looking at it or getting to it? I agree, I'm sure I've done something that's preventing this from working properly. I'm trying to figure out what that is. > Is this UART data sent from the INT0 interrupt? =A0If so, then it would b= e > spinning on the UART ready in the interrupt routine, which is not a good > idea. =A0Usually it's best to handle the immediate hardware issue in the > interrupt routine, then leave state around so that the foreground code ca= n > do more time consuming but less latency-sensitive processing later. =A0It > sounds like sending this burst of data over the UART falls into the latte= r > catagory. No, the INT0 handler just triggers the first byte. The subsequent ones are sent via a timer interrupt. > Are you really sure the INT0 interrupt routine properly saves/restores al= l > state it trashes, including any FSR registers? =A0Again, it sounds like y= ou're > trying to do too much in the interrupt, which also leaves more possibilit= y > of trashed state or calling a common routine that is not really re-entran= t. At the top of my ISR I save WREG, STATUS, and BSR. Interestingly enough, I recently ran into a problem where WREG was getting trashed in the ISR and the context restore wasn't working. This of course only happened once in a while. I started using the fast return stack and it seems to be ok now. I've never seen that before, and I've used the same context save code many times. For WREG, on entry I execute a "MOVWF W_Temp", and on exit "MOVF W_Temp, W". As for the FSR, I am only using one of them and that is in the ISR. > Since you're on a PIC 18, how about using the high priority interrupt for > INT0 and the low priority for INT2? =A0Why is INT0 so high priority if it= 's so > slow (83ms) and is going to do something slow like send data over the UAR= T? > It sounds like INT2 is actually your higher priority. What's important is the latency of dealing with INT0. That data burst triggers something visual, and I'm trying to get the jitter to as low as possible. That's why I'm trying to deal with INT2 without going into the ISR. If an INT0 pulse happens while I'm already in the ISR, there is a delay and that effect is visually noticeable. I will look into using the priority interrupts. I'm a bit concerned about my context saving problem listed above, as I can't use the fast return stack for both levels, and something seems to be wrong occasionally with my regular context save. >> Instead of polling, I've >> tried dealing with it in the ISR. > > So now "it" is back to being INT2, not INT0? Yes, sorry for the ambiguity there. I tried having INT2 trigger an interrupt, then I set a flag to deal with the parallel transfer in the main line. I thought that perhaps something funny was happening because I was polling INTCON3, but I still ended up with the same stall condition. Thanks, Josh --=20 A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. =A0 =A0 =A0 =A0 -Douglas Adams --=20 http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .