Hi, all -
I am trying to build the circuit as described in Mr. Molloy’s book, figure 6-2 (page 204 in my copy). The LED comes on and stays on no matter what I do in software. I’ve even removed the gpio49 directory, using the “echo 49 > unexport” command. LED stays on.
Any ideas what I might be doing wrong? I’m including a picture of my wiring. In the pic, the BS270 is “upside down;” that is, from left to right it’s DGS.
Thanks for any help.
mz
Oops…forgot the pic:
Removing the gpio pin from the sysfs entries probably won’t help.
So why don’t you be verbose with us, and tell us everything you’ve done, including setup, Linux image date, and kernel used.
Hi, William - thanks for the quick reply. The system is whatever the BBB came with (I got it about a month ago). The uname command suggests it was built Oct 13 2015. I’ve done no other setup other than build the circuit and follow the instructions on page 205 of The Book.
So, if deleting the entry for gpio49 doesn’t do anything, do I correctly infer that the “default” state of the hardware is a closed circuit (LED on)?
Thanks for the help.
mz
Ok, first I’m not an EE, so if I make a statement that’s obviously wrong from that perspective. . .
Anyway . . . I have a custom cape with several LED’s on it here. Connected to a Beagelbone green.
LED is on:
william@beaglebone:~$ cat /sys/class/gpio/gpio110/value
1
LED goes off:
william@beaglebone:~$ sudo sh -c “echo ‘0’ > /sys/class/gpio/gpio110/value”
william@beaglebone:~$ cat /sys/class/gpio/gpio110/value
0
LED comes back on:
william@beaglebone:~$ sudo sh -c “echo ‘1’ > /sys/class/gpio/gpio110/value”
unexport does not work for me:
william@beaglebone:~$ sudo sh -c “echo ‘110’ > /sys/class/gpio/unexport”
sh: echo: I/O error
Maybe I’m doing this wrong, because honestly I have not been using the sysfs gpio file directly in around . . .I do not know, maybe 6 months. I’ve been using config-pin with universal IO. But it is my assumption that I am unable to unexport because of something related to universal IO, and my custom cape / overlay.
But yes, the pins on a beaglebone are all set to come up as inputs by default. Then they can be used as gpio without any overlay, just by exporting the pins, then configurering them the way you want. Through the sysfs gpio file structure.
So why don’t you copy paste what you’re attempting from the command line, along with the errors you’re getting if any. If you’re not getting any errors, but no physical feedback through the LED going off and on. Then you’re probably connected to the wrong pin out of the header.
Another thing that comes to mind, is that possibly your circuit there is reverse logic.
By the way, I have the book, but this is not an issue with Derrek’s book, I know that for a fact. You’re doing something differently, or wrong for your situation. Maybe something has changed, but you’re most likely using a 3.8.11-bone47 kernel. Which should be exactly the same kernel Derek was using.
Hey, William -
Thanks for bearing with me on this…
mz
A word of caution--some MOSFETs start conducting between source and
drain when you apply voltage to the the gate, and others work the
other way. Which one do you have---what's the type?
Hi, Przemek -
It’s a Fairchild BS270:
I (obviously) need to learn more about this…is the information you ask of in the data sheet? If so, I’ll search for it.
mz
I’d check /sys/class/gpio/gpio49/direction . . .
william@beaglebone:~$ cat /sys/class/gpio//gpio49/direction
in
Make sure its “out”
After that, I’d start by disconnecting P9.23 from the circuit, then check with a volt meter that the pin isn’t somehow damaged. P9.1 and P9.2 are both ground on that header.
Oh, and additionally. The circuit needs to be isolated when the board powers on / off. This is where my electronics knowledge will fail me, but if that pin is not isolated at boot, and it’s externally powered. You may have damaged the pin . . . also you’re powering your circuit from what looks like P9.5, which is 5V, the gpio pins are only 3v3 tolerant.
Additionally, the GPIO pins can only source / sink so much current, For many, this is only 6mA or less, where a few are 8mA. But again, my electronics knowledge would fail me here in knowing exactly what’s going on with your circuit.
Oh, now this is interesting: now that daylight has gone, and the room’s a little darker, I can see that the LED is on brightly when the value is 1. When the value is 0, it’s noticeably dimmer, but not completely off.
Here, I’m way out of my depth (I’m a software person)…I double-checked the resistor, and it’s the correct “size” (220 ohm).
I remember reading in the book that the BBB is a little “fussy” about things getting connected an disconnected. Is it good practice to do a shutdown before I start moving wires around for testing?
Thanks…
mz
I think that since you’re getting power from the P9 header for this circuit, you’re ok. As far as isolation goes. But again I’m not an EE so someone who is should answer that question. I’m a software person too.
I also see what seems to be a current limiting resistor . . .
As far as the LED always being lit, but dimmer when toggled low. Your transistor is always conducting for some reason. Maybe a weak pulldown on the gate is needed ? But hey. software guy, not electronics guy here . . .
http://www.farnell.com/datasheets/2162038.pdf page 4 shows Ids vs Vgs
plot that conduction start well above 2.5V (listed as Vgs(th) in the
datasheet), so the the voltage put out by the GPIO pin, which should
be almost 3.3V, should be enough. Do you have a multimeter to measure
the actual gate voltage?
OK then, check the voltage for '0'---it has to be much lower than
Vgs(th) i.e. 2.5V. Perhaps some pullup doesn't let it go all the way
down? Again, measure it with the voltmeter.
Yes, the gate voltage is 3.3V when the file “value” is 1, and 0V when the value is 0.
Yes, the gate voltage is 3.3V when the file "value" is 1, and 0V when the
value is 0.
then, either the transistor is blown (they need to be protected from
static discharge which could damage them) or it's miswired.
This is the circuit which may or may not render well in ASCII.
o +5V
>
>>> R
>>> 330ohm
>
_V_ LED
>
>--+
GPIO -->------| |
>--+
_|_ GND
BTW, you didn't mention the LED current limiting resistor---you need
that because your transistor can pass multiple amps when GPIO is 3.3V
and the drain is at 5V-Vled, i.e. around 3.5V. Lack of the resistor
could have damaged the transistor as well, although it would have
damaged the LED as well I think.
{crawling out of the shadows}
On Mon, 24 Oct 2016 19:25:44 -0700 (PDT), mzimmers
<mzimmers@gmail.com> declaimed the following:
Oh, now this is interesting: now that daylight has gone, and the room's a
little darker, I can see that the LED is on brightly when the value is 1.
When the value is 0, it's noticeably dimmer, but not completely off.Here, I'm way out of my depth (I'm a software person)...I double-checked
the resistor, and it's the correct "size" (220 ohm).I remember reading in the book that the BBB is a little "fussy" about
things getting connected an disconnected. Is it good practice to do a
shutdown before I start moving wires around for testing?
At this point, /I'd/ likely try taking the GPIO out of the equation by
removing the lead from the GPIO pin and just alternately touching one of
the spare ground pins and then the 3.3V supply pin, and observing the LED.
If it is the same behavior, the likely culprit would be the transistor,
which is either "leaking", or is mis-wired -- though I'm having difficulty
visualizing a mis-connection where a "1" results in full brightness. I can
see wirings where the gate is always set to conduct and what is being
controlled is either the source or drain voltage level (I'm assuming this
transistor is one meant to conduct when the gate is high):
5V -> LED -> limit resistor -> <conducting transistor> -> GPIO@3.3V [dim --
1.7V effective on LED/resistor]
5V -> LED -> limit resistor -> <conducting transistor> -> GPIO@0.0V [bright
-- full 5V effective on LED/resistor]
GPIO@3.3V -> LED -> limit resistor -> <conducting transistor> -> 0V
[moderate -- 3.3V effective on LED/resistor]
GPIO@0.0V -> LED -> limit resistor -> <conducting transistor> -> 0V [off --
0V effective on LED/resistor]
Thank you for the information, guys. Just to make sure we’re all on the same page (pardon the pun), here’s the circuit that I’ve built:
I’m pretty sure I’ve done this correctly.
Dennis: I tried your test, and it does indeed work the same way (PWR: bright, GND: dim). I also tried GPIO1_16 (I originally used GPIO1_17 per the instructions) with the same result.
Looks like I fritzed the transistor, huh?
mz
On Tue, 25 Oct 2016 09:12:34 -0700 (PDT), mzimmers
<mzimmers@gmail.com> declaimed the following:
Dennis: I tried your test, and it does indeed work the same way (PWR:
bright, GND: dim). I also tried GPIO1_16 (I originally used GPIO1_17 per
the instructions) with the same result.Looks like I fritzed the transistor, huh?
That would be my feelings... You have a transistor that is not
completely blocking current flow.
Hi,
The book mentioned as far as I remember, a kickback diode should be in circuitry in parallel with the load which is LED in your case, to protect the transistor from static for on/off cycles. Looks like transistor is gone at the beginning of the tests.
Alex