Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
My Raspberry Pi3 is dead or dying.
331 views
Skip to first unread message
RobH
Jan 21, 2018, 9:33:16 AM1/21/18
to
I have been trying to get a simple led project to work on my pi 3 using
a 5 volt 6 amp power supply and a 510 ohm resistor in front of the led
to reduce the current going to it. Now after trying different tutorials,
my pi 3 goes off on it's own from being powered up.
If I remove the power lead and restart the pi 3 the red comes on and the
green led flashes as well as the ethernet port flashing green led.
I ssh into the pi 3 to try and run a python program, but then the pi
dies, and there are no lit up leds anywhere at all on it.
Is there any way it can be fixed or should I just forget about it.
a 5 volt 6 amp power supply and a 510 ohm resistor in front of the led
to reduce the current going to it. Now after trying different tutorials,
my pi 3 goes off on it's own from being powered up.
If I remove the power lead and restart the pi 3 the red comes on and the
green led flashes as well as the ethernet port flashing green led.
I ssh into the pi 3 to try and run a python program, but then the pi
dies, and there are no lit up leds anywhere at all on it.
Is there any way it can be fixed or should I just forget about it.
Dave Liquorice
Jan 21, 2018, 9:56:05 AM1/21/18
to
On Sun, 21 Jan 2018 14:33:13 +0000, RobH wrote:
> I ssh into the pi 3 to try and run a python program, but then the pi
> dies, and there are no lit up leds anywhere at all on it.
>
> Is there any way it can be fixed ...
> I ssh into the pi 3 to try and run a python program, but then the pi
> dies, and there are no lit up leds anywhere at all on it.
>
I'm not convinced it's broke, the fact it boots, initialises the
USB/ethernet, loads the OS and starts the sshd service indicates it's
far from dead.
Seems more like a major crash when your try to run the Python script.
Does Python work? Just enter "python" at the command prompt, you
should get version info and a >>> prompt. Enter "print 'hello world'"
"hello world" shoould eco back and return to the >>> prompt. Enter
"quit()" to get back to the OS prompt.
If that works start looking at what your script is up to.
--
Cheers
Dave.
alister
Jan 21, 2018, 1:26:37 PM1/21/18
to
On Sun, 21 Jan 2018 14:33:13 +0000, RobH wrote:
if you have driven them at 5V without protection you may have damaged the
port & possibly other parts of the CPU (current limiting with a resistor
may not be sufficient protection).
this could easily result in erratic or unpredictable behaviour.
--
A baby is God's opinion that the world should go on.
-- Carl Sandburg
RobH
Jan 21, 2018, 2:05:47 PM1/21/18
to
a couple of python files but neither did anything out of the ordinary.
So as you say it is not dead or dying.
RobH
Jan 21, 2018, 2:10:50 PM1/21/18
to
using a 220 ohm one
Gordon Henderson
Jan 21, 2018, 2:36:06 PM1/21/18
to
Boot the Pi, login, run a few programs - just to make sure the Pi
itself is running OK.
Halt and power down.
Connect from GPIO pin 11 (physical pin 11) to the LED to a resistor then
to 0v.
Boot Pi & login:
Run this command in a terminal
gpio -1 mode 11 out
gpio -1 toggle 11
Run the last command a few times. LED ought to go on/off.
Your 510 ohm resistor ought to be fine - as a general guide
for most generic red/yellow/green LEDs you can use a value of
Voltage * 100 ohms, so for the 3.3v Pi, then 330 ohms is fine.
More pictures here which might help you get started:
https://projects.drogon.net/raspberry-pi/gpio-examples/blink/
Gordon
R.Wieser
Jan 21, 2018, 3:47:16 PM1/21/18
to
Rob,
> ...but then the pi dies, and there are no lit up leds anywhere at all on
> it.
Thats odd, as the red led is directly connected to the 3.3v power, and thus
*cannot* be switched off.
... which leads me to believe that the problem might very well not be your
PI, but somehow no power being supplied to it.
In other words, check the power supply and the wiring from it to the PI
(wire breakage comes to mind, but maybe even something as simple as a bad
contact on the connector).
On the other hand, if the powerlines on the PI somehow got shortcutted the
red led will ofcourse go dark too - but thats not something I see happening
when an output pin gets destroyed. Especially not when its intermittent.
Regards,
Rudy Wieser
> ...but then the pi dies, and there are no lit up leds anywhere at all on
> it.
Thats odd, as the red led is directly connected to the 3.3v power, and thus
*cannot* be switched off.
... which leads me to believe that the problem might very well not be your
PI, but somehow no power being supplied to it.
In other words, check the power supply and the wiring from it to the PI
(wire breakage comes to mind, but maybe even something as simple as a bad
contact on the connector).
On the other hand, if the powerlines on the PI somehow got shortcutted the
red led will ofcourse go dark too - but thats not something I see happening
when an output pin gets destroyed. Especially not when its intermittent.
Regards,
Rudy Wieser
Dave Liquorice
Jan 21, 2018, 5:20:23 PM1/21/18
to
On Sun, 21 Jan 2018 21:47:06 +0100, R.Wieser wrote:
> Thats odd, as the red led is directly connected to the 3.3v power, and
> thus *cannot* be switched off.
Not according to the Pi 3 schematic. There is FET between the LED and
> Thats odd, as the red led is directly connected to the 3.3v power, and
> thus *cannot* be switched off.
ground, the gate fed from the active low !RST output of a
APX803-46SAG supply supervisor device. If the 5 V supply drops below
4.6 V it asserts the active low !RST and thus turns the LED off. If
the supply rises above 4.6 V it waits at least 140 ms before lowering
!RST. The same signal goes elsewhere as the PWR_LOW_N line.
The documentation is incomplete but dig about for gpiovirtbuf to at
least monitor the PWR_LOW_N line and in principle be able to control
the LED via that line.
--
Cheers
Dave.
Dave Liquorice
Jan 21, 2018, 5:25:11 PM1/21/18
to
On Sun, 21 Jan 2018 19:05:46 +0000, RobH wrote:
>> I'm not convinced it's broke, the fact it boots, initialises the
>> USB/ethernet, loads the OS and starts the sshd service indicates
it's
>> far from dead.
>
>> I'm not convinced it's broke, the fact it boots, initialises the
>> USB/ethernet, loads the OS and starts the sshd service indicates
it's
>> far from dead.
>
> I have booted up the pi 3 and left it running for a while now. I did try
> a couple of python files but neither did anything out of the ordinary.
> So as you say it is not dead or dying.
As has been mentioned the GPIO's on a Pi are 3.3 V and don't take
> a couple of python files but neither did anything out of the ordinary.
> So as you say it is not dead or dying.
kindly to 5 V. I assumed that the 5 V supply was only fed to the 5 V
USB input or to the 5 V pins on the GPIO header. If you connected the
5 V to the LED, then reistor then to a GPIO you might have fried that
GPIO but with a 510 ohm resistor I find that unlikely.
Try running the LED Python script with no resistors/LEDs connected,
does the Pi still fall over? Change the script to use a different
GPIO, try again with no R's or LEDs, if that works repeat with R's
and LED's connected (to 3.3 V...).
--
Cheers
Dave.
R.Wieser
Jan 22, 2018, 3:31:26 AM1/22/18
to
Dave,
>> Thats odd, as the red led is directly connected to the 3.3v power, and
>> thus *cannot* be switched off.
>
> Not according to the Pi 3 schematic.
Damn. I googled it and went with the "I feel lucky" result. I guess I
wasn't ... A later result mentions its actually connected to something
switchable. So, my bad.
It would still not not be a bad idea to check the power supply though,
starting with placing a led on the +5v power pins (to see if power is
actually present). Apart from the wiring problems I mentioned, if the Pi is
connected to that 6Amp power supply its just possible that it doesn't
work/stabilize all that well on lower currents, and as such causes the Pi to
brown-out.
Regards,
Rudy Wieser
>> Thats odd, as the red led is directly connected to the 3.3v power, and
>> thus *cannot* be switched off.
>
> Not according to the Pi 3 schematic.
wasn't ... A later result mentions its actually connected to something
switchable. So, my bad.
It would still not not be a bad idea to check the power supply though,
starting with placing a led on the +5v power pins (to see if power is
actually present). Apart from the wiring problems I mentioned, if the Pi is
connected to that 6Amp power supply its just possible that it doesn't
work/stabilize all that well on lower currents, and as such causes the Pi to
brown-out.
Regards,
Rudy Wieser
RobH
Jan 22, 2018, 6:49:36 AM1/22/18
to
On 21/01/18 19:24, Dennis Lee Bieber wrote:
> On Sun, 21 Jan 2018 19:10:48 +0000, RobH <r...@despammer.com> declaimed the
> following:
> Active High or Active Low wiring?
>
> IOWs, what is the voltage source for the LED?
>
> GPIO -> limit resistor -> LED -> ground (active High -- LED is on when
> GPIO is high/3.3V)
>
> V+ -> limit resistor -> LED -> GPIO (active Low -- LED is on when GPIO
> is low/ground/0V)
>
> In the former, the processor GPIO provides the voltage, so you should
> be seeing the 3.3V maximum, and need to limit the current to that available
> on a GPIO (If the calculator was based on 5V, you should be safe, as you
> are running the LED on less than maximum current given a 3.3V source). In
> the latter, the voltage is provided by some power supply bus -- and if that
> is 5V, and the GPIO is High (conceptually off), you would still have 2.8V
> passing through the resistor/LED being sinked by the GPIO. {Note: my use of
> source/sink may be inconsistent -- I tend to think in terms of higher
> voltage flowing to lower voltage... But electron flow itself is in the
> opposite direction).
>
>
I don't know what the difference between active low and active high wiring.
The voltage source for the led is from the Raspberry pi GPIO 17
I have been following this youtube video:
https://www.youtube.com/watch?v=OEilz2Cq_xY.
I've just done some checking of some of the GPIO pins with a voltmeter,
and got this:
GPIO 17 0.06 vdc
GPIO 27 0.01 vdc
GPIO 22 0.07 vdc
GPIO 23 0.05 vdc
GPIO 24 0.02 vdc
GPIO 08 3.25 vdc
GPIO 07 3.25 vdc
GPIO 25 0.01 vdc
Now if GPIO is only measuring 0.06 Volts, that is not enough to power up
the led. Should it be connected to a 3.25V pin instead.
> On Sun, 21 Jan 2018 19:10:48 +0000, RobH <r...@despammer.com> declaimed the
> following:
>
> IOWs, what is the voltage source for the LED?
>
> GPIO -> limit resistor -> LED -> ground (active High -- LED is on when
> GPIO is high/3.3V)
>
> V+ -> limit resistor -> LED -> GPIO (active Low -- LED is on when GPIO
> is low/ground/0V)
>
> In the former, the processor GPIO provides the voltage, so you should
> be seeing the 3.3V maximum, and need to limit the current to that available
> on a GPIO (If the calculator was based on 5V, you should be safe, as you
> are running the LED on less than maximum current given a 3.3V source). In
> the latter, the voltage is provided by some power supply bus -- and if that
> is 5V, and the GPIO is High (conceptually off), you would still have 2.8V
> passing through the resistor/LED being sinked by the GPIO. {Note: my use of
> source/sink may be inconsistent -- I tend to think in terms of higher
> voltage flowing to lower voltage... But electron flow itself is in the
> opposite direction).
>
>
I don't know what the difference between active low and active high wiring.
The voltage source for the led is from the Raspberry pi GPIO 17
I have been following this youtube video:
https://www.youtube.com/watch?v=OEilz2Cq_xY.
I've just done some checking of some of the GPIO pins with a voltmeter,
and got this:
GPIO 17 0.06 vdc
GPIO 27 0.01 vdc
GPIO 22 0.07 vdc
GPIO 23 0.05 vdc
GPIO 24 0.02 vdc
GPIO 08 3.25 vdc
GPIO 07 3.25 vdc
GPIO 25 0.01 vdc
Now if GPIO is only measuring 0.06 Volts, that is not enough to power up
the led. Should it be connected to a 3.25V pin instead.
RobH
Jan 22, 2018, 7:09:24 AM1/22/18
to
led come on or off.
I did some checking of some of the GPIO pins and found this :
GPIO 17 0.06 vdc
GPIO 27 0.01 vdc
GPIO 22 0.07 vdc
GPIO 23 0.05 vdc
GPIO 24 0.02 vdc
GPIO 08 3.25 vdc
GPIO 07 3.25 vdc
GPIO 25 0.01 vdc
will never light up.
Thanks for the link and I also tried the commands from that page , to no
avail.
RobH
Jan 22, 2018, 7:12:42 AM1/22/18
to
I am not using the psu now as I realised it shouldn't be need yet just
for 1 led.
Dave Liquorice
Jan 22, 2018, 8:50:35 AM1/22/18
to
On Mon, 22 Jan 2018 12:09:22 +0000, RobH wrote:
>> Run this command in a terminal
>>
>> gpio -1 mode 11 out
>> gpio -1 toggle 11
>>
>
>> Run this command in a terminal
>>
>> gpio -1 mode 11 out
>> gpio -1 toggle 11
>>
>
> I have ran the commands you asked me to and they did nothing to make the
> led come on or off.
What was shown on screen?
> led come on or off.
gpio is a utilty supplied by WiringPi which I'm fairly sure isn't
included in the Raspbian distribution. Have you installed WiringPi?
--
Cheers
Dave.
RobH
Jan 22, 2018, 11:03:47 AM1/22/18
to
returned the cursor to the pi as in waiting for a command.
No I have not installed WiringPI as I have not heard of it until now.
Gordon Henderson
Jan 22, 2018, 11:14:35 AM1/22/18
to
In article <nyyfbegfubjuvyypb...@news.individual.net>,
wiringPi is installed as standard with Raspbian (full, not lite)
However he did execute the commands. My guess is that the GPIO is
basically dead on this Pi.
Gordon
However he did execute the commands. My guess is that the GPIO is
basically dead on this Pi.
Gordon
RobH
Jan 22, 2018, 11:21:48 AM1/22/18
to
On 22/01/18 15:50, Dennis Lee Bieber wrote:
> On Mon, 22 Jan 2018 11:49:33 +0000, RobH <r...@despammer.com> declaimed the
> following:
>
>>
> is the "normal/off" state for a signal, and one sets the voltage to high to
> turn it on. Active low presumes the "normal/off" state is high voltage, and
> the signal is on when pulled to ground.
> for a GPIO commanded to a Low state, and 3.25 looks appropriate for those
> commanded to be in a High state.
>
> http://www.auctoris.co.uk/2012/07/19/gpio-with-sysfs-on-a-raspberry-pi/
>
> That is: using the sysfs access (export those you were testing), set
> DIRECTION to OUT, then set VALUE to 1... You should now measure around 3.3V
> on the GPIOs (make sure to look at the correct pin mapping to the GPIOs).
> Finally, set VALUE to 0 and measure -- they should now be near 0.0.
> https://elinux.org/RPi_Low-level_peripherals#Interfacing_with_GPIO_pins
> https://learn.sparkfun.com/tutorials/raspberry-gpio/python-rpigpio-api
> (note that the RPi package supports use of the board/socket pin numbers, or
> the chip set internal pin numbers -- if you are wiring using the board
> numbers, but are in chip mode when commanding, you could be corrupting
> something critical to operation)
>
> Note -- in that link they are using a transistor as an electronic gate
> to avoid drawing much current from the GPIO itself.
>
I'm not sure I understander you here:
> But what state were those GPIOs commanded to be in. 0.0x appears
> proper for a GPIO commanded to a Low state, and 3.25 looks
appropriate > for those commanded to be in a High state.
I think you are saying that the measured voltages for some of the GPIO
pins are correct.
> On Mon, 22 Jan 2018 11:49:33 +0000, RobH <r...@despammer.com> declaimed the
> following:
>
>>
>> I don't know what the difference between active low and active high wiring.
>>
>
> I had provided the description... In short, active high presumes ground
>>
>
> is the "normal/off" state for a signal, and one sets the voltage to high to
> turn it on. Active low presumes the "normal/off" state is high voltage, and
> the signal is on when pulled to ground.
>
>
>>
>> I've just done some checking of some of the GPIO pins with a voltmeter,
>> and got this:
>>
>> GPIO 17 0.06 vdc
>> GPIO 27 0.01 vdc
>> GPIO 22 0.07 vdc
>> GPIO 23 0.05 vdc
>> GPIO 24 0.02 vdc
>> GPIO 08 3.25 vdc
>> GPIO 07 3.25 vdc
>> GPIO 25 0.01 vdc
>>
>> Now if GPIO is only measuring 0.06 Volts, that is not enough to power up
>> the led. Should it be connected to a 3.25V pin instead.
>
> But what state were those GPIOs commanded to be in. 0.0x appears proper
>
>>
>> I've just done some checking of some of the GPIO pins with a voltmeter,
>> and got this:
>>
>> GPIO 17 0.06 vdc
>> GPIO 27 0.01 vdc
>> GPIO 22 0.07 vdc
>> GPIO 23 0.05 vdc
>> GPIO 24 0.02 vdc
>> GPIO 08 3.25 vdc
>> GPIO 07 3.25 vdc
>> GPIO 25 0.01 vdc
>>
>> Now if GPIO is only measuring 0.06 Volts, that is not enough to power up
>> the led. Should it be connected to a 3.25V pin instead.
>
> for a GPIO commanded to a Low state, and 3.25 looks appropriate for those
> commanded to be in a High state.
>
> http://www.auctoris.co.uk/2012/07/19/gpio-with-sysfs-on-a-raspberry-pi/
>
> That is: using the sysfs access (export those you were testing), set
> DIRECTION to OUT, then set VALUE to 1... You should now measure around 3.3V
> on the GPIOs (make sure to look at the correct pin mapping to the GPIOs).
> Finally, set VALUE to 0 and measure -- they should now be near 0.0.
> https://elinux.org/RPi_Low-level_peripherals#Interfacing_with_GPIO_pins
> https://learn.sparkfun.com/tutorials/raspberry-gpio/python-rpigpio-api
> (note that the RPi package supports use of the board/socket pin numbers, or
> the chip set internal pin numbers -- if you are wiring using the board
> numbers, but are in chip mode when commanding, you could be corrupting
> something critical to operation)
>
> Note -- in that link they are using a transistor as an electronic gate
> to avoid drawing much current from the GPIO itself.
>
I'm not sure I understander you here:
> But what state were those GPIOs commanded to be in. 0.0x appears
> proper for a GPIO commanded to a Low state, and 3.25 looks
appropriate > for those commanded to be in a High state.
I think you are saying that the measured voltages for some of the GPIO
pins are correct.
Andy Burns
Jan 22, 2018, 11:23:03 AM1/22/18
to
Dave Liquorice wrote:
> gpio is a utilty supplied by WiringPi which I'm fairly sure isn't
> included in the Raspbian distribution.
I have a fresh Pi3 with raspian (not lite) installed via latest NOOBS,
> gpio is a utilty supplied by WiringPi which I'm fairly sure isn't
> included in the Raspbian distribution.
and wiringPi is included.
RobH
Jan 22, 2018, 11:32:26 AM1/22/18
to
On 22/01/18 15:50, Dennis Lee Bieber wrote:
> On Mon, 22 Jan 2018 11:49:33 +0000, RobH <r...@despammer.com> declaimed the
> following:
>
>>
>> I don't know what the difference between active low and active high wiring.
>>
>
>>
>
> I had provided the description... In short, active high presumes ground
> is the "normal/off" state for a signal, and one sets the voltage to high to
> turn it on. Active low presumes the "normal/off" state is high voltage, and
> the signal is on when pulled to ground.
>
>
>>
> is the "normal/off" state for a signal, and one sets the voltage to high to
> turn it on. Active low presumes the "normal/off" state is high voltage, and
> the signal is on when pulled to ground.
>
>
>>
>> I've just done some checking of some of the GPIO pins with a voltmeter,
>> and got this:
>>
>> GPIO 17 0.06 vdc
>> GPIO 27 0.01 vdc
>> GPIO 22 0.07 vdc
>> GPIO 23 0.05 vdc
>> GPIO 24 0.02 vdc
>> GPIO 08 3.25 vdc
>> GPIO 07 3.25 vdc
>> GPIO 25 0.01 vdc
>>
>> Now if GPIO is only measuring 0.06 Volts, that is not enough to power up
>> the led. Should it be connected to a 3.25V pin instead.
>
>> and got this:
>>
>> GPIO 17 0.06 vdc
>> GPIO 27 0.01 vdc
>> GPIO 22 0.07 vdc
>> GPIO 23 0.05 vdc
>> GPIO 24 0.02 vdc
>> GPIO 08 3.25 vdc
>> GPIO 07 3.25 vdc
>> GPIO 25 0.01 vdc
>>
>> Now if GPIO is only measuring 0.06 Volts, that is not enough to power up
>> the led. Should it be connected to a 3.25V pin instead.
>
> But what state were those GPIOs commanded to be in. 0.0x appears proper
> for a GPIO commanded to a Low state, and 3.25 looks appropriate for those
> commanded to be in a High state.
>
> http://www.auctoris.co.uk/2012/07/19/gpio-with-sysfs-on-a-raspberry-pi/
>
> That is: using the sysfs access (export those you were testing), set
> DIRECTION to OUT, then set VALUE to 1... You should now measure around 3.3V
> on the GPIOs (make sure to look at the correct pin mapping to the GPIOs).
> Finally, set VALUE to 0 and measure -- they should now be near 0.0.
> https://elinux.org/RPi_Low-level_peripherals#Interfacing_with_GPIO_pins
> https://learn.sparkfun.com/tutorials/raspberry-gpio/python-rpigpio-api
> (note that the RPi package supports use of the board/socket pin numbers, or
> the chip set internal pin numbers -- if you are wiring using the board
> numbers, but are in chip mode when commanding, you could be corrupting
> something critical to operation)
>
> Note -- in that link they are using a transistor as an electronic gate
> to avoid drawing much current from the GPIO itself.
>
I have exported the GPIO17 pin and it does show up ok, but when I do
> for a GPIO commanded to a Low state, and 3.25 looks appropriate for those
> commanded to be in a High state.
>
> http://www.auctoris.co.uk/2012/07/19/gpio-with-sysfs-on-a-raspberry-pi/
>
> That is: using the sysfs access (export those you were testing), set
> DIRECTION to OUT, then set VALUE to 1... You should now measure around 3.3V
> on the GPIOs (make sure to look at the correct pin mapping to the GPIOs).
> Finally, set VALUE to 0 and measure -- they should now be near 0.0.
> https://elinux.org/RPi_Low-level_peripherals#Interfacing_with_GPIO_pins
> https://learn.sparkfun.com/tutorials/raspberry-gpio/python-rpigpio-api
> (note that the RPi package supports use of the board/socket pin numbers, or
> the chip set internal pin numbers -- if you are wiring using the board
> numbers, but are in chip mode when commanding, you could be corrupting
> something critical to operation)
>
> Note -- in that link they are using a transistor as an electronic gate
> to avoid drawing much current from the GPIO itself.
>
echo echo out > direction OUT or out, I get
-bash: echo: write error: Invalid argument.
RobH
Jan 22, 2018, 12:42:04 PM1/22/18
to
On 22/01/18 17:21, Dennis Lee Bieber wrote:
> On Mon, 22 Jan 2018 16:32:24 +0000, RobH <r...@despammer.com> declaimed the
> following:
>
>>>
> subdirectory?
>
> Try with quotes around "out" (I noticed some differences being used in
> syntax between the web sites)
>
> (as root):
> echo "out" > direction
>
> Dug up my RPi-3, and running via a session from Putty:
>
> pi@raspberrypi:~$
> pi@raspberrypi:~$ sudo su root
> root@raspberrypi:/home/pi# cd /sys/class/gpio
> root@raspberrypi:/sys/class/gpio# ls
> export gpiochip0 gpiochip100 unexport
> root@raspberrypi:/sys/class/gpio# echo 17 > export
>
> Per the diagrams, GPIO17 is connector pin 11 (and pin 9 is ground)
>
> root@raspberrypi:/sys/class/gpio# ls
> export gpio17 gpiochip0 gpiochip100 unexport
> root@raspberrypi:/sys/class/gpio# cd gpio17
> root@raspberrypi:/sys/class/gpio/gpio17# ls
> active_low device direction edge subsystem uevent value
> root@raspberrypi:/sys/class/gpio/gpio17# ls -l
> total 0
> -rwxrwx--- 1 root gpio 4096 Jan 22 11:54 active_low
> lrwxrwxrwx 1 root gpio 0 Jan 22 11:54 device -> ../../../3f200000.gpio
> -rwxrwx--- 1 root gpio 4096 Jan 22 11:54 direction
> -rwxrwx--- 1 root gpio 4096 Jan 22 11:54 edge
> lrwxrwxrwx 1 root gpio 0 Jan 22 11:54 subsystem ->
> ../../../../../../class/gpio
> -rwxrwx--- 1 root gpio 4096 Jan 22 11:54 uevent
> -rwxrwx--- 1 root gpio 4096 Jan 22 11:54 value
> root@raspberrypi:/sys/class/gpio/gpio17# cat active_low direction edge
> uevent value
> 0
> in
> none
> 0
> root@raspberrypi:/sys/class/gpio/gpio17# echo out > direction
>
> No quotes needed in my test
>
> root@raspberrypi:/sys/class/gpio/gpio17# cat active_low direction edge
> uevent value
> 0
> outpi@raspberrypi:/sys/class/gpio/gpio17 $ sudo su root
root@raspberrypi:/sys/devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio17#
echo out > direction out
bash: echo: write error: Invalid argument
root@raspberrypi:/sys/devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio17#
echo out > direction "out"
bash: echo: write error: Invalid argument
root@raspberrypi:/sys/devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio17#
> none
> 0
> root@raspberrypi:/sys/class/gpio/gpio17# echo 1 > value
> root@raspberrypi:/sys/class/gpio/gpio17# cat active_low direction edge
> uevent value
> 0
> out
> none
> 1
>
> DVM read 3.28V between connector pins 11 and 9 (Not easy holding the
> meter probes on the pins, especially as my unit is in a case and the access
> slot isn't that wide)
>
> root@raspberrypi:/sys/class/gpio/gpio17# echo 0 > value
> root@raspberrypi:/sys/class/gpio/gpio17# cat active_low direction edge
> uevent value
> 0
> out
> none
> 0
>
> DVM read 0.00V between connector pins 11 and 9
>
> root@raspberrypi:/sys/class/gpio/gpio17# cd ..
> root@raspberrypi:/sys/class/gpio# echo 17 > unexport
> root@raspberrypi:/sys/class/gpio#
>
>
> {Note: My SD card is still running a Jessie release; I need to spend a day
> reflashing and configuring the latest Raspbian, which I think is now up to
> Stretch}
>
I wasn't running as root but now I am, and this what I got:
pi@raspberrypi:/sys/class/gpio/gpio17 $ sudo su root
root@raspberrypi:/sys/devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio17#
echo out > direction out
bash: echo: write error: Invalid argument
root@raspberrypi:/sys/devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio17#
echo out > direction "out"
bash: echo: write error: Invalid argument
root@raspberrypi:/sys/devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio17#
What am I missing.
For measuring the voltage on the pins, I just used jumper wires as it
was a lot easier than trying it on the pins.
> On Mon, 22 Jan 2018 16:32:24 +0000, RobH <r...@despammer.com> declaimed the
> following:
>
>>>
>> I have exported the GPIO17 pin and it does show up ok, but when I do
>> echo echo out > direction OUT or out, I get
>> -bash: echo: write error: Invalid argument.
>
> You are running as root, are you not? You are also /in/ the gpio17
>> echo echo out > direction OUT or out, I get
>> -bash: echo: write error: Invalid argument.
>
> subdirectory?
>
> Try with quotes around "out" (I noticed some differences being used in
> syntax between the web sites)
>
> (as root):
> echo "out" > direction
>
> Dug up my RPi-3, and running via a session from Putty:
>
> pi@raspberrypi:~$
> pi@raspberrypi:~$ sudo su root
> root@raspberrypi:/home/pi# cd /sys/class/gpio
> root@raspberrypi:/sys/class/gpio# ls
> export gpiochip0 gpiochip100 unexport
> root@raspberrypi:/sys/class/gpio# echo 17 > export
>
> Per the diagrams, GPIO17 is connector pin 11 (and pin 9 is ground)
>
> root@raspberrypi:/sys/class/gpio# ls
> export gpio17 gpiochip0 gpiochip100 unexport
> root@raspberrypi:/sys/class/gpio# cd gpio17
> root@raspberrypi:/sys/class/gpio/gpio17# ls
> active_low device direction edge subsystem uevent value
> root@raspberrypi:/sys/class/gpio/gpio17# ls -l
> total 0
> -rwxrwx--- 1 root gpio 4096 Jan 22 11:54 active_low
> lrwxrwxrwx 1 root gpio 0 Jan 22 11:54 device -> ../../../3f200000.gpio
> -rwxrwx--- 1 root gpio 4096 Jan 22 11:54 direction
> -rwxrwx--- 1 root gpio 4096 Jan 22 11:54 edge
> lrwxrwxrwx 1 root gpio 0 Jan 22 11:54 subsystem ->
> ../../../../../../class/gpio
> -rwxrwx--- 1 root gpio 4096 Jan 22 11:54 uevent
> -rwxrwx--- 1 root gpio 4096 Jan 22 11:54 value
> root@raspberrypi:/sys/class/gpio/gpio17# cat active_low direction edge
> uevent value
> 0
> in
> none
> 0
> root@raspberrypi:/sys/class/gpio/gpio17# echo out > direction
>
> No quotes needed in my test
>
> root@raspberrypi:/sys/class/gpio/gpio17# cat active_low direction edge
> uevent value
> 0
> outpi@raspberrypi:/sys/class/gpio/gpio17 $ sudo su root
root@raspberrypi:/sys/devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio17#
echo out > direction out
bash: echo: write error: Invalid argument
root@raspberrypi:/sys/devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio17#
echo out > direction "out"
bash: echo: write error: Invalid argument
root@raspberrypi:/sys/devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio17#
> none
> 0
> root@raspberrypi:/sys/class/gpio/gpio17# echo 1 > value
> root@raspberrypi:/sys/class/gpio/gpio17# cat active_low direction edge
> uevent value
> 0
> out
> none
> 1
>
> DVM read 3.28V between connector pins 11 and 9 (Not easy holding the
> meter probes on the pins, especially as my unit is in a case and the access
> slot isn't that wide)
>
> root@raspberrypi:/sys/class/gpio/gpio17# echo 0 > value
> root@raspberrypi:/sys/class/gpio/gpio17# cat active_low direction edge
> uevent value
> 0
> out
> none
> 0
>
> DVM read 0.00V between connector pins 11 and 9
>
> root@raspberrypi:/sys/class/gpio/gpio17# cd ..
> root@raspberrypi:/sys/class/gpio# echo 17 > unexport
> root@raspberrypi:/sys/class/gpio#
>
>
> {Note: My SD card is still running a Jessie release; I need to spend a day
> reflashing and configuring the latest Raspbian, which I think is now up to
> Stretch}
>
I wasn't running as root but now I am, and this what I got:
pi@raspberrypi:/sys/class/gpio/gpio17 $ sudo su root
root@raspberrypi:/sys/devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio17#
echo out > direction out
bash: echo: write error: Invalid argument
root@raspberrypi:/sys/devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio17#
echo out > direction "out"
bash: echo: write error: Invalid argument
root@raspberrypi:/sys/devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio17#
What am I missing.
For measuring the voltage on the pins, I just used jumper wires as it
was a lot easier than trying it on the pins.
RobH
Jan 22, 2018, 12:44:16 PM1/22/18
to
install it.
Andy Burns
Jan 22, 2018, 12:52:02 PM1/22/18
to
RobH wrote:
> How do I find out if it is installed or not, and if not, should I
> install it.
If you just type gpio in a terminal window and press return, if it's
> How do I find out if it is installed or not, and if not, should I
> install it.
installed it'll give you some usage information, if not installed it'll
complain no command found.
RobH
Jan 22, 2018, 1:38:22 PM1/22/18
to
RobH
Jan 22, 2018, 1:53:37 PM1/22/18
to
On 22/01/18 15:50, Dennis Lee Bieber wrote:
> On Mon, 22 Jan 2018 11:49:33 +0000, RobH <r...@despammer.com> declaimed the
> following:
>
>>
>> I don't know what the difference between active low and active high wiring.
>>
>
>>
>
> I had provided the description... In short, active high presumes ground
> is the "normal/off" state for a signal, and one sets the voltage to high to
> turn it on. Active low presumes the "normal/off" state is high voltage, and
> the signal is on when pulled to ground.
>
>
>>
> is the "normal/off" state for a signal, and one sets the voltage to high to
> turn it on. Active low presumes the "normal/off" state is high voltage, and
> the signal is on when pulled to ground.
>
>
>>
>> I've just done some checking of some of the GPIO pins with a voltmeter,
>> and got this:
>>
>> GPIO 17 0.06 vdc
>> GPIO 27 0.01 vdc
>> GPIO 22 0.07 vdc
>> GPIO 23 0.05 vdc
>> GPIO 24 0.02 vdc
>> GPIO 08 3.25 vdc
>> GPIO 07 3.25 vdc
>> GPIO 25 0.01 vdc
>>
>> Now if GPIO is only measuring 0.06 Volts, that is not enough to power up
>> the led. Should it be connected to a 3.25V pin instead.
>
>> and got this:
>>
>> GPIO 17 0.06 vdc
>> GPIO 27 0.01 vdc
>> GPIO 22 0.07 vdc
>> GPIO 23 0.05 vdc
>> GPIO 24 0.02 vdc
>> GPIO 08 3.25 vdc
>> GPIO 07 3.25 vdc
>> GPIO 25 0.01 vdc
>>
>> Now if GPIO is only measuring 0.06 Volts, that is not enough to power up
>> the led. Should it be connected to a 3.25V pin instead.
>
> But what state were those GPIOs commanded to be in. 0.0x appears proper
> for a GPIO commanded to a Low state, and 3.25 looks appropriate for those
> commanded to be in a High state.
>
> http://www.auctoris.co.uk/2012/07/19/gpio-with-sysfs-on-a-raspberry-pi/
>
> That is: using the sysfs access (export those you were testing), set
> DIRECTION to OUT, then set VALUE to 1... You should now measure around 3.3V
> on the GPIOs (make sure to look at the correct pin mapping to the GPIOs).
> Finally, set VALUE to 0 and measure -- they should now be near 0.0.
> https://elinux.org/RPi_Low-level_peripherals#Interfacing_with_GPIO_pins
> https://learn.sparkfun.com/tutorials/raspberry-gpio/python-rpigpio-api
> (note that the RPi package supports use of the board/socket pin numbers, or
> the chip set internal pin numbers -- if you are wiring using the board
> numbers, but are in chip mode when commanding, you could be corrupting
> something critical to operation)
>
> Note -- in that link they are using a transistor as an electronic gate
> to avoid drawing much current from the GPIO itself.
>
I have just measured the voltage on GPIO17 and it is still as it was
> for a GPIO commanded to a Low state, and 3.25 looks appropriate for those
> commanded to be in a High state.
>
> http://www.auctoris.co.uk/2012/07/19/gpio-with-sysfs-on-a-raspberry-pi/
>
> That is: using the sysfs access (export those you were testing), set
> DIRECTION to OUT, then set VALUE to 1... You should now measure around 3.3V
> on the GPIOs (make sure to look at the correct pin mapping to the GPIOs).
> Finally, set VALUE to 0 and measure -- they should now be near 0.0.
> https://elinux.org/RPi_Low-level_peripherals#Interfacing_with_GPIO_pins
> https://learn.sparkfun.com/tutorials/raspberry-gpio/python-rpigpio-api
> (note that the RPi package supports use of the board/socket pin numbers, or
> the chip set internal pin numbers -- if you are wiring using the board
> numbers, but are in chip mode when commanding, you could be corrupting
> something critical to operation)
>
> Note -- in that link they are using a transistor as an electronic gate
> to avoid drawing much current from the GPIO itself.
>
before at 0.06 volts.
RobH
Jan 22, 2018, 3:22:11 PM1/22/18
to
On 22/01/18 19:33, Dennis Lee Bieber wrote:
> On Mon, 22 Jan 2018 18:53:35 +0000, RobH <r...@despammer.com> declaimed the
> following:
>
>>>
> and /value were set properly. The default state seems to be INput with the
> pin pulled down to ground (value shows 0).
>
> And /that/ requires being able to control things from the command line.
> Until you can successfully set /direction to out, and /value to 1, the pin
> voltage is expected to be near ground (except for the two pins that are
> pulled high)
>
Direction and value are set
root@raspberrypi:/sys/class/gpio/gpio17# echo out > direction
>>> GPIO.setup(17, GPIO.OUT)
>>> GPIO.output(17, GPIO.HIGH)
To get it give 3.3 volts, but it didn't
> On Mon, 22 Jan 2018 18:53:35 +0000, RobH <r...@despammer.com> declaimed the
> following:
>
>>>
>> I have just measured the voltage on GPIO17 and it is still as it was
>> before at 0.06 volts.
>>
>
> Measurement of the pins is meaningless without knowing that /direction
>> before at 0.06 volts.
>>
>
> and /value were set properly. The default state seems to be INput with the
> pin pulled down to ground (value shows 0).
>
> And /that/ requires being able to control things from the command line.
> Until you can successfully set /direction to out, and /value to 1, the pin
> voltage is expected to be near ground (except for the two pins that are
> pulled high)
>
Direction and value are set
root@raspberrypi:/sys/class/gpio/gpio17# echo out > direction
root@raspberrypi:/sys/class/gpio/gpio17# echo 1 > value
root@raspberrypi:/sys/class/gpio/gpio17#
I also tried:
root@raspberrypi:/sys/class/gpio/gpio17#
>>> GPIO.setup(17, GPIO.OUT)
>>> GPIO.output(17, GPIO.HIGH)
To get it give 3.3 volts, but it didn't
Dave Liquorice
Jan 22, 2018, 5:47:37 PM1/22/18
to
Lite installed on them before Christmas by downloading the image and
copying to card.
--
Cheers
Dave.
Dave Liquorice
Jan 22, 2018, 5:56:11 PM1/22/18
to
On Mon, 22 Jan 2018 16:14:34 -0000 (UTC), Gordon Henderson wrote:
>> gpio is a utilty supplied by WiringPi which I'm fairly sure isn't
>> included in the Raspbian distribution. Have you installed
WiringPi?
>
> wiringPi is installed as standard with Raspbian (full, not lite)
That'll be why I don't have wiringPi on two Oi's here, I use Lite...
>> gpio is a utilty supplied by WiringPi which I'm fairly sure isn't
>> included in the Raspbian distribution. Have you installed
WiringPi?
>
> wiringPi is installed as standard with Raspbian (full, not lite)
> However he did execute the commands.
when no parameters are supplied or just returning to the prompt shows
that gpio is there.
> My guess is that the GPIO is basically dead on this Pi.
correct for the GPIO and that the LED is connected to the correct pin
for that GPIO.
If the OP only wants to flash one LED, then hopefully one of the
other GPIO's will work.
--
Cheers
Dave.
Gordon Henderson
Jan 23, 2018, 4:15:02 AM1/23/18
to
gpio -v
It ought to read 2.44 (or greater) if wiringPi is installed. If it's not
installed, then:
sudo apt-get install wiringpi
will get it for you. (Assuming Raspbian or a Raspbian derived system)
The command:
gpio readall
will always give you a handy print out of the GPIO connector with the
3 different pin numbering schemes. wiringPi by default uses it's own
numbering scheme, but with the -g flag to the gpio program it uses
the native gpio pin numbers and with the -1 flag it uses the physical
pin numbers (On the original Pi the connector was marked P1, hence the -1 flag)
Pin numbering can be confusing, see this:
https://projects.drogon.net/wiringpi-pin-numbering/
The best pin out site is the Pimoroni one at
https://pinout.xyz/
A very simple way to get/test a pin with an LED is 'blink', see here:
https://projects.drogon.net/raspberry-pi/gpio-examples/blink/
I would strongly suggest that newbies do not jump into code, nor that
they try to use the sysfs interface either when starting out - it's just
too much to do, learn and get wrong - this one command is all you need:
gpio -g blink 17
to test an LED on BCM_GPIO pin 17, wiringPi pin 0, physical pin 11.
Gordon
(wiringPi author)
RobH
Jan 23, 2018, 5:08:27 AM1/23/18
to
On 22/01/18 19:33, Dennis Lee Bieber wrote:
> On Mon, 22 Jan 2018 18:53:35 +0000, RobH <r...@despammer.com> declaimed the
> following:
>
>>>
for pin 17:
BCM 17
wPi 0
Name GPIO. 0
Mode OUT
Physical 11
So Pin 11 is set to OUT as I read it.
> On Mon, 22 Jan 2018 18:53:35 +0000, RobH <r...@despammer.com> declaimed the
> following:
>
>>>
>> I have just measured the voltage on GPIO17 and it is still as it was
>> before at 0.06 volts.
>>
>
>> before at 0.06 volts.
>>
>
> Measurement of the pins is meaningless without knowing that /direction
> and /value were set properly. The default state seems to be INput with the
> pin pulled down to ground (value shows 0).
>
> And /that/ requires being able to control things from the command line.
> Until you can successfully set /direction to out, and /value to 1, the pin
> voltage is expected to be near ground (except for the two pins that are
> pulled high)
>
Now according to wiringPi, when I do a gpio readall, I get the following
> and /value were set properly. The default state seems to be INput with the
> pin pulled down to ground (value shows 0).
>
> And /that/ requires being able to control things from the command line.
> Until you can successfully set /direction to out, and /value to 1, the pin
> voltage is expected to be near ground (except for the two pins that are
> pulled high)
>
for pin 17:
BCM 17
wPi 0
Name GPIO. 0
Mode OUT
Physical 11
So Pin 11 is set to OUT as I read it.
RobH
Jan 23, 2018, 5:10:16 AM1/23/18
to
installed on my Pi3. Interestingly when I do a gpio readall, it shows that:
BCM 17
wPi 0
Name GPIO. 0
Physical 11
All the other pins are shown as Mode IN.
Henri Derksen
Jan 23, 2018, 10:11:29 AM1/23/18
to
Hello RobH,
RH> I have been trying to get a simple led project to work on my pi 3 using
RH> a 5 volt 6 amp power supply and a 510 ohm resistor in front of the led
RH> to reduce the current going to it. Now after trying different tutorials,
RH> my pi 3 goes off on it's own from being powered up.
RH> If I remove the power lead and restart the pi 3 the red comes on and the
RH> green led flashes as well as the ethernet port flashing green led.
RH> I ssh into the pi 3 to try and run a python program, but then the pi
RH> dies, and there are no lit up leds anywhere at all on it.
RH> Is there any way it can be fixed or should I just forget about it.
Me is told to never draw more power from your Pi than 2 Amps at a Pi 2B,
or not more then 2.5 Amps on a Pi 3B.
If you connect a 5 Vdc= 6 Amp power supply to your Pi's input power socket,
and you took more dan 2.5 Amps from it by GPIO or USB devices,
you will blow the power input fuse from your Pi 3B's input power socket.
So if you need more power then that the Pi can handle, buy an external powered
USB2 hub, or power the GPIO externally with buffers (resistors),
as others told here.
So giving your Pi a higher Amperage feeding than it can handle is potentially
dangeroues. I.e. feeding a Pi 2B with a 2.5 Amps Pi 3B power supply, or feeding
a Pi 3B with a 4, 5 or 6 Amps power supply.
So keep it at max or below 2.5 Amps for the Pi 3B and max or below 2 Amps for
all the other Pi's.
You know each USB port may only take 0.5 Amps as a max.,
but donot exceed the max. Amperage the Pi can handle, or your Pi will go down,
i.e. stops running. That can crash the software on the SDcard.
Some friends of me at ships are unpatient and donot shut down OpenCPN and
Rasbian Linux, but pull the power plug ones when they are ready vieuw ECDIS
charts. They were surprised that their Linux was broken.
I had to fill their SDcard with a complete setup, and their Pi worked again
in good condition. It happend more times with the same skipper, so he
asked me for a backup SDcard when this happened more times.
Some people do not study to handle computers the right way ;-(.
Ofcourse I will help people to go on, but at some point it has to stop.
This power in fuse is also the reason to feed in a light higher Voltage of
about 5.1 Vdc= to the Pi's power input, as the Pi does not like a too low
Voltage on its power input port. That fuse also lowers the Voltage a bit.
At ships it could be a reason to power it directly via a step down dc-dc buck
power converter from the batteries 24 Vdc= to 5.2 Vdc= to avoid problems
with the usually installed 24 Vdc= to 230 Vac~ / 50 Hz inverter,
and than use the normal 230 to 5 adapter.
Because if the 230 Vac~ inverter shuts down suddenly, your microSDcard could
get broken software on it ;-(.
With the Pi at 24 Vdc= to 5.2 Vdc=, you have time to shut down normally.
Or immediate start the generator to fill the ships battery and the inverter
will also start up again. Then the monitor at 230 Vac~ will show pictures again
but the Pi at 24 Vdc= did go on during the inverter down period.
So always make BackUps of your good working (micro-)SDcard.
My third option would be to use the Pi 3B with his own keyboard, mouse and
monitor to see how it functions. With SSH you donot see everything I think.
Hope this helps? Good luck in getting your Pi 3B working again.
My own experience:
My first Pi 3B got a totally dead USBus when I was looking at pictures on a USB
stick with clicking at a mouse to find some special photo.
When doing that my one year new Elesar USB keyboard with red function keys
(Acorn BBC Style) got defect and blowed up the Pi 3B's USB.
The mouse, USB and Micro SD card worked OK in my Pi 2B,
but my Elesar red function keys keybord had been died ;-(
It was expensive at Euro 99,00 in 2016.
The Pi 3B booted normally and I got a good window screen and programs run,
but I could not use another keyboard and mouse any more at no USB port.
Unluckily I had closed down SSH, so I could not reach my Pi 3B then.
That was because SSH is default (=your fault) allways ON,
and it is not wise when the default password is not changend ;-(.
Especially when the Pi is also connected to the outside InterNet.
I got a new Pi 3B under garantee, and the first thing I did was changing the
default password to something else, and leave SSH default ON.
I wrote down that new password in a textfile on another home computer.
Normally you hardly need it, as the Pi starts automatically.
I think it is still strange that the keyboard broke at the moment I did not use
it at all, because I was busy with the mouse.
But may be continues clicking to see the next picture generates a kind of an
USB data pulse the keyboard electronics could not handle?
But that should not happen methinks.
Both Pi 3B and (red) keyboard were stuck ;-(.
Who has seen such a (strange) behavior before?
Henri.
RH> I have been trying to get a simple led project to work on my pi 3 using
RH> a 5 volt 6 amp power supply and a 510 ohm resistor in front of the led
RH> to reduce the current going to it. Now after trying different tutorials,
RH> my pi 3 goes off on it's own from being powered up.
RH> If I remove the power lead and restart the pi 3 the red comes on and the
RH> green led flashes as well as the ethernet port flashing green led.
RH> I ssh into the pi 3 to try and run a python program, but then the pi
RH> dies, and there are no lit up leds anywhere at all on it.
RH> Is there any way it can be fixed or should I just forget about it.
Me is told to never draw more power from your Pi than 2 Amps at a Pi 2B,
or not more then 2.5 Amps on a Pi 3B.
If you connect a 5 Vdc= 6 Amp power supply to your Pi's input power socket,
and you took more dan 2.5 Amps from it by GPIO or USB devices,
you will blow the power input fuse from your Pi 3B's input power socket.
So if you need more power then that the Pi can handle, buy an external powered
USB2 hub, or power the GPIO externally with buffers (resistors),
as others told here.
So giving your Pi a higher Amperage feeding than it can handle is potentially
dangeroues. I.e. feeding a Pi 2B with a 2.5 Amps Pi 3B power supply, or feeding
a Pi 3B with a 4, 5 or 6 Amps power supply.
So keep it at max or below 2.5 Amps for the Pi 3B and max or below 2 Amps for
all the other Pi's.
You know each USB port may only take 0.5 Amps as a max.,
but donot exceed the max. Amperage the Pi can handle, or your Pi will go down,
i.e. stops running. That can crash the software on the SDcard.
Some friends of me at ships are unpatient and donot shut down OpenCPN and
Rasbian Linux, but pull the power plug ones when they are ready vieuw ECDIS
charts. They were surprised that their Linux was broken.
I had to fill their SDcard with a complete setup, and their Pi worked again
in good condition. It happend more times with the same skipper, so he
asked me for a backup SDcard when this happened more times.
Some people do not study to handle computers the right way ;-(.
Ofcourse I will help people to go on, but at some point it has to stop.
This power in fuse is also the reason to feed in a light higher Voltage of
about 5.1 Vdc= to the Pi's power input, as the Pi does not like a too low
Voltage on its power input port. That fuse also lowers the Voltage a bit.
At ships it could be a reason to power it directly via a step down dc-dc buck
power converter from the batteries 24 Vdc= to 5.2 Vdc= to avoid problems
with the usually installed 24 Vdc= to 230 Vac~ / 50 Hz inverter,
and than use the normal 230 to 5 adapter.
Because if the 230 Vac~ inverter shuts down suddenly, your microSDcard could
get broken software on it ;-(.
With the Pi at 24 Vdc= to 5.2 Vdc=, you have time to shut down normally.
Or immediate start the generator to fill the ships battery and the inverter
will also start up again. Then the monitor at 230 Vac~ will show pictures again
but the Pi at 24 Vdc= did go on during the inverter down period.
So always make BackUps of your good working (micro-)SDcard.
My third option would be to use the Pi 3B with his own keyboard, mouse and
monitor to see how it functions. With SSH you donot see everything I think.
Hope this helps? Good luck in getting your Pi 3B working again.
My own experience:
My first Pi 3B got a totally dead USBus when I was looking at pictures on a USB
stick with clicking at a mouse to find some special photo.
When doing that my one year new Elesar USB keyboard with red function keys
(Acorn BBC Style) got defect and blowed up the Pi 3B's USB.
The mouse, USB and Micro SD card worked OK in my Pi 2B,
but my Elesar red function keys keybord had been died ;-(
It was expensive at Euro 99,00 in 2016.
The Pi 3B booted normally and I got a good window screen and programs run,
but I could not use another keyboard and mouse any more at no USB port.
Unluckily I had closed down SSH, so I could not reach my Pi 3B then.
That was because SSH is default (=your fault) allways ON,
and it is not wise when the default password is not changend ;-(.
Especially when the Pi is also connected to the outside InterNet.
I got a new Pi 3B under garantee, and the first thing I did was changing the
default password to something else, and leave SSH default ON.
I wrote down that new password in a textfile on another home computer.
Normally you hardly need it, as the Pi starts automatically.
I think it is still strange that the keyboard broke at the moment I did not use
it at all, because I was busy with the mouse.
But may be continues clicking to see the next picture generates a kind of an
USB data pulse the keyboard electronics could not handle?
But that should not happen methinks.
Both Pi 3B and (red) keyboard were stuck ;-(.
Who has seen such a (strange) behavior before?
Henri.
RobH
Jan 23, 2018, 11:43:23 AM1/23/18
to
On 23/01/18 15:30, Dennis Lee Bieber wrote:
> On Tue, 23 Jan 2018 10:10:14 +0000, RobH <r...@despammer.com> declaimed the
> following:
>
>
> But what does any of:
>
> gpio -g read 17
> gpio read 0
> gpio -1 read 11
>
> produce. Readall appears to merely report the direction, the chip pin, the
> header pin, and the WiringPI number&name. Unless the pin, in OUT mode,
> comes back as high (1) internally the physical pin will measure near GND
> level. If it does read back as high, and the physical pin is still near
> GND, you may have a bad chip -- in that the pin driver is not providing a
> signal... Double check by setting mode IN, jumpering pin first to ground
> and reading it (should be low/0), then jumper to 3.3V [DO NOT TOUCH 5V with
> the jumper] and again reading (should be high/1).
>
> If I had physical access, I'd probably do a verification run by writing
> 0, measuring all pins relative to ground, then writing 1 and measuring all
> pins again -- looking for any pin that changed value. If a pin changes
> value -- stay on that pin with the meter and alternately command the system
> to 0 and 1 to see if the value follows the commanded writes.
>
All of the above commands return 0
I set the direction to IN then did gpio readall which shows the gpio17
pin as IN and 0 voltage.
Then I connected the positive jumper wire to the 3.3 volt pin, and then
measured th voltage across the positive and ground wires, which was 3.28
Volts.
> On Tue, 23 Jan 2018 10:10:14 +0000, RobH <r...@despammer.com> declaimed the
> following:
>
>> Thanks for the information about wiringPi, and yes it is already
>> installed on my Pi3. Interestingly when I do a gpio readall, it shows that:
>>
>> BCM 17
>> wPi 0
>> Name GPIO. 0
>> Mode OUT.
>> Physical 11
>>
>> All the other pins are shown as Mode IN.
>
> Which implies that something executed a mode OUT setting...
>> installed on my Pi3. Interestingly when I do a gpio readall, it shows that:
>>
>> BCM 17
>> wPi 0
>> Name GPIO. 0
>> Mode OUT.
>> Physical 11
>>
>> All the other pins are shown as Mode IN.
>
>
> But what does any of:
>
> gpio -g read 17
> gpio read 0
> gpio -1 read 11
>
> produce. Readall appears to merely report the direction, the chip pin, the
> header pin, and the WiringPI number&name. Unless the pin, in OUT mode,
> comes back as high (1) internally the physical pin will measure near GND
> level. If it does read back as high, and the physical pin is still near
> GND, you may have a bad chip -- in that the pin driver is not providing a
> signal... Double check by setting mode IN, jumpering pin first to ground
> and reading it (should be low/0), then jumper to 3.3V [DO NOT TOUCH 5V with
> the jumper] and again reading (should be high/1).
>
> If I had physical access, I'd probably do a verification run by writing
> 0, measuring all pins relative to ground, then writing 1 and measuring all
> pins again -- looking for any pin that changed value. If a pin changes
> value -- stay on that pin with the meter and alternately command the system
> to 0 and 1 to see if the value follows the commanded writes.
>
All of the above commands return 0
I set the direction to IN then did gpio readall which shows the gpio17
pin as IN and 0 voltage.
Then I connected the positive jumper wire to the 3.3 volt pin, and then
measured th voltage across the positive and ground wires, which was 3.28
Volts.
Gordon Henderson
Jan 23, 2018, 12:27:42 PM1/23/18
to
In article <1856...@f1208.n280.z2.binkp.net>,
The Pi (or any electronic device) will only draw what it needs. You
could use a 5v, 1000 amp PSU on a Pi and it'll be fine.
The Pi v2 and v3 both have a 2.5 amp polyfuse (self resetting) on the
5v input.
Additionally the USB system has an overall current limit of 1.2 amps -
this is limited by a little bit of electronics (switchable from 0.6 amps
to 1.2 amps on the v2, but not switchable on the v3). You can pull 1.2
amps out of one USB socket or spread over all 4.
The 5v power output on the GPIO pin has no separate limiter (other than
the input polyfuse) and there it is possible to 'crowbar' the Pi and
cause it to powerdown/reboot if you short the 5v to 0v. The input fuse
is there to stop the PCB melting.
What you don't have much protection from is connecting the 5v signal
directly to a GPIO pin - then you have 5v going into a 3.3v system. If
the 3.3v pin is set to output then you can destroy the output driver
(and possibly other things too). You mostly get away with it if the pin
is set to input mode.
Gordon
Henri Derksen <nospam.Hen...@f1208.n280.z2.binkp.net> wrote:
>Me is told to never draw more power from your Pi than 2 Amps at a Pi 2B,
>or not more then 2.5 Amps on a Pi 3B.
>If you connect a 5 Vdc= 6 Amp power supply to your Pi's input power socket,
>and you took more dan 2.5 Amps from it by GPIO or USB devices,
>you will blow the power input fuse from your Pi 3B's input power socket.
>So if you need more power then that the Pi can handle, buy an external powered
>USB2 hub, or power the GPIO externally with buffers (resistors),
>as others told here.
>So giving your Pi a higher Amperage feeding than it can handle is potentially
>dangeroues. I.e. feeding a Pi 2B with a 2.5 Amps Pi 3B power supply, or feeding
>a Pi 3B with a 4, 5 or 6 Amps power supply.
>So keep it at max or below 2.5 Amps for the Pi 3B and max or below 2 Amps for
>all the other Pi's.
>You know each USB port may only take 0.5 Amps as a max.,
>but donot exceed the max. Amperage the Pi can handle, or your Pi will go down,
>i.e. stops running. That can crash the software on the SDcard.
Hm.
>Me is told to never draw more power from your Pi than 2 Amps at a Pi 2B,
>or not more then 2.5 Amps on a Pi 3B.
>If you connect a 5 Vdc= 6 Amp power supply to your Pi's input power socket,
>and you took more dan 2.5 Amps from it by GPIO or USB devices,
>you will blow the power input fuse from your Pi 3B's input power socket.
>So if you need more power then that the Pi can handle, buy an external powered
>USB2 hub, or power the GPIO externally with buffers (resistors),
>as others told here.
>So giving your Pi a higher Amperage feeding than it can handle is potentially
>dangeroues. I.e. feeding a Pi 2B with a 2.5 Amps Pi 3B power supply, or feeding
>a Pi 3B with a 4, 5 or 6 Amps power supply.
>So keep it at max or below 2.5 Amps for the Pi 3B and max or below 2 Amps for
>all the other Pi's.
>You know each USB port may only take 0.5 Amps as a max.,
>but donot exceed the max. Amperage the Pi can handle, or your Pi will go down,
>i.e. stops running. That can crash the software on the SDcard.
The Pi (or any electronic device) will only draw what it needs. You
could use a 5v, 1000 amp PSU on a Pi and it'll be fine.
The Pi v2 and v3 both have a 2.5 amp polyfuse (self resetting) on the
5v input.
Additionally the USB system has an overall current limit of 1.2 amps -
this is limited by a little bit of electronics (switchable from 0.6 amps
to 1.2 amps on the v2, but not switchable on the v3). You can pull 1.2
amps out of one USB socket or spread over all 4.
The 5v power output on the GPIO pin has no separate limiter (other than
the input polyfuse) and there it is possible to 'crowbar' the Pi and
cause it to powerdown/reboot if you short the 5v to 0v. The input fuse
is there to stop the PCB melting.
What you don't have much protection from is connecting the 5v signal
directly to a GPIO pin - then you have 5v going into a 3.3v system. If
the 3.3v pin is set to output then you can destroy the output driver
(and possibly other things too). You mostly get away with it if the pin
is set to input mode.
Gordon
Gordon Henderson
Jan 23, 2018, 12:34:09 PM1/23/18
to
In article <7fke6dd88u1b9lg9m...@4ax.com>,
at the 'V' column. V for Value.
The thing you can't read the state of is the internal pull up/down
resistors. These are write only.
Gordon
Dennis Lee Bieber <wlf...@ix.netcom.com> wrote:
>On Tue, 23 Jan 2018 10:10:14 +0000, RobH <r...@despammer.com> declaimed the
>following:
>
>On Tue, 23 Jan 2018 10:10:14 +0000, RobH <r...@despammer.com> declaimed the
>following:
>
>>Thanks for the information about wiringPi, and yes it is already
>>installed on my Pi3. Interestingly when I do a gpio readall, it shows that:
>>
>>BCM 17
>>wPi 0
>>Name GPIO. 0
>>Mode OUT.
>>Physical 11
>>
>>All the other pins are shown as Mode IN.
>
>>installed on my Pi3. Interestingly when I do a gpio readall, it shows that:
>>
>>BCM 17
>>wPi 0
>>Name GPIO. 0
>>Mode OUT.
>>Physical 11
>>
>>All the other pins are shown as Mode IN.
>
> Which implies that something executed a mode OUT setting...
>
> But what does any of:
>
>gpio -g read 17
>gpio read 0
>gpio -1 read 11
>
>produce. Readall appears to merely report the direction, the chip pin, the
>header pin, and the WiringPI number&name.
gpio readall does a read of the pin as well as it's direction. Look
>
> But what does any of:
>
>gpio -g read 17
>gpio read 0
>gpio -1 read 11
>
>produce. Readall appears to merely report the direction, the chip pin, the
>header pin, and the WiringPI number&name.
at the 'V' column. V for Value.
The thing you can't read the state of is the internal pull up/down
resistors. These are write only.
Gordon
RobH
Jan 23, 2018, 2:09:53 PM1/23/18
to
On 23/01/18 18:53, Dennis Lee Bieber wrote:
> On Tue, 23 Jan 2018 16:43:21 +0000, RobH <r...@despammer.com> declaimed the
> following:
>
>
> presume that the GPIO circuitry is blown (or there is confusion as to which
> pin is really being tested). I'm using the -1 option to specify the
> physical header pin
>
> gpio -1 mode 11 in
> #header 11 jumpered to GND (header pin 9, as I recall, is a ground)
> gpio -1 read 11
> #should be 0
> #now jumper header 11 to 3.3V (header pin 1 or header pin 17)
> gpio -1 read 11
> #should be 1 -- if it is still 0, dead GPIO circuit
>
> #with nothing connected to header pin 11
> gpio -1 read 11
> #should be 0
> gpio -1 write 11 1
> gpio -1 read 11
> #should be 1, if this is 0 a REALLY dead GPIO, as the internal latches
> can't hold an output value.
>
When I do
pi@raspberrypi:~ $ gpio -1 mode 11 in
pi@raspberrypi:~ $ gpio -1 read 11
0
pi@raspberrypi:~ $ gpio -1 read 11 Jumper header to 3.3v
Now nothing connected to the gpio pins
pi@raspberrypi:~ $ gpio -1 mode 11 out
pi@raspberrypi:~ $ gpio -1 write 11 0
pi@raspberrypi:~ $ gpio read 11
1
> On Tue, 23 Jan 2018 16:43:21 +0000, RobH <r...@despammer.com> declaimed the
> following:
>
>
>> All of the above commands return 0
>>
>> I set the direction to IN then did gpio readall which shows the gpio17
>> pin as IN and 0 voltage.
>>
>> Then I connected the positive jumper wire to the 3.3 volt pin, and then
>> measured th voltage across the positive and ground wires, which was 3.28
>> Volts.
>
> If the sequence (below) always reports 0, then it would be safe to
>>
>> I set the direction to IN then did gpio readall which shows the gpio17
>> pin as IN and 0 voltage.
>>
>> Then I connected the positive jumper wire to the 3.3 volt pin, and then
>> measured th voltage across the positive and ground wires, which was 3.28
>> Volts.
>
> presume that the GPIO circuitry is blown (or there is confusion as to which
> pin is really being tested). I'm using the -1 option to specify the
> physical header pin
>
> gpio -1 mode 11 in
> #header 11 jumpered to GND (header pin 9, as I recall, is a ground)
> gpio -1 read 11
> #should be 0
> #now jumper header 11 to 3.3V (header pin 1 or header pin 17)
> gpio -1 read 11
> #should be 1 -- if it is still 0, dead GPIO circuit
>
> #with nothing connected to header pin 11
> gpio -1 mode 11 out
> gpio -1 write 11 0
> gpio -1 read 11
> #should be 0
> gpio -1 write 11 1
> gpio -1 read 11
> #should be 1, if this is 0 a REALLY dead GPIO, as the internal latches
> can't hold an output value.
>
When I do
pi@raspberrypi:~ $ gpio -1 mode 11 in
pi@raspberrypi:~ $ gpio -1 read 11
0
pi@raspberrypi:~ $ gpio -1 read 11 Jumper header to 3.3v
0
gpio -1 read 11
0
gpio -1 read 11
Now nothing connected to the gpio pins
pi@raspberrypi:~ $ gpio -1 mode 11 out
pi@raspberrypi:~ $ gpio -1 write 11 0
pi@raspberrypi:~ $ gpio read 11
1
RobH
Jan 23, 2018, 3:39:18 PM1/23/18
to
RobH
Jan 23, 2018, 3:50:48 PM1/23/18
to
On 23/01/18 19:28, Dennis Lee Bieber wrote:
> gpio -1 read 11
I have just redone all of the commands again now:
pi@raspberrypi:~ $ gpio -1 mode 11 out
pi@raspberrypi:~ $ gpio -1 write 11 0
pi@raspberrypi:~ $ gpio read 11 < I intentionally left out -1
1
1
> gpio -1 read 11
I have just redone all of the commands again now:
pi@raspberrypi:~ $ gpio -1 mode 11 out
pi@raspberrypi:~ $ gpio -1 write 11 0
1
pi@raspberrypi:~ $ gpio -1 read 11
0
pi@raspberrypi:~ $ gpio read 11
0
1
pi@raspberrypi:~ $ gpio -1 mode 11 out
pi@raspberrypi:~ $ gpio -1 write 11 0
pi@raspberrypi:~ $ gpio -1 write 11 0
pi@raspberrypi:~ $ gpio -1 read 11
0
pi@raspberrypi:~ $ gpio -1 write 11 1
0
Dennis
Jan 23, 2018, 6:05:18 PM1/23/18
to
On 01/23/2018 03:32 PM, Dennis Lee Bieber wrote:
> On Tue, 23 Jan 2018 20:50:46 +0000, RobH <r...@despammer.com> declaimed the
> following:
>
> working system shows:
>
> pi@raspberrypi:~$ gpio -1 mode 11 out
> pi@raspberrypi:~$ gpio -1 read 11
> 0
> pi@raspberrypi:~$ gpio -1 write 11 1
> pi@raspberrypi:~$
>
> Time to check the other GPIO pins for internal functioning. Looking at
> the result of readall, those would be physical/header pins 7, 13, 15, 29,
> 31, 33, 35, 37, 12, 16, 18, 22, 32, 36, 38, 40. Find out if any GPIO are
> working for output. I don't know the internals of the SoC, but could see a
> case where all GPIOs could be killed by one overload, without killing the
> rest of the SoC.
>
> I don't do BASH shell scripts, or I'd provide one that encapsulates the
> above 5 commands with a parameter for the pin number to speed up the
> testing. In lieu, guess it would be [^] (cursor up) to recall each command
> for editing the pin number (which should be faster than retyping each from
> scratch).
>
Something like
#!/bin/bash
# test Raspberry Pi gpio pins
for pin in 7 13 15 29 31 33 35 37 12 16 18 22 32 36 38 40
do
gpio -1 mode $pin out
gpio -1 read $pin
gpio -1 write $pin 1
gpio -1 read $pin
done
save as testpins.bash and then
chmod +x testpins.bash
./testpins.bash
> On Tue, 23 Jan 2018 20:50:46 +0000, RobH <r...@despammer.com> declaimed the
> following:
>
>> pi@raspberrypi:~ $ gpio -1 write 11 1
>> pi@raspberrypi:~ $ gpio -1 read 11
>> 0
>> pi@raspberrypi:~ $
>
> At this point I decree that chip GPIO to be totally gone... As a
>> pi@raspberrypi:~ $ gpio -1 read 11
>> 0
>> pi@raspberrypi:~ $
>
> working system shows:
>
> pi@raspberrypi:~$ gpio -1 mode 11 out
> pi@raspberrypi:~$ gpio -1 read 11
> 0
> pi@raspberrypi:~$ gpio -1 write 11 1
> pi@raspberrypi:~$ gpio -1 read 11
> 1
> pi@raspberrypi:~$
>
> Time to check the other GPIO pins for internal functioning. Looking at
> the result of readall, those would be physical/header pins 7, 13, 15, 29,
> 31, 33, 35, 37, 12, 16, 18, 22, 32, 36, 38, 40. Find out if any GPIO are
> working for output. I don't know the internals of the SoC, but could see a
> case where all GPIOs could be killed by one overload, without killing the
> rest of the SoC.
>
> I don't do BASH shell scripts, or I'd provide one that encapsulates the
> above 5 commands with a parameter for the pin number to speed up the
> testing. In lieu, guess it would be [^] (cursor up) to recall each command
> for editing the pin number (which should be faster than retyping each from
> scratch).
>
Something like
#!/bin/bash
# test Raspberry Pi gpio pins
for pin in 7 13 15 29 31 33 35 37 12 16 18 22 32 36 38 40
do
gpio -1 mode $pin out
gpio -1 read $pin
gpio -1 write $pin 1
gpio -1 read $pin
done
save as testpins.bash and then
chmod +x testpins.bash
./testpins.bash
RobH
Jan 24, 2018, 6:39:37 AM1/24/18
to
On 23/01/18 21:32, Dennis Lee Bieber wrote:
> On Tue, 23 Jan 2018 20:50:46 +0000, RobH <r...@despammer.com> declaimed the
> following:
>
> pi@raspberrypi:~$ gpio -1 read 11
> 0
gpio -1 mode pin no. out
gpio -1 read pin no.
gpio -1 write pin no. 0
gpio -1 read pin no.
gpio -1 write pin no. 1
gpio -1 read pin no.
From the list there are just 6 pins which read 1, and where the
voltages were 3.23 - 3.27 volts
Those pins are
Physical pin no.
13 29 33 37 22 32
Now I am using pin no.32 which gives 3.24V, and the led lights up when
set to (GPIO.HIGH), and goes off when set to (GPIO.LOW).
> On Tue, 23 Jan 2018 20:50:46 +0000, RobH <r...@despammer.com> declaimed the
> following:
>
>> pi@raspberrypi:~ $ gpio -1 write 11 1
>> pi@raspberrypi:~ $ gpio -1 read 11
>> 0
>> pi@raspberrypi:~ $
>
>> pi@raspberrypi:~ $ gpio -1 read 11
>> 0
>> pi@raspberrypi:~ $
>
> At this point I decree that chip GPIO to be totally gone... As a
> working system shows:
>
> pi@raspberrypi:~$ gpio -1 mode 11 out
> working system shows:
>
> pi@raspberrypi:~$ gpio -1 read 11
> 0
> pi@raspberrypi:~$ gpio -1 write 11 1
> pi@raspberrypi:~$ gpio -1 read 11
> 1
> pi@raspberrypi:~$
>
> Time to check the other GPIO pins for internal functioning. Looking at
> the result of readall, those would be physical/header pins 7, 13, 15, 29,
> 31, 33, 35, 37, 12, 16, 18, 22, 32, 36, 38, 40. Find out if any GPIO are
> working for output. I don't know the internals of the SoC, but could see a
> case where all GPIOs could be killed by one overload, without killing the
> rest of the SoC.
>
> I don't do BASH shell scripts, or I'd provide one that encapsulates the
> above 5 commands with a parameter for the pin number to speed up the
> testing. In lieu, guess it would be [^] (cursor up) to recall each command
> for editing the pin number (which should be faster than retyping each from
> scratch).
>
I have checked all the pins which you listed for me with
> pi@raspberrypi:~$ gpio -1 read 11
> 1
> pi@raspberrypi:~$
>
> Time to check the other GPIO pins for internal functioning. Looking at
> the result of readall, those would be physical/header pins 7, 13, 15, 29,
> 31, 33, 35, 37, 12, 16, 18, 22, 32, 36, 38, 40. Find out if any GPIO are
> working for output. I don't know the internals of the SoC, but could see a
> case where all GPIOs could be killed by one overload, without killing the
> rest of the SoC.
>
> I don't do BASH shell scripts, or I'd provide one that encapsulates the
> above 5 commands with a parameter for the pin number to speed up the
> testing. In lieu, guess it would be [^] (cursor up) to recall each command
> for editing the pin number (which should be faster than retyping each from
> scratch).
>
gpio -1 mode pin no. out
gpio -1 read pin no.
gpio -1 write pin no. 0
gpio -1 read pin no.
gpio -1 write pin no. 1
gpio -1 read pin no.
From the list there are just 6 pins which read 1, and where the
voltages were 3.23 - 3.27 volts
Those pins are
Physical pin no.
13 29 33 37 22 32
Now I am using pin no.32 which gives 3.24V, and the led lights up when
set to (GPIO.HIGH), and goes off when set to (GPIO.LOW).
RobH
Jan 24, 2018, 12:55:53 PM1/24/18
to
On 24/01/18 17:04, Dennis Lee Bieber wrote:
> On Wed, 24 Jan 2018 11:39:35 +0000, RobH <r...@despammer.com> declaimed the
> following:
>
>
> header, the corresponding chip GPIO numbers are also scattered about --
> which kills my hypothesis that a "block" of GPIOs might have been damaged
> en-mas. But worse, a read of the BCM2835 Peripherals manual implies all the
> exposed GPIOs are from one chip block, so even a "dead block" concept is
> void.
>
> Figuring out if the "alternate functions" for some of the dead pins are
> usable is beyond discussion... Header pin 11/GPIO17, for example, has
> alternate functions: SD9 (secondary memory data bus), UART0 RTS, SPI1 Chip
> Select 1, and UART1 RTS.
>
> Other than that -- it may be time to consider a second RPi...
> (Something I should do myself -- I have spares for BBB, TIVA C [all three
> models], Arduino, ancient over-priced BASIC Stamps, and even Propeller
> boards).
>
Actually I do have another pi3 but it is being used on another project,
in that it streams music from my PC to a speaker in another part of the
house. I was going to swap the sd cards over on them to use.
> On Wed, 24 Jan 2018 11:39:35 +0000, RobH <r...@despammer.com> declaimed the
> following:
>
>
>> From the list there are just 6 pins which read 1, and where the
>> voltages were 3.23 - 3.27 volts
>>
>> Those pins are
>> Physical pin no.
>> 13 29 33 37 22 32
>>
>> Now I am using pin no.32 which gives 3.24V, and the led lights up when
>> set to (GPIO.HIGH), and goes off when set to (GPIO.LOW).
>
> That is an intriguing set... Besides none of them being adjacent on the
>> voltages were 3.23 - 3.27 volts
>>
>> Those pins are
>> Physical pin no.
>> 13 29 33 37 22 32
>>
>> Now I am using pin no.32 which gives 3.24V, and the led lights up when
>> set to (GPIO.HIGH), and goes off when set to (GPIO.LOW).
>
> header, the corresponding chip GPIO numbers are also scattered about --
> which kills my hypothesis that a "block" of GPIOs might have been damaged
> en-mas. But worse, a read of the BCM2835 Peripherals manual implies all the
> exposed GPIOs are from one chip block, so even a "dead block" concept is
> void.
>
> Figuring out if the "alternate functions" for some of the dead pins are
> usable is beyond discussion... Header pin 11/GPIO17, for example, has
> alternate functions: SD9 (secondary memory data bus), UART0 RTS, SPI1 Chip
> Select 1, and UART1 RTS.
>
> Other than that -- it may be time to consider a second RPi...
> (Something I should do myself -- I have spares for BBB, TIVA C [all three
> models], Arduino, ancient over-priced BASIC Stamps, and even Propeller
> boards).
>
Actually I do have another pi3 but it is being used on another project,
in that it streams music from my PC to a speaker in another part of the
house. I was going to swap the sd cards over on them to use.
0 new messages