IOC flag triggered when PIC is unplugged...?

[Demon]

16F18877

Any idea why it would do that?

The PIC is running normally, and then the IOC flags get set when I pull the USB cable on the MeLabs programmer (or unplug the header).

I know my encoders can jitter, but I'm not even touching them.


EDIT: My configs for brown out in case it helps:

_BOREN_ON & _BORV_LO

[richard]

i guess it begs the questions
what ioc flags were triggered ?
what pins had any ioc functions active?

[Demon]

IOC_COM1_Swap_flag          var IOCAF.4
IOC_COM2_Swap_flag          var IOCCF.1
IOC_NAV1_Swap_flag          var IOCBF.5
IOC_NAV2_Swap_flag          var IOCBF.2

These, at random.

Only IOC was used, no other peripherals used on these pins.

I tried external pull-ups just now, in case the internal were just borderline, but that didn't make a difference.

EDIT: Using this wiring:

[Demon]

These are pushbuttons, not rotary encoders with wonky shafts that can jitter whenever the cat farts.

[Demon]

I'm certain it has something to do with voltage levels as the PIC loses power.

IOC flags are randomly triggered when VDD is cut with a switch, but not on MCLR.

Values are READ from DATA at PIC start-up. IOC flags on pushbuttons are used to swap values left to right, then WRITE back to memory.* By the end of the video, all values have swapped places without pushing any buttons.

[richard]

Ceramic bypass/decoupling capacitors are often better .

IOC flags on pushbuttons are used to swap values left to right, then WRITE back to memory

a particularly bad practice, you should always check that it was an actual keypress [ in that was held for a definitive time] before actioning it

key activity should be ignored until power is stable

[richard]

That's what the IOC flag was used for; to check if a button was activated.

That is a false assumption, all the IOC flag says is that a edge was detected, you need way more info to determine if it was a valid key press, at a minimum you need to know if its still "active" and if it was "active" for a reasonable time. no simple hw debounce solution will do all the work

don't forget a 0.000000025S [thats 25nS ] pulse can trigger an ioc event , would you call that a key press
how about 25uS what about 1mS , for my money i would ignore anything less than 50mS
glacially slow for a Pic@32MHz

ps , switches on long leads and breadboards are potentially difficult cases also

[Demon]

That is a false assumption, all the IOC flag says is that a edge was detected, ...

I know that now.

... no simple hw debounce solution will do all the work...

The 74HC14 with Bourns' debounce was doing very well. I'm rewiring that back in now to redo testing.

... for my money i would ignore anything less than 50mS...

I'll post results when I have everything back up and running. It was surprisingly stable before I migrated to a 16F18877.

... switches on long leads and breadboards are potentially difficult cases also

Switches and encoders are all mounted on headers, same for power jack, USB connector and 7805.

The only leads for switches will be from 74HC14 to PIC, and I keep those on 2 breadboard area maximum. The only PIC with long leads is for the LCDs.

The USART leads (in white) will branch out from the USB PIC out to the SW and ENC PICs (the END lead is 5in straight line, so about 6in when strung out).

[richard]

It was surprisingly stable before I migrated to a 16F18877.

to get away from all the needless 7416 chips plus the flexibility of pps as a bonus

[Demon]

to get away from all the needless 7416 chips plus the flexibility of pps as a bonus

That was my original goal, to reduce cost, complexity and real estate.

I gotta admit, PPS, was a neat bonus. I was truly impressed with the 16F18877.

[Ioannis]

I would not give up on the 18877 chip. Sometimes the view seems great but has pitfalls and all you need is to sleep on this. Next day will come the aha moment!

Ioannis