INT_EXT firing off on startup, getc locking up

[evsource]

Hi,

I'm using INT_EXT to detect incoming data from another PIC. That other PIC does nothing for awhile, however, as soon as I enable the EXT_INT interrupt, the ISR fires off and locks up on the getc (because there isn't anything there to get).

I'm puzzled why it fires off.

I've tried an input call for PIN_B0 to make sure it is set as an input on init, I've tried changing ext_int_edge from H_to_L and L_to_H, all without results.

A workaround was to set the timeout to 1s in the #rs232 statement. However, I'd like to know why it's doing that.

[ckielstra]

Compiler version?
PIC type number?
Example code?

It is good practice to clear an interrupt before enabling it, do you do that?

[Ttelmah]

Ongoing to Ckielstrs's comment, not only is it 'good practice', but if you change the interrupt edge, it is _essential_.
The sequence should be:
Set the interrupt edge.
Clear the interrupt.
Enable the interrupt.

The normal way to code the interrupt handler, if using software RS232 (which your comment about 'getc' suggests), is as the first instruction in the handler, to use if(kbhit), to verify that there is data arriving (for the software RS232, this is 'true', if the input line is low, reflecting the start bit being present), to avoid problems from possible triggers by noise etc..

Best Wishes