WTF!? Atmega328P vs 2N7002F - fails to turn off!

[Kremmen]

What the #¤%& am i doing wrong here? A circuit that couldn't be simpler fails to work, and yet it works when done on the breadboard.

This is a dead simple indicator LED / isolator opto driver from Atmega328 GPIO pin to 2N7002F fet. Gate resistor is 10 to 100 ohms and there is a gate pulldown 1 to 10k ( i.e. those are the limits that i have tried). The load is a LED fed from 12V thru a limiter of some 470 ohms or so (varies - there are several circuits that behave like this). The problem is that the fet does not turn off but leaks like crazy. If the load is a LED it stays lit although the brightness goes down so the gate drive does go down as well. But the fet never turns off properly.
I have encountered this in 2 separate projects now. The first one was done using Arduino Due and the 2nd one is a DIY board with the Atmega on board. No matter what combo of gate resistors i try the behavior is the same.
If i force (short) the gate to ground the LED goes dark immediately as it should. I have made the same circuit on breadboard and driven it from a signal generator. That way it is not the least sensitive to parameter variations. A low drive level of over 300 mV still causes the LED to turn off nicely. Scoping the Atmega shows the drive signal to go well below that but still the LED stays on.
After thoroughly isually inspecting the circuit i can guarantee that the connections are right (4 bad circuits in 4 different places for the particular function and nothing else would be a stretch anyway).
What the hell is going on here? What am i missing?

[Seekonk]

Too many words to read, but I suspect the output pin was not defined as an output.  That leaves it floating and gate capacitance holds fet on.

[alsetalokin4017]

Too many words to read, but I suspect the output pin was not defined as an output.  That leaves it floating and gate capacitance holds fet on.

This was my first guess too.

Kremmen, can you post your complete code?

[Kremmen]

Too many words to read, but I suspect the output pin was not defined as an output.  That leaves it floating and gate capacitance holds fet on.

This was my first guess too.

Kremmen, can you post your complete code?

I know you mean well, but that ain't it. But in the interest of not being difficult, here it is. Sorry about the language in the comments - you'll have to live with that.
Any better ideas?

Code: [Select]

/*
 * PWRcontroller.cpp
 *
 * Created: 15.2.2016 11:53:03
 * Author : martti
 */

#include <avr/io.h>
#include <avr/interrupt.h>

#define F_CPU 8000000L

uint16_t cmscounter;
volatile uint16_t mscounter; // millisekuntilaskuri (laskee millisekunteja pwm-syklin alusta)
uint16_t tmpsetpoint, csetpoint;
volatile uint16_t setpoint; // asetusarvo (0 - 1000)
uint16_t ADsum;
uint8_t ADindex;
#define  ADINDEXMAX 64 // oltava 2:n potenssi!
uint16_t ADvalue[ADINDEXMAX];
volatile bool cyclestart;
bool pwroutput, indicator;
uint8_t portvalue;


int main(void) {
uint8_t i;

 // Alustetaan GPIO
PORTD = 0; // lähdöt ensin pois päältä
DDRD = 0x03; // 2 alinta bittiä outputteja
 
    // Alustetaan kello, timeri1 ja A/D-muunnin
CLKPR = 1 << CLKPCE; // enable prescaler
CLKPR = 0; // prescaler = 1 (8MHz kello)

TCCR1A = 0; // Compare outputit pois päältä WGM bitit 0 ja 1 = =
TCCR1B = 1<<WGM12 | 1<<CS10; // CTC moodi, prescaler = 1
TIMSK1 = 1 << OCIE1A; // Timer 1 keskeytys vertailurekisteristä A
OCR1A = 0x1f40; // vertailu = 8000  --> 1ms aikakeskeytykset

ADMUX = 0x00;
ADCSRA = 1 << ADEN | 1 << ADIE | 1 << ADPS0; // muunnin päälle, keskeytykset päälle, muuntimen kellojakaja /4

for ( i=0; i<ADINDEXMAX; i++ ) {
ADvalue[i] = 0;
}
ADindex = 0;
ADsum = 0;

sei();
//pwm-looppi
    while (1)
    {
if (cyclestart) {
cli();
cyclestart = false;
sei();
pwroutput = true;
}
cli();
cmscounter = mscounter;
csetpoint = setpoint;
sei();
if ( cmscounter >= csetpoint ) pwroutput = false;
portvalue = (PIND & 0xfc);
portvalue |= pwroutput & 0x01;
portvalue |= ((pwroutput & 0x01 ) | (indicator & 0x01)) << 1;
PORTD = portvalue;
    }
}

// Timer1 Compare A: 1 millisekunnin keskeytys
// kasvatetaan millisekuntilaskuria
//
ISR(TIMER1_COMPA_vect) {
ADCSRA = ADCSRA |  1 << ADSC | 1 << ADIE; // käynnistetään uusi A/D-muunnos
if ( ++mscounter > 1000) {
mscounter = 0;
cyclestart = true;
}
indicator = !indicator;
}

// A/D-muuntimen keskeytys
ISR(ADC_vect) {
ADsum -= ADvalue[ADindex];
ADvalue[ADindex] = ADC;
ADsum += ADvalue[ADindex];
ADindex++;
if ( ADindex >= ADINDEXMAX) ADindex = 0;
tmpsetpoint = ADsum >> 6; // jako 64:llä. Synkattava ADINDEXMAX:in kanssa!

// A/D-muunnos tuottaa lukeman 0 - 1024. Jaksonaika on 1000 ms joten
// setpoint on 24 isompi kuin jakso. Käytetään ero hyväksi tekemällä hieman välystä molempiin päihin
// Lukemat 0-12 tulkitaan nollaksi ja isommista vähennetään 12. Tällöin viimeiset 12 inkrementtiä vastaavat "täyttä kaasua"
// Näin varmistetaan, että potikalla päästään ihan nollasta ihan täysille.

if (tmpsetpoint < 12 ) setpoint = 0;
else setpoint = tmpsetpoint - 12;

}

[kfitch42]

Let's break this down: Is the problem inside or outside the atmega328/arduino?

Build up the breadboard/siggen circuit that works (LED goes out): replace siggen with ATmega328, does is still go out? Replace siggen with arduino, does it still go out?

or alternately, take the system that is not working, and replace the atmega/arduino with the siggen.

Could it be something as simple as the gate pulldown is actually a pull up?

[danadak]

Set a breakpoint at code right after you turn off jfet and look at gate drive Vgs with a voltmeter.
Sounds like output of opto isolator is a bipolar threshold above ground and keeping the fet on.
If you can't breakpoint it do a while( 1 ) { }; right after you turn off JFET.

Do you have a schematic snippit from Arduino pin all the way to LED load you can post, along
with opto coupler part number ?

Regards, Dana.

[danadak]

One other thing, in a design like this the Rgs should be >> than any series Rintogate,
as that forms a V divider and robs you of gate drive when yiou are turning on the fet.
So lean more towards the 10K size to insure you get the fet turned hard on which limits
Pdiss in the jfet and makes the Iled more predictable and set primarily by its Rled and
Vsupply.

Regards, Dana.

[Kremmen]

The switching frequency is so low as to be effectively DC on the timescale of gate oscillations that usually occur at >100 MHz. The indicator LED cycles at 1 Hz with a 1 kHz brightness modulation on top so there is all the time in the world for the gate drive to stabilize to whatever it is aiming at.
I have scoped the circuit using a reasonable scope (Rigol 2202) and no gate oscillations visible. Voltage levels are about what one would expect.


The actual circuit looks like this.  R7 is directly connected to a GPIO pin of an Atmega 328P. There is a similar circuit done with Arduino Due (an Atmel SAM ARM chip) and it behaves exactly the same. When switched off there is a significant and persistent leakage. That case is made simple by the fact that the indicator LEDs are idle at start so there are no switching events at all. The gate voltage is 43.96 mV and still the LED is visibly on.
I can only come to the conclusion that either 2N7002 is unsuitable for this application or that i have a batch of shitty components.
Interestingly, the same ARM drives a bunch of BS170 fets on a satellite board with zero issues.

[Psi]

Some of your variables are not defined volatile and should be.

Every variable/array/boolean used in an interrupt should be volatile unless it is only used in the interrupt and nowhere else.

(Except if your using nested interrupts, then make the sucker volatile if it even thinks about going near an interrupt) your not using nested, so that's fine

[Kremmen]

While you are formally correct it won't impact the overall working of the code. And it is anyway irrelevant to the problem at hand because variable volatility and GPIO drive levels are unrelated.
Perhaps you didn't have time to read my latest reply before posting. In my last i noted that in some of the cases it is easy to verify that the outputs are stable at low output level and still the LED is visibly on.

[Kalvin]

I do not know what is going on, but you can place a diode (1N4001 or 1N4148)  between the Q3's drain (pin 2) and ground which will make the Gate negative relative to the drain when driven "0" and it should turn the Q3 off. Or, you have the R7 there, so you can replace the Q3 with an NPN and make R7 to 1K.

The MOC3061M is an opto-triac which is suitable only for driving AC-loads as it will stay on when triggered until the load's voltage drops to zero.

[Kremmen]

Yes the triac opto is used exactly for that purpose and is free to stay on for the rest of the cycle, that is the idea after all. The issue is on the LED side of the opto, not on the hi voltage side.

Good question about the ground. I should have mentioned that it was one of the first things i checked and there is no practical difference in ground potential. Additionally in some of the physival circuits you can see by eyeball that the ground plane extends directly to the common point at the regulator. Anyway, the decisive thing controlling turn on/off is the Vgs as measured between the fet gate and source. I confirmed by measuring directly from the pins of the fet and get 40.03 mV that definitely should not turn the fet on, whatever the load might be...

Thanks all for the suggestions. I don't think i want to rape the circuit by adding any kludge diodes or other hacks to get such a simple thing working. I'll just replace the fet with a known good type.
My original purpose in posting was to find out if this was a known issue with one or the other, or perhaps just this combo. But apparently it is not.

[Kalvin]

You could take the faulty 2N7002 and measure the gate-source and gate-drain resistance (in both polarities, of course) and check whether you still have a MOSFET or something else.  I am not sure how easy it is to break the 2N7002 and what it its common breaking mechanism, but during the winter-time static electricity is everywhere.

[Kremmen]

While that is a good suggestion i have 4 individual fets all showing the same behavior. 2 of those are soldered in an SMD oven using a controlled heating cycle, 2 are hand soldered.
Anything wrong with all 4 of them either indicates an issue with the component itself or some gross violation in the soldering process. Just for your information i have ~40 years experience in soldering so i do know how that is done right. And component overheating is not a problem otherwise so why just these fets?
Of course all of them could still be kaput due to something in the process that they cannot take. But that would only be an indication to change fet type to something that works.

Soldering wires to the fet dead bug style and then playing with it using a signal generator results in exactly the kind of behavior one would expect. But same does not happen when a similar fet is driven by the processor. Hence the WTF...

[dadler]

Truly bizarre.

Is there any chance your uC output ports are toasted, and there is nothing wrong with the FETs?

The confounding part is that the FETs work as expected off board...

[Kremmen]

Well. it is possible (but i say not likely) for the Atmega that sits on a DIY board. For the Arduino Due i highly doubt it because i have not soldered the processor of course, only the "shield" with all the other stuff.

Playing with the signal generator you can swear it is the processor because everything works.
In the processor circuit all voltages indicate the fet must be off yet isn't. So you can swear it is the fet.
So which is it...?

[xtoffer]

Hello, I wanna try one guess. Since everything should work there is probably a false assumption somewhere.

I keep getting stuck on the ground part and feel that there still might be something fussy there. -If- the grounds were not connected funny things would happen. The reason it would work by connecting the signal generator could be that through connecting it you also make a proper ground connection.  (And likewise when you manually pulled the gate low.) The reason it measured roughly the same potential could possibly be that the meter pulled the two grounds together?

To put my mind to rest, could you measure the resistance between the microcontroller GND pins (there are multiple on that one I think) and the FET source?

Otherwise... footprint? Nah I don't know..

[Farley]

I might have missed it in the preceding posts, but did you confirm which pin (by pin number) on the ATMEGA386 that R7 is connected to?

[ivan747]

Is the pinout on the FET right?

[danadak]

The substrate of the Opto Coupler is no connect, left floating ?

Regards, Dana.

[KL27x]

Playing with the signal generator you can swear it is the processor because everything works.
In the processor circuit all voltages indicate the fet must be off yet isn't. So you can swear it is the fet.
So which is it...?

If you are measuring gate voltage below threshold, and the LED is not fully off, it's because the FET is truly off... most of the time, but not all the time. (Did you scope it?) So if it's really dim and you can't see it flickering, you know the duty cycle is pretty low, and the average frequency is higher than 50Hz. And that the problem is most likely your code. (With a slight possibility it's a silicon errata that is not due to your error).

Step 1. Disable your interrupt routine.
Step 2. Set LED pin to output off. loop.
Step 3. Watch it really turn off.
Step 4. Change your test code to turn ON the LED. And watch it turn on.
Step 5. Repeat 2-4 as many times as necessary for you to accept that you have made a mistake.
Step 6. Now stop dicking around playing with your signal generator and get to work.

Step 7. Go back to the "turn off led" test loop. And enable your ISR. See if the LED is all the way off.
Step 8. If you have a scope, turn on the LED, and see if it's really on 100% of the time.

I put money it's your ISR, and a good chance it's due to what Psi posted. If that doesn't fix your problem, also try clearing all of your variables at startup. That's a shotgun approach, but it may be helpful. Also if you have a scope, try toggling a pin at the start of your ISR and toggling it off before exiting, then look at it on your scope. This is good, in general, to see if it's really doing what you think it is. Scope the LED pin on the other channel to find out where this spike is occurring in relation to your ISR as a whole.

[Kremmen]

I will respond to the latest posts here one by one. Some of the suggestions have been verified already several times but in the interest of keeping the thread readable, i will respond to each question here.

Hello, I wanna try one guess. Since everything should work there is probably a false assumption somewhere.

I keep getting stuck on the ground part and feel that there still might be something fussy there. -If- the grounds were not connected funny things would happen. The reason it would work by connecting the signal generator could be that through connecting it you also make a proper ground connection.  (And likewise when you manually pulled the gate low.) The reason it measured roughly the same potential could possibly be that the meter pulled the two grounds together?

To put my mind to rest, could you measure the resistance between the microcontroller GND pins (there are multiple on that one I think) and the FET source?

Otherwise... footprint? Nah I don't know..

The grounds have been originally designed along generally accepted design practices although the fact that these boards are only 2 layer do place certain limitations. Still, it is easily verifiable from the design documents and visually, that there is plenty of copper fill available for the ground connections. In a previous post i already reported that the fet pin voltages (those and those only decide if the fet is on or not) indicate turn off. Still to put minds at rest i measured the resistance (3 out of 4 cases) and every one is below 0.005 ohms (measured with rather accurate a Rohde&Schwarz lab multimeter).

I might have missed it in the preceding posts, but did you confirm which pin (by pin number) on the ATMEGA386 that R7 is connected to?

Yes of course. Again i remind that there are 2 different devices both showing the same symptoms. One is driven by an Arduino Due where it is hardly likely that the pinout would be wrong.
Both units are done using a PCB CAD with confirmed footprints. The same processor footprint has been used in numerous projects and is known good. It would be difficult to pass DRC and connectivity verification in the PCB CAD if that was wrong. Also the signals demonstrably go to the fets they should, it is just that the fets behave erratically.

Is the pinout on the FET right?

Yes. Again, this is a standard SOT-23 package footpring in the PCB CAD, with tons of use cases all over the place. Also the 2N7002 has been used in any number of projects with no issues until this. 2N7002 data sheet agrees with what is on the PCB.

The substrate of the Opto Coupler is no connect, left floating ?

Regards, Dana.

Yes, as specified in the data sheet. Anyway, it would have no impact on the ordinary LEDs, especially those on a totally separate board

[...]
If you are measuring gate voltage below threshold, and the LED is not fully off, it's because the FET is truly off... most of the time, but not all the time. (Did you scope it?) So if it's really dim and you can't see it flickering, you know the duty cycle is pretty low, and the average frequency is higher than 50Hz. And that the problem is most likely your code. (With a slight possibility it's a silicon errata that is not due to your error).

You 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. ..."

Step 1. Disable your interrupt routine.
Step 2. Set LED pin to output off. loop.
Step 3. Watch it really turn off.
Step 4. Change your test code to turn ON the LED. And watch it turn on.
Step 5. Repeat 2-4 as many times as necessary for you to accept that you have made a mistake.
Step 6. Now stop dicking around playing with your signal generator and get to work.

Step 7. Go back to the "turn off led" test loop. And enable your ISR. See if the LED is all the way off.
Step 8. If you have a scope, turn on the LED, and see if it's really on 100% of the time.

So i guess dicking must continue while we wait for more relevant suggestions if you have any.

I put money it's your ISR, and a good chance it's due to what Psi posted. If that doesn't fix your problem, also try clearing all of your variables at startup. That's a shotgun approach, but it may be helpful. Also if you have a scope, try toggling a pin at the start of your ISR and toggling it off before exiting, then look at it on your scope. This is good, in general, to see if it's really doing what you think it is. Scope the LED pin on the other channel to find out where this spike is occurring in relation to your ISR as a whole.

OK, i'll take your money. How much did we bet, again?

This is how the Arduino thing looks. Both LEDs are statically OFF in the procesor outputs. No interrupts, no nothing. I/O driven low with no changes and this is what i get.

[station240]

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.
I'd try increasing the 100ohm resistor.

[jwm_]

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?

[fable]

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.
Sorry for my bad english.