-
Quote
In the processor circuit all voltages indicate the fet must be off yet isn't.
If you measure essentially 0V on the gate in circuit and you have verified LED turns completely off when you ground the gate, physically, then perhaps you should scope your FET gate? You must have a low duty cycle pwm going on??
You mentioned an optocoupler. Be sure to take your ground from the FET source pin when you scope it. This ain't rocket science. I don't believe in no ghosts.QuoteYou may want to re-read what i wrote earlier regarding the Arduino Due use case: "... That case is made simple by the fact that the indicator LEDs are idle at start so there are no switching events at all. ..."
So you think... You can be sure as you want what your Arduino is or isn't doing. But something is moving the FET gate. Or you are measuring voltage incorrectly. Are you saying you have a function generator but no scope?
If I'm wrong, fine. But if you haven't checked it, yet, this is the only logical explanation, IMO. You can speculate about unicorns all you want, but turn over the first rock at your feet, first. -
Perhaps it's simply the mosfet is too sensitive. What voltage does the GPIO pin output when it's logically 0 ? It could be as high as 0.8V for example.
That won't do anything much to the static condition because the fet gate is essentially a capacitor with zero bias current. The only thing affected is the voltage division ratio between the drive and grounding resistors. And if you read the earlier posts that has been tried already. Combinations of 10/1k, 10/10k, 100/1k, 100/10k have all been tried with zip improvement in the problem.
I'd try increasing the 100ohm resistor.
But i agree that the fet could simply be too sensitive for some reason. Maybe a bad batch or something because the 2N7002 should take at least a volt at the gate before significant turn on. When i have time i will replace one with something else and see what happens.A long shot but since you are reusing the TxD and RxD pins, you don't have a bootloader or something that is leaving the UART enabled do you?
No. Good suggestion but that is not it. No bootloader in the non-Arduino device. UART functionality is not programmed as is apparent from the non-Arduino source in an earlier post.I had similar problem long time ago...Just replace gate drive resistor with 10k and remove resistor from gate to ground and it will work.
Now that is just plain silly.
Sorry for my bad english.
Not unless there are elves somewhere pwming the output. Where would such a pwm come from? I am the master of my code at least in the non-Arduino unit and i promise you there is no secret pwm going on. And in the Arduino unit the outputs are held statically at low level. There is no modulation at all for those pins in the code. I promise you i would know.QuoteIn the processor circuit all voltages indicate the fet must be off yet isn't.
If you measure essentially 0V on the gate in circuit and you have verified LED turns completely off when you ground the gate, physically, then perhaps you should scope your FET gate. You must have a low duty cycle pwm going on??
But yes, i have scoped all the signals multiple times and no secret pwm is going on. In fact the signals are quite clean so you would assume everything must work. Only not.
-
If you scoped it properly. At the actual gate and source of the FET. At your fastest time base and trigger set to somewhere south of the gate threshold, with the probes and channel voltage divisions set right. And there is no signal there. Gate is always at the same potential as the source. And the LED is dimly lit, but it goes out when you physically ground the gate, changing nothing. Then you don't have a problem. You have something really interesting going on, indeed!Quote
I am the master of my code
These are words that will never cross my lips, again.
QuoteNot unless there are elves somewhere pwming the output.
I call them bugs. Elves, that works, too.
If you are so sure, try tying your AVR LED output pin to the rail (whichever one is supposed to turn the LED off). This won't harm the AVR, if it's doing what you think. (And it probably won't do any harm if it's pwming at such a low duty cycle, either). If this results in a dimly lit LED, then you will know it's the circuit. And thenI will start believing in this unicorn.Who cares what I think? And then, you should start considering a unicorn. RF interference, too fast to scope?
You mentioned an optocoupler. Maybe you need to check this part, next. At any rate, I don't think this has anything to do with the electrical levels of the Atmega. Volts are volts, and you are measuring them as ok.
-
I knew someone would make that kind of commentQuoteI am the master of my code
These are words that will never cross my lips, again.
. My admittedly arrogant claim was mainly targeted at the suggestions of checking for all kinds of n00b level mistakes. While none of us are incapable of error like HAL9000, I want to think myself able to avoid such elementaries in the first place and at least able to find them when they occur nevertheless.
Some code is hastily written and logical errors do creep in, but i have difficulty recalling when coding language or the hardware would have been issues.
-
Sorry, I'm not intending to be a smartass or to give you attitude. Just imploring you to do your due diligence and to rule out any source of human error before getting us all excited about a new and mysterious FET phenomenon. Even "picking up" a non-signal with a scope, you might want to prove to yourself that the scope is setup correctly by picking up a minimally equivalent test signal (because no one has ever made a mistake setting up a scope before!) And I am sorry I took your words out of context, a bit. I know you meant that this problem was not dependent on Arduino libraries.
Personally, for me, it's ALWAYS my own error, and usually my code, until proven otherwise. But I am terrible at coding, and I know it.
And I'm not suggesting it's a n00b mistake, or even your mistake, even if it is the code. There are innumerable ways to get unintended bugs. It might be your compiler, errata, erroneous documentation or header files, or a very un-n00b coding error. I can't read your code, but Psi and jwm_ have mentioned some things that have bitten me, repeatedly. -
Try removing R7 when you see the phenomenon. If the MOSFET still conducts after removing the R7, you have a 2N7002-thyristor
Have you checked the 12V power supply? Is it noisy? Does it contain fast voltage spikes which could couple capacitively to 2N7002 and keep the 2N7002 in conducting state?
You could also try changing the 10K gate resistor to 1K which would make the gate less sensitive to the capacitive coupling and noise.
Pretty weird problem you have in your hands. -
Once I had similar problem.
Then I had no time for experiments and just added resistor from drain to power which probably draw 1mA more when LED was turned on, but also it ate leaked current.
Probably LEDs are very sensitive and can glow even with very small current. Did you measure LED current in OFF state?
-
Oh, another test. If you think your atmega (or is it the optocoupler?) isn't pulling close enough to ground, try manually grounding the FET pin through a diode or three to see if that doesn't still turn the LED completely off!
-
When you measure LED current are you measuring Id of 2N7002 or Iled.
If the opto coupler has been stressed, or you have terminated the opto
coupler substrate to some potential other than floating you could have
Iled > 0 while Idfet = 0, eg. the 2N7002 is in fact off. The opto coupler
could have been damaged, over stressed, and the internal isolated substrates
for the Triac and LED bridged.
Earlier comment to reduce Rgs of 2N7002 due to noise. That infers that
Zgs is set by the 10K, which is not the case, unless Atmel output in high
Z. Its the high or low Rdson of the Atmel PMOS or NMOS output transistor
that will set the noise susceptibility. Still a good idea to make sure the 12 Vdc
supply is clean however.
The upper limiting value of Rgs is established by leakage (Rgs x Leakage << Vthmosfet)
and stray C coupling and wasted power consumption when 2N7002 is being driven high.
For the people who keep implying you need to measure Vgs of 2N7002 to see if its
being driven off, they clearly missed your earlier post where you measured it to be
~ 40 mV.
Regards, Dana. -
Sorry, I'm not intending to be a smartass or to give you attitude. Just imploring you to do your due diligence before getting us all excited about a new and mysterious FET phenomenon. And I took your words out of context, a bit. I know you meant that this was not dependent on Arduino libraries.
No offense taken. I have seen enough to agree with you in principle.
Personally, for me, it's ALWAYS my code until proven otherwise. I am terrible at coding, and I know it.
At the risk of again sounding arrogant, i am not terrible at coding. I have been employed for decades to write code that is often safety-of-life critical, as well as code to control heavy industrial machinery (distributed paper machine drive systems, FMS centers, all manner of heavy manufacturing automation). Some of it in days when the words "best" and "practice" did not usually appear one after the other. You had ruled paper and pencil and precious little else. Learned many things in the school of hard knocks.QuoteAnd I'm not suggesting it's a n00b mistake, or even your mistake, even if it is the code. There are innumerable ways to get unintended bugs. It might be your compiler, errata, erroneous documentation or header files, or a very un-n00b coding error. I can't read your code, but Psi and jwm_ have mentioned some things that have bitten me, repeatedly.
But that is part of my point. The 328P code is absolutely trivial and there is no way in hell it won't do what the source says. If a simple GPIO output was an errata case, the whole product would be unusable for anything. It is guaranteed by experience from numerous earlier cases that the functionality the code exercises does work, and i can see it work by all the tests i care to apply. The output pins switch state exactly when they are supposed to (this has been debugged thoroughly) in both cases.Try removing R7 when you see the phenomenon. If the MOSFET still conducts after removing the R7, you have a 2N7002-thyristor
Now that is one thing i have not tried yet. I will, but it will be tomorrow as today i am busy with other things.Quote
Only superficially. The 12V is nominal only as it is unregulated and varies (it is also clearly higher but that is OK, it has been accounted for). The regulator is a simple LDO so no spiking or ripple appears in the supply, other than the 100 Hz capacitor ripple that is insignificant.
Have you checked the 12V power supply? Is it noisy? Does it contain fast voltage spikes which could couple capacitively to 2N7002 and keep the 2N7002 in conducting state?Quote
Tried it already. No help there.
You could also try changing the 10K gate resistor to 1K which would make the gate less sensitive to the capacitive coupling and noise.Quote
You don't say
Pretty weird problem you have in your hands. Before experiencing this i would have laughingly dismissed such problems as just incompetence if someone else had reported it.
But i have now 4 similar circuits on 2 physically separate PCBs driven by 2 different processors (Atmega 328P AVR on the DIY board and a SAM3X ARM on Arduino Due + DIY shield). 3 of those are visible LEDs and the last is the triac opto. All share 1 thing in common and that is the 2N7002 fet and all have the same problem.
Additionally, the above Arduino drives an essentially identical fet circuit on a separate satellite PCB where the fets control internally optoisolated Toshiba SSRs. Those function perfectly and the only difference is that the fet for there is BS170, not 2N7002.Oh, another test. If you think your atmega (or is it the optocoupler?) isn't pulling close enough to ground, try manually grounding the FET pin through a diode or three to see if that doesn't still turn the LED completely off!
The SAM at least pulls down to ~40mV and if that doesn't turn the fet off then there is no justice. Having said that the fet _does_ turn off if i forcibly ground the gate using a piece of wire. So that would indicate that 40 mV is enough for turn on against everything the data sheet says. At least Fairchild data sheet indicates that not much happens with Vgs below 2 volts. I know from experience that many specimens do conduct between 1 and 2 volts but 40 mV is way below that...
-
Quote
The SAM at least pulls down to ~40mV and if that doesn't turn the fet off then there is no justice. Having said that the fet _does_ turn off if i forcibly ground the gate using a piece of wire. So that would indicate that 40 mV is enough for turn on against everything the data sheet says. At least Fairchild data sheet indicates that not much happens with Vgs below 2 volts. I know from experience that many specimens do conduct between 1 and 2 volts but 40 mV is way below that...
Maybe you misunderstood what I meant. Instead of grounding it with a bare wire short, try shorting it through a diode drop. So you're only pulling it down to 0.6-0.7V, which is higher than the 40mV you are currently measuring. If 40mV is truly letting the FET leak, 0.6-0.7V won't turn it off any further. If clamping through a diode turns off the LED, then you know there's a phantom signal.QuoteThose function perfectly and the only difference is that the fet for there is BS170, not 2N7002.
Well this is eye-opening. It surely sounds plausible that the trench FET and the LED are both extremely sensitive. Maybe a simple thing to try is to change out the FET for another part number?
FWIW, I concur that Figure 10 of the datasheet appears to show less than 1 microamp should be passed with 5V at the drain and gate voltage less than 0.6V under the most extreme circumstance. 1uA could definitely cause a visible glow in a sensitive LED, and your Vds is closer to 12V. But at gate voltage of40mA40mV one would presume much less leakage.
Please keep us posted on tomorrow's experiments! -
I may indeed have misunderstood you. I will try that also when i'm at it next.
Maybe you misunderstood what I meant. Instead of grounding it with a bare wire short, try shorting it through a diode drop. So you're only pulling it down to 0.6-0.7V, which is higher than the 40mV you are currently measuring. If 40mV is truly letting the FET leak, 0.6-0.7V won't turn it off any further. If clamping through a diode turns off the LED, then you know there's a phantom signal.Quote
I have lots of experience with the Atmega328P and it is my default processor for small items. For this current application it is gross overkill but who cares. It does the job (well, YMMV apparently...) and cost is no issue. The point is that i do know how the part behaves and i am confident that whatever silicon errors there lurk, this basic GPIO functionality is not one of them. If that were the case most of my projects would be in serious trouble.QuoteThose function perfectly and the only difference is that the fet for there is BS170, not 2N7002.
Well this is eye-opening. It surely sounds plausible that the trench FET and the LED are both extremely sensitive. Maybe a simple thing to try is to change out the FET for another part number?QuoteThe 328P code is absolutely trivial and there is no way in hell it won't do what the source says. If a simple GPIO output was an errata case, the whole product would be unusable for anything.
I have no experience with this device. I have plenty of experience with GPIO not doing what I think, because it is multipurpose and the configuration not set right. And I have plenty of experience with my code not behaving as I thought, even when it seems to be doing exactly what I want it to!QuotePlease keep us posted on tomorrow's experiments!
I will do that.
-
I am such a sucker. I actually wired up one of my most sensitive FETs (http://www.mouser.com/ds/2/115/DMN65D8L-219098.pdf) to my most sensitive LED (orange, no part number, but it is fantastically sensitive. Diode test lights it up almost as bright as you'd want for an indicator!), no series resistor on the LED, at all.
12V to the anode on my bench psu, limited to 150mA. 1.2K pullup on the gate which is also clamped to the source with a diode. I measured the Vgs at 0.69V. No glow, at all. (Until I put DMM voltmeter probe on the cathode, and it lights up a bit taking the reading!). Probed all the points to make sure I had everything wired, correctly, all good. Turned the current limiting down to 10mA and removed the diode, and bright light ensues.
Doesn't prove anything except what a lack of a life I have, but I thought I'd share!
(These FETs are pretty cheap, too, AFAIC. So maybe you can use it if your FET is to blame.)
-
This is a long shot but have you any freeze it spray handy (compressed air cans upside down work also)
It would be interesting to see if cooling the fet helps it turn off. Gate threshold voltage drops with increase in heat perhaps this may be a problem
-
I vote for ESD damage. The 2N7002 has very little gate capacitance so it is very easy to destroy.
-
PD0 is shared with RXD and the description of the UART says it owns that pin unless it is disabled (i.e. it does not get overriden by DDRD).
A bit of RXEN0 = 0 ?
If you switch to a GPIO not shared with RXD does it behave?
As per...A long shot but since you are reusing the TxD and RxD pins, you don't have a bootloader or something that is leaving the UART enabled do you?
RXEN does give you a pull up on PD0 but RXEN is default to 0 so you would have to have something else enabling it as per jwm_'s suggestion. -
Where were these 2N7002s sourced from?
-
At this point it would be real tempting to pull an LED and 2N7002 off the board, set it up
in a protoboard, and see if it works as one expects. The primary thing that would make
drain current in the 2N7002 with a Vgs = 0 would be either blown gate, or the output
drain to source diode damaged (usually done by exceeding safe area, L dominant transients).
Not applicable but also notice Idss at Vgs = 0, hot, 1 mA is the spec.
Regards, Dana. -
Where were these 2N7002s sourced from?
If memory serves, from Mouser. Actually i am convinced because i seldom get semiconductors from anywhere else. Definitely not from cheapo Asian sources. -
Where were these 2N7002s sourced from?
If memory serves, from Mouser. Actually i am convinced because i seldom get semiconductors from anywhere else. Definitely not from cheapo Asian sources.
Should be good then. I do know that 2N7002s are extremely ESD sensitive. I just fried a couple of them a few weeks ago when testing a circuit in my bench. One would leak about 200uA of current and never fully shut off. But when you ground the gate, yours DO turn off... -
To guard against this my workbench is protected with proper ESD conductive mat, wrist straps and ground connections. It is still possible to zap a very sensitive part but i don't think that is the problem. Not for all 4 of the cases.
I had time for a quick hack just now and replaced one of the 2N7002s with a BS170. I can report that the corresponding LED is now fully off as it should be. So it was the fet as i suspected, after all. Later i could try to run some components thru a Peak tester to get the characteristic curves. Those could be revealing.
-
Quote
Not applicable but also notice Idss at Vgs = 0, hot, 1 mA is the spec.
That sounds excessive. I'm seeing this:
http://www.nxp.com/documents/data_sheet/2N7002F.pdf
IDSS drain leakage current VDS = 48 V; VGS = 0 V
min typ max
Tj = 25 °C - 0.01 1 uA
Tj = 150 °C - - 10 uAQuoteIf memory serves, from Mouser.
The Mouser stocked version is a tenth of a cent cheaper than the reel of logic level FETs I just bought. I'll consider it lucky I was looking for minimum current of 250mA.
-
From this datasheet - https://www.fairchildsemi.com/datasheets/2N/2N7000.pdf
I should correct my earlier post to .5 mA hot for the 2N7002.
Regards, Dana.
-
Ok. Actually, the Mouser stocked Diodes incorporated SOT 23 2n7002 is also showing half a milliamp.
Interesting thing I learned from the Fairchilds datasheet
SOT23 = TO-236AB ?! ... naturally.
-
What about the value of the SPIEN fuse?
Anyway, the question remains... does it still behave this way on other GPIO pins? Which ones have you tried?