This is really freaky... like Ghost-in-the-PIC freaky... read on.
So I'm experimenting with interrupt-on-change and sleep functions with my 16F690. I used a speaker to beep as indication that sleep mode has exited (due to interrupt).
I left it powered on to make sure it stayed in sleep mode, and to make sure my wiring was good, and no components failed in the final product. All good.
I have a power strip running to my workbench, and the PIC is about a foot away from it. I have a fan plugged into the same outlet as the power strip.
Check this out.
When i turn the fan on or off, while the blade are still moving, AN INTERRUPT-ON-CHANGE IS TRIGGERED IN THE PIC!!! Note that the fan is about 3 feet away from the PIC (and through a wall). This weird behavior only happens when the power strip is plugged in.
How can this behavior be explained?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You possibly need to add a capacitor between the +5 and Gnd feeds into the PIC chip to smooth out any power fluctuations and noise picked up as interference.
For example:
One as a decoupling capacitor (of about 20 to 100 uf) to clean up your power supply if using a transformer.
One as a debounce capacitor (of about 0.01 (10nF) to 0.1 uf) to keep slight fluxuations of the power from resetting the chip.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The chip isn't being reset, only an interrupt-on-change. I have a 100uF capacitor to smooth power coming from the +5v regulator, as well as a .1uF capacitor right between Vdd and Vss (gnd) next to the PIC, as well as a 47uF capacitor smoothing out power coming from the battery source (+12v and gnd).
I'm figuring AC electrical noise is feeding back into the power lines from the fan, and the power strip carries this noise (close to the PIC project). However, I do not know why this "noise" is triggering an Interrupt on Change inside the PIC?
I was thinking maybe I could neatly wrap the project up in aluminum foil to act as a Faraday cage to stop such interference?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Won't you have to connect your Faraday aluminum foil cage to ground for it to work ? Does that have to be the house ground, using for example the round pin on the power strip?, or will circuit ground do ?....I would start with circuit ground and see what happens.
Maybe there is a flaw in your PIC chip? Does it still happen if you swap out the chip for another of the same type?
Will your final implementation encounter such a situation, or it this environment influenced by the power strip only happening in your test setup?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The final implementation will be in an automobile, so I doubt such interference will happen. I was curious as to why it was happening, and wondering if it was a more broad problem that could be encountered in other, however dissimilar, situations. I havent tried swapping it out for another chip and testing it, as the final product is finished and assembled.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Johnny,
this is definitively a problem of your power supply. Just do what the above comments are recommendig: Add filter-caps before and after your 5V regulator to eliminate noise and spikes on your supply. Additionaly solder right over the supply pins of the pic ceramic cap of 0.1uF direct to ground with wires short as possible. Even you install your device in a car you have to do this. The supply in a car is even 'dirtier' then your main supply.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have done this. However, my power supplies are different sources.
I ran the PIC project on 12 AA batteries, going to a +5v regulator with filter caps as per the regulator data sheet, plus the suggested .1 uF cap right at the PIC Vcc and Vdd terminals.
The fan was on the AC circuit of my apartment. The interference is being transmitted wirelessly. But why, and perhaps how to fix this for future scenerios, is my question.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Modern CMOS devices have two properties that can get you into trouble and create all kinds of weird glitch issues.
1. The input impedance is ultra high (hundreds of Meg Ohms), with very low input capacitance.
2. Modern Fabrication processes create very fast CMOS with response times in the low nanosecond range (pico seconds for some chips).
Given these two facts, and the fact that ANY unterminated input will act like an antenna, your glitch issue is more than likely being caused by a stray signal coupling into an unterminated pin.
Also remember that pins connected to other CMOS devices which have Tri-Stated to a high impedance state count as unterminated.
On a quick-connect-strip type breadboard an unterminated pin will have a chain of contacts a centimeter or two long to couple stray signals, even if it's not connected to a wire.
If you have an unterminated wire connected to the pin, it’s even worse, and you will be able to trigger a stray data transition from several feet away if something generates an E-Field spike (E-field is electrostatic and is capacitive coupled).
If a pin is grounded through several inches of wire, with the ground (or near ground) at the far end, it can act as an H-Field antenna and pick up an electromagnetic spike (H-field is electromagnetic and is magnetically coupled).
Beginning engineers almost always get bit by having improperly terminated pins in their projects.
Some Pspice CAM software will auto-route unused pins to ground, to prevent just the kind of problem you are seeing, but that can also cause issues, because another solution popular with some developers, is to set unused pins as outputs to prevent them from picking up stray signals.
One system brought to me for debugging, had horrible thermal problems. It turned out that the hardware designer had grounded all the unused ports, and the software engineer had set them as outputs without bothering to make sure that he also wrote a zero to the port. So several gates on the port were trying to drive a ground high, and making the chip dissipation go through the roof.
You can get in trouble the other way just as well by tying unused pins to VCC then accidentally trying to drive them low in software.
So here are some guidelines to avoid stray glitch problems-
1. Unused inputs should be tied to ground or VCC.
2. Unused flexible I/O ports can be set as outputs to guarantee against them creating stray interrupts, but often power consumption will be lower if they are just left as inputs and grounded.
Be careful about the issue I mentioned above, and on flexible I/O ports either ground them, or set them as outputs, and you will eliminate 90% of your weird interrupt issues.
Physically grounding the unused pins gives better ESD protection, but if there is any chance that the software will go nuts and set the pin HIGH during the development of the software, you might want to ground the unused port pins through 1K resistors, which will give enough pull-down to avoid glitch issues, but will not exceed the pin drive limits if accidentally driven high.
Hope this helps
S.B.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Wow, that's interesting. Thanks for the information!
All of my ports with their interrupt-on-change enabled are grounded with a 10k resistor (with an interrupt occurring when the port is pulled high by a 1k resistor).
My chip (16F690) has ports A and B that are able to Int-on-change. I have software selected only certain portA's to be Int-on-change (A.0, A.1, A.2, A.5). The other portA pins are used as: MCLR, analog input.
I have left 3 of the 4 port B's unconnected (and haven't set them as in or out in the software) Also, I am using one of the portB's (portb.7) as a output (driving a transistor).
Is this being caused by the EM field acting on the unconnected portB's, even though I haven't set them to be Int-on-change? Or interference with some of the PORTA ports being used for other things (analog, MCLR)?
FWIW, the interrupt is what wakes the chip up from sleep.
Thank you.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Curious to know if you tried the foil thing? Or in lieu of that, putting some tin/metal box over the project. Some stabs in the dark: Twisting the power supply lines, a choke on the supply line, or possibly a ferrite bead/collar?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have found that the electric motors for the vehicles power windows (in the vicinity of the project box) causes an interrupt.
I will try the foil thing, and twisting the power wires this weekend.
I however do not have a ferrite bead/collar. What do those do anyways? I will take some old USB wires apart of use their ferrite collar (same thing, right?)
Thanks again everyone for the support.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is really freaky... like Ghost-in-the-PIC freaky... read on.
So I'm experimenting with interrupt-on-change and sleep functions with my 16F690. I used a speaker to beep as indication that sleep mode has exited (due to interrupt).
I left it powered on to make sure it stayed in sleep mode, and to make sure my wiring was good, and no components failed in the final product. All good.
I have a power strip running to my workbench, and the PIC is about a foot away from it. I have a fan plugged into the same outlet as the power strip.
Check this out.
When i turn the fan on or off, while the blade are still moving, AN INTERRUPT-ON-CHANGE IS TRIGGERED IN THE PIC!!! Note that the fan is about 3 feet away from the PIC (and through a wall). This weird behavior only happens when the power strip is plugged in.
How can this behavior be explained?
You possibly need to add a capacitor between the +5 and Gnd feeds into the PIC chip to smooth out any power fluctuations and noise picked up as interference.
For example:
One as a decoupling capacitor (of about 20 to 100 uf) to clean up your power supply if using a transformer.
One as a debounce capacitor (of about 0.01 (10nF) to 0.1 uf) to keep slight fluxuations of the power from resetting the chip.
The chip isn't being reset, only an interrupt-on-change. I have a 100uF capacitor to smooth power coming from the +5v regulator, as well as a .1uF capacitor right between Vdd and Vss (gnd) next to the PIC, as well as a 47uF capacitor smoothing out power coming from the battery source (+12v and gnd).
I'm figuring AC electrical noise is feeding back into the power lines from the fan, and the power strip carries this noise (close to the PIC project). However, I do not know why this "noise" is triggering an Interrupt on Change inside the PIC?
I was thinking maybe I could neatly wrap the project up in aluminum foil to act as a Faraday cage to stop such interference?
Won't you have to connect your Faraday aluminum foil cage to ground for it to work ? Does that have to be the house ground, using for example the round pin on the power strip?, or will circuit ground do ?....I would start with circuit ground and see what happens.
Maybe there is a flaw in your PIC chip? Does it still happen if you swap out the chip for another of the same type?
Will your final implementation encounter such a situation, or it this environment influenced by the power strip only happening in your test setup?
The final implementation will be in an automobile, so I doubt such interference will happen. I was curious as to why it was happening, and wondering if it was a more broad problem that could be encountered in other, however dissimilar, situations. I havent tried swapping it out for another chip and testing it, as the final product is finished and assembled.
Hi Johnny,
this is definitively a problem of your power supply. Just do what the above comments are recommendig: Add filter-caps before and after your 5V regulator to eliminate noise and spikes on your supply. Additionaly solder right over the supply pins of the pic ceramic cap of 0.1uF direct to ground with wires short as possible. Even you install your device in a car you have to do this. The supply in a car is even 'dirtier' then your main supply.
I have done this. However, my power supplies are different sources.
I ran the PIC project on 12 AA batteries, going to a +5v regulator with filter caps as per the regulator data sheet, plus the suggested .1 uF cap right at the PIC Vcc and Vdd terminals.
The fan was on the AC circuit of my apartment. The interference is being transmitted wirelessly. But why, and perhaps how to fix this for future scenerios, is my question.
Modern CMOS devices have two properties that can get you into trouble and create all kinds of weird glitch issues.
1. The input impedance is ultra high (hundreds of Meg Ohms), with very low input capacitance.
2. Modern Fabrication processes create very fast CMOS with response times in the low nanosecond range (pico seconds for some chips).
Given these two facts, and the fact that ANY unterminated input will act like an antenna, your glitch issue is more than likely being caused by a stray signal coupling into an unterminated pin.
Also remember that pins connected to other CMOS devices which have Tri-Stated to a high impedance state count as unterminated.
On a quick-connect-strip type breadboard an unterminated pin will have a chain of contacts a centimeter or two long to couple stray signals, even if it's not connected to a wire.
If you have an unterminated wire connected to the pin, it’s even worse, and you will be able to trigger a stray data transition from several feet away if something generates an E-Field spike (E-field is electrostatic and is capacitive coupled).
If a pin is grounded through several inches of wire, with the ground (or near ground) at the far end, it can act as an H-Field antenna and pick up an electromagnetic spike (H-field is electromagnetic and is magnetically coupled).
Beginning engineers almost always get bit by having improperly terminated pins in their projects.
Some Pspice CAM software will auto-route unused pins to ground, to prevent just the kind of problem you are seeing, but that can also cause issues, because another solution popular with some developers, is to set unused pins as outputs to prevent them from picking up stray signals.
One system brought to me for debugging, had horrible thermal problems. It turned out that the hardware designer had grounded all the unused ports, and the software engineer had set them as outputs without bothering to make sure that he also wrote a zero to the port. So several gates on the port were trying to drive a ground high, and making the chip dissipation go through the roof.
You can get in trouble the other way just as well by tying unused pins to VCC then accidentally trying to drive them low in software.
So here are some guidelines to avoid stray glitch problems-
1. Unused inputs should be tied to ground or VCC.
2. Unused flexible I/O ports can be set as outputs to guarantee against them creating stray interrupts, but often power consumption will be lower if they are just left as inputs and grounded.
Be careful about the issue I mentioned above, and on flexible I/O ports either ground them, or set them as outputs, and you will eliminate 90% of your weird interrupt issues.
Physically grounding the unused pins gives better ESD protection, but if there is any chance that the software will go nuts and set the pin HIGH during the development of the software, you might want to ground the unused port pins through 1K resistors, which will give enough pull-down to avoid glitch issues, but will not exceed the pin drive limits if accidentally driven high.
Hope this helps
S.B.
Wow, that's interesting. Thanks for the information!
All of my ports with their interrupt-on-change enabled are grounded with a 10k resistor (with an interrupt occurring when the port is pulled high by a 1k resistor).
My chip (16F690) has ports A and B that are able to Int-on-change. I have software selected only certain portA's to be Int-on-change (A.0, A.1, A.2, A.5). The other portA pins are used as: MCLR, analog input.
I have left 3 of the 4 port B's unconnected (and haven't set them as in or out in the software) Also, I am using one of the portB's (portb.7) as a output (driving a transistor).
Is this being caused by the EM field acting on the unconnected portB's, even though I haven't set them to be Int-on-change? Or interference with some of the PORTA ports being used for other things (analog, MCLR)?
FWIW, the interrupt is what wakes the chip up from sleep.
Thank you.
Curious to know if you tried the foil thing? Or in lieu of that, putting some tin/metal box over the project. Some stabs in the dark: Twisting the power supply lines, a choke on the supply line, or possibly a ferrite bead/collar?
I have found that the electric motors for the vehicles power windows (in the vicinity of the project box) causes an interrupt.
I will try the foil thing, and twisting the power wires this weekend.
I however do not have a ferrite bead/collar. What do those do anyways? I will take some old USB wires apart of use their ferrite collar (same thing, right?)
Thanks again everyone for the support.
Better yet, http://www.freescale.com/files/microcontrollers/doc/app_note/AN1259.pdf
Thought of the twisted pair thing, like maybe cat5 wire or cable might cancel your input noise, whether power supply, buttons or ?
Salvaged an old Motorola car phone booster, it was in an all aluminum enclosure, and if I remember correctly the micro had a shield over it.