Button function problem after waking from sleep

[spcmicro]

I have an application that uses switch closures on 3 PORT B inputs. The inputs have external pull ups and the switch connects the input to ground when pressed. I am using the Button function to debounce the keys.

Everything works as expected before I put the PIC into sleep mode. One of the inputs, PORTB bit 4 is used as a wake on change input. If I put the processor into sleep mode and then wake it up with a key press on the switch connected to PORTB it wakes up just fine. The problem is that it after awakening the Button function sees the key as down even though it has returned to the high state, I have a delay after the waking up of 2 seconds that should take care of any bouncing issues when the key that takes it out of sleep mode is released. If I put a breakpoint in the code where the Button function thinks it sees the key down, a logic level 0, the value of PORTB in the watch window shows that input is high as expected.

Is this a problem with the Button function? The data sheet for the PIC that I'm using, the PIC18F4680, states on page 132 that the polling of PORTB is not recommended when using the interrupt on change feature. Is this the problem?

[Acetronics]

Hi, Spc

When using interrupt on portB ( with Wake up or not ...), you HAVE to read PortB in your interrupt to cancel what Microchip data call the " Mismatch condition" ...

This furiously looks to be a reason for you to get such behaviour
I'd recommend you to read the relevant chapter of your Pic Datasheet ...

Also think when you push the button is ONE interrupt reason, but if you release it ... it is ANOTHER interrupt reason ...

Alain

[spcmicro]

Hello Alain,

Thank you for your input. I have read the data sheet in detail. I have been programming embedded processors since 1981 and have become very intimate lately with the PIC data sheets. I know it's like asking if the power switch is on so I take no offense.

I had already tried the read of the PORTB data in my interrupt handler but it caused a different problem, which I didn't write down. I'll put it back in so that I can give you the results of that test. I would also think that the first read of the poirt after the interrupt would clear the comparison state in the PIC..

In my interrupt handler, I disable the interrupt immediately because I don't care about the interrupt on port change after the PIC is woken back up. With the interrupt disabled, the changes on PORTB don't generate any more interrupts. I don't know what this would have to do with the Button function not reading the port properly when the watch window seems to display the proper result.

Thanks again... .. .