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.