New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

not enough voltage on GPIO14 on pi3 #9

Closed
macsimski opened this Issue Jun 13, 2016 · 20 comments

Comments

Projects
None yet
5 participants
@macsimski

macsimski commented Jun 13, 2016

It seems the raspberry Pi model 3B has a changed internal circuit for the GPIO pin. when console is disabled on the pi, the voltage of the pin drops to around 1.4 volt. with console enabled, this is the correct 3.3 volt.
what to do?

I build this on my model B+ (thanks rpi for the brilliant naming scheme) and this is working fine. But now in "production" on a model 3, this fails.

@NeonHorizon

This comment has been minimized.

Show comment
Hide comment
@NeonHorizon

NeonHorizon Jun 13, 2016

Owner

Ahh I think this is because the Pi3 doesn't have a real UART on the GPIO. The UART on GPIO14 on the Pi3 is emulated in software because the actual UART is now used for the Bluetooth.

Try the following in the boot config file:
enable_uart=1

If that doesn't work try disabling the bluetooth and see if it makes a difference:
dtoverlay=pi3-disable-bt

If that still doesn't work try both at once :)

Let us know how you get on....

Owner

NeonHorizon commented Jun 13, 2016

Ahh I think this is because the Pi3 doesn't have a real UART on the GPIO. The UART on GPIO14 on the Pi3 is emulated in software because the actual UART is now used for the Bluetooth.

Try the following in the boot config file:
enable_uart=1

If that doesn't work try disabling the bluetooth and see if it makes a difference:
dtoverlay=pi3-disable-bt

If that still doesn't work try both at once :)

Let us know how you get on....

@macsimski

This comment has been minimized.

Show comment
Hide comment
@macsimski

macsimski Jun 13, 2016

Hmm. does work partially. when enabling console, it works, but because of al the messages there is enough 0 volt to trigger a power down without a proper shutdown command. Disabling BT does not change something

macsimski commented Jun 13, 2016

Hmm. does work partially. when enabling console, it works, but because of al the messages there is enough 0 volt to trigger a power down without a proper shutdown command. Disabling BT does not change something

@macsimski

This comment has been minimized.

Show comment
Hide comment
@macsimski

macsimski Jun 13, 2016

could i swap tx and rx? it seems the GPIO15 does carry 3.3v. we can live with a minute without power warning i think

macsimski commented Jun 13, 2016

could i swap tx and rx? it seems the GPIO15 does carry 3.3v. we can live with a minute without power warning i think

@NeonHorizon

This comment has been minimized.

Show comment
Hide comment
@NeonHorizon

NeonHorizon Jun 13, 2016

Owner

GPIO15 has 3v3 straight from power up?
Or after a minute after start up?

Owner

NeonHorizon commented Jun 13, 2016

GPIO15 has 3v3 straight from power up?
Or after a minute after start up?

@macsimski

This comment has been minimized.

Show comment
Hide comment
@macsimski

macsimski Jun 13, 2016

straight up, but with a very weak pullup. and. its not pulled low at shutdown. so a dead end. :-(

macsimski commented Jun 13, 2016

straight up, but with a very weak pullup. and. its not pulled low at shutdown. so a dead end. :-(

@NeonHorizon

This comment has been minimized.

Show comment
Hide comment
@NeonHorizon

NeonHorizon Jun 13, 2016

Owner

I thought so. Unfortunately as far as I know GPIO14 was the only way to do it :(
I don't have a Pi3 so I can't test but it may be the case that you literally can't use a Pi3 :(
If that is true I will update the instructions...

The only other thing you could do would be to monitor the output from the power LED on the board or something like that. It would be tricky though and involve working out a circuit and surface mount soldering.

Owner

NeonHorizon commented Jun 13, 2016

I thought so. Unfortunately as far as I know GPIO14 was the only way to do it :(
I don't have a Pi3 so I can't test but it may be the case that you literally can't use a Pi3 :(
If that is true I will update the instructions...

The only other thing you could do would be to monitor the output from the power LED on the board or something like that. It would be tricky though and involve working out a circuit and surface mount soldering.

@macsimski

This comment has been minimized.

Show comment
Hide comment
@macsimski

macsimski Jun 13, 2016

I've attached a DSlogic to all the pins and 14 is the only one with the behaviour we need. bu i was thinking in another direction: as serial console is enabled, maybe we could bridge the zero volt pulses with a big capacitor and a slightly larger resistor going to pin14. but i have not tested the setup yet as i am not in my lab and took only some resistors with me. it seems that enabeling the console does not influence the battery sensing ability

macsimski commented Jun 13, 2016

I've attached a DSlogic to all the pins and 14 is the only one with the behaviour we need. bu i was thinking in another direction: as serial console is enabled, maybe we could bridge the zero volt pulses with a big capacitor and a slightly larger resistor going to pin14. but i have not tested the setup yet as i am not in my lab and took only some resistors with me. it seems that enabeling the console does not influence the battery sensing ability

@NeonHorizon

This comment has been minimized.

Show comment
Hide comment
@NeonHorizon

NeonHorizon Jun 13, 2016

Owner

I think you might need diodes because 1 is a source but 0 is a sync so it would actually drain the cap?

Owner

NeonHorizon commented Jun 13, 2016

I think you might need diodes because 1 is a source but 0 is a sync so it would actually drain the cap?

@macsimski

This comment has been minimized.

Show comment
Hide comment
@macsimski

macsimski Jun 13, 2016

if the pulses are small enough (115200) and using a sufficient high resistor like 60k could do the trick. i will test tomorrow as I am heading home right now. a diode is just the opposite of what you want: the signal should go low to shut down the machine. the databurst is short enough for the capacitor to revive. Hmm maybe a forward diode paralel to the resistor can help in recharing the capacitor...

macsimski commented Jun 13, 2016

if the pulses are small enough (115200) and using a sufficient high resistor like 60k could do the trick. i will test tomorrow as I am heading home right now. a diode is just the opposite of what you want: the signal should go low to shut down the machine. the databurst is short enough for the capacitor to revive. Hmm maybe a forward diode paralel to the resistor can help in recharing the capacitor...

@NeonHorizon

This comment has been minimized.

Show comment
Hide comment
@NeonHorizon

NeonHorizon Jun 13, 2016

Owner

Yeah I'm guessing voltage drop on diodes would be the issue.

Owner

NeonHorizon commented Jun 13, 2016

Yeah I'm guessing voltage drop on diodes would be the issue.

@macsimski

This comment has been minimized.

Show comment
Hide comment
@macsimski

macsimski Jun 13, 2016

well, simulations in LTSpice show that using a 1uf capacitor over the 100K resistor should work, taking in account that in the character A there are five successive zeroes in a byte, resulting in a dip of 52us. as it is 23:24 here, i will try that tomorrow and get back to you

macsimski commented Jun 13, 2016

well, simulations in LTSpice show that using a 1uf capacitor over the 100K resistor should work, taking in account that in the character A there are five successive zeroes in a byte, resulting in a dip of 52us. as it is 23:24 here, i will try that tomorrow and get back to you

@macsimski

This comment has been minimized.

Show comment
Hide comment
@macsimski

macsimski Jun 14, 2016

It works now. You don't even have to press the button for more than a instant to boot the pi. I only put an 100uf 10v capacitor parallel to the 100k resistor. This is just enough to bridge the short period during booting that the serial port is not yet up.
So to recap: keep the serial console running on the pi and place a 100uf 10v capacitor parallel to the 100k resistor.
As I am using this setup to monitor power loss, I changed the script somewhat because I sense another pin on the chip: !PG. this signal goes high when power is lost, so i had to change "!=" to only "=" in line 20 of the low_bat_shutdown script. I also followed that condition on line 20 with a sleep 25 and another copy of line 20 inserted on line 22 so if the power is interrupted briefly by a loose powercord or a change of power socket in your room, the pi stays on for at least another 15 seconds before issuing the shutdown command.

macsimski commented Jun 14, 2016

It works now. You don't even have to press the button for more than a instant to boot the pi. I only put an 100uf 10v capacitor parallel to the 100k resistor. This is just enough to bridge the short period during booting that the serial port is not yet up.
So to recap: keep the serial console running on the pi and place a 100uf 10v capacitor parallel to the 100k resistor.
As I am using this setup to monitor power loss, I changed the script somewhat because I sense another pin on the chip: !PG. this signal goes high when power is lost, so i had to change "!=" to only "=" in line 20 of the low_bat_shutdown script. I also followed that condition on line 20 with a sleep 25 and another copy of line 20 inserted on line 22 so if the power is interrupted briefly by a loose powercord or a change of power socket in your room, the pi stays on for at least another 15 seconds before issuing the shutdown command.

@macsimski macsimski closed this Jun 14, 2016

@NeonHorizon

This comment has been minimized.

Show comment
Hide comment
@NeonHorizon

NeonHorizon Jun 14, 2016

Owner

Thanks for your help with this Simon.
I've updated the readme in a number of places (search for Pi 3) and added you as a contributor. Let me know if what I've added is wrong (or do a pull request) or if you would like to change/remove your contributor entry.

Owner

NeonHorizon commented Jun 14, 2016

Thanks for your help with this Simon.
I've updated the readme in a number of places (search for Pi 3) and added you as a contributor. Let me know if what I've added is wrong (or do a pull request) or if you would like to change/remove your contributor entry.

@craic

This comment has been minimized.

Show comment
Hide comment
@craic

craic Oct 5, 2016

Contributor

Sorry to reopen this... but I'm testing my pi_power set up on a Pi 3 (which uses the same power up/power downcircuit) and it works fine with the 'regular' set up - i.e. no capacitor and the serial interface disables in raspi-config...

My setup is a Raspberry Pi 3 Model B v1.2 (2015) running Raspbian Jessie (I believe - the login says Linux raspberrypi 4.1.19-v7+ and /etc/debian_version says 8.0

Simon, what was your board ? I'll try and reproduce it

thanks

Contributor

craic commented Oct 5, 2016

Sorry to reopen this... but I'm testing my pi_power set up on a Pi 3 (which uses the same power up/power downcircuit) and it works fine with the 'regular' set up - i.e. no capacitor and the serial interface disables in raspi-config...

My setup is a Raspberry Pi 3 Model B v1.2 (2015) running Raspbian Jessie (I believe - the login says Linux raspberrypi 4.1.19-v7+ and /etc/debian_version says 8.0

Simon, what was your board ? I'll try and reproduce it

thanks

@macsimski

This comment has been minimized.

Show comment
Hide comment
@macsimski

macsimski Oct 6, 2016

I don't have it here at the moment as the installation is at someone elses place. next week I will be there and get back to you.

macsimski commented Oct 6, 2016

I don't have it here at the moment as the installation is at someone elses place. next week I will be there and get back to you.

@craic

This comment has been minimized.

Show comment
Hide comment
@craic

craic Oct 6, 2016

Contributor

Hmm... in my Pi3 / PowerBoost 1000C setup I had connected the PowerBoost output USB +/- pads directly to the Pi 5V and Ground pins on the GPIO connector, which is supposed to work (and does) but I was seeing some weirdness - when powered down the blue LED on the Powerboost would flicker dimly - unplugging the HDMI cable to my monitor fixed this... so there was some current passing back from the HDMI ?

So I wired up the PowerBoost USB output through a regular cable to the Pi USB power input - and in this configuration I needed to use your solution for the Pi 3...

Never change more than one thing at a time... I should know that by now

I'm doing some more testing right now

Contributor

craic commented Oct 6, 2016

Hmm... in my Pi3 / PowerBoost 1000C setup I had connected the PowerBoost output USB +/- pads directly to the Pi 5V and Ground pins on the GPIO connector, which is supposed to work (and does) but I was seeing some weirdness - when powered down the blue LED on the Powerboost would flicker dimly - unplugging the HDMI cable to my monitor fixed this... so there was some current passing back from the HDMI ?

So I wired up the PowerBoost USB output through a regular cable to the Pi USB power input - and in this configuration I needed to use your solution for the Pi 3...

Never change more than one thing at a time... I should know that by now

I'm doing some more testing right now

@tverona1

This comment has been minimized.

Show comment
Hide comment
@tverona1

tverona1 Feb 27, 2017

Hey guys, commenting here to ask a related question: With the same circuitry, on my pi 3 I need to hold the power button for around 20 sec for it to stay on. If I hold it for only a couple of secs, it starts to boot but at some point it looks like the tx pin goes low, so I need to hold it for around 20 secs or so, til it finishes booting. Have you see this?

tverona1 commented Feb 27, 2017

Hey guys, commenting here to ask a related question: With the same circuitry, on my pi 3 I need to hold the power button for around 20 sec for it to stay on. If I hold it for only a couple of secs, it starts to boot but at some point it looks like the tx pin goes low, so I need to hold it for around 20 secs or so, til it finishes booting. Have you see this?

@NeonHorizon

This comment has been minimized.

Show comment
Hide comment
@NeonHorizon

NeonHorizon Feb 27, 2017

Owner

The Pi3 is messed up due to the fake UART. Did you follow the Pi3 specific instructions?

Owner

NeonHorizon commented Feb 27, 2017

The Pi3 is messed up due to the fake UART. Did you follow the Pi3 specific instructions?

@burksfamly

This comment has been minimized.

Show comment
Hide comment
@burksfamly

burksfamly Mar 4, 2017

After getting clarification from Rob and Daniel on the pi_power project (thank you), I have been working on a project in which I have implemented pi_power with some modifications. In short, the schematic was followed as prescribed, except I grounded the 1000C. With respect to software control, I remapped all original GPIO usage to avoid conflicts with the comm (UART, I2C, SPI) and EEPROM GPIO functions I needed for the project, and to use physical GPIO pins on the header more suitable to my IC and component placement on the stackable Pi HAT I built from a PCB blank (soldered and wire-wrapped). I ended up remapping GPIO BCM pins as follows:

pi_power (Modified pi_power)
26 (27)
20 (18)
21 (16)
25 (13)
24 (06)
23 (05)
18 (12)
14 (26*)

*I use GPIO BCM 26 to simulate the action of the GPIO 14 (UART-TXD) during the boot process by first setting GPIO BCM 26 mode to output and then writing a 1 to GPIO BCM 26 (setting it high) immediately afterward. I currently do this via rc.local (soon to be deprecated), so I'll move it to systemd later on. In addition, in the user_shutdown_setup() function of pi_power.py, I had to insert a time.sleep(2) function call between the GPIO.setup() and the GPIO.add_event_detect() functions for the "shutdown_pin"; otherwise, the Pi will shut down as soon as the GPIO.setup() function is called to setup the "shutdown_pin". I also had to measure actual resistance of the resistors in the voltage dividers to calculate Vout, and run stress tests to determine actual high and low limits of my 6600 mAh LiPo battery...it mattered...especially with the resistors I used (+-5% my bum :) ).

So...for those with similar GPIO conflict problems, this is very doable as it has been stable for several weeks during further development of the project. I suggest, however, that if you try to do this using the original pi_power design, you first develop a GPIO conflict matrix for your design and a board layout and soldering map for your stackable Pi HAT to ensure that you minimize wire run lengths and optimize placement of your components. I even found room to include access headers on the HAT for both used and unused GPIO pins, which makes for easy troubleshooting and expansion.

ADDITIONAL QUESTION: Will an increase in capacitance (e.g., say doubling by placing an additional 100uF capacitor in parallel with the 100uF capacitor that is already in parallel with the 100k resister to ground in the Pi 3 power circuit) allow a consistent reboot of the Pi via the Pixel GUI or "sudo shutdown -r now"? The reason I ask is that more than 50% of the time with the current design I can perform such a reboot, but other times it fails. I haven't tested additional capacitance yet, because my new stackable Pi HAT is buried in its enclosure, I am in too many development rabbit holes at the time to step back to this part of the project, and I thought someone out there more knowledgeable that I am regarding circuit design may know off the top of their head. If someone out there is remotely sure that the concept would at least work in theory with the Pi 3 and this type of pi_power design, I will try to increase capacitance until it works consistently and let you know.

UPDATE: (03-08-17) - I doubled capacitance by placing an additional 100uF capacitor in parallel with the 100uF capacitor in the original circuit (i.e., the one that is in parallel with the 100k resister to ground for the RPi 3 circuit). Since my original post, I have been cutting code daily in my application's kernel, which has required many system reboot events during development and testing. I have had no instances where the reboot process has failed...it has consistently rolled over, latched and powered up. Given the number of times I have had to reboot, I call this doubling a success. As a caveat, if a Pi 3 system is configured differently, requiring a longer reboot, the 200uF solution may fail...but the concept of increasing capacitance appears to work.

Here are a couple pics of the stackable Pi HAT:

stackable pi hat 1

stackable pi hat 2

burksfamly commented Mar 4, 2017

After getting clarification from Rob and Daniel on the pi_power project (thank you), I have been working on a project in which I have implemented pi_power with some modifications. In short, the schematic was followed as prescribed, except I grounded the 1000C. With respect to software control, I remapped all original GPIO usage to avoid conflicts with the comm (UART, I2C, SPI) and EEPROM GPIO functions I needed for the project, and to use physical GPIO pins on the header more suitable to my IC and component placement on the stackable Pi HAT I built from a PCB blank (soldered and wire-wrapped). I ended up remapping GPIO BCM pins as follows:

pi_power (Modified pi_power)
26 (27)
20 (18)
21 (16)
25 (13)
24 (06)
23 (05)
18 (12)
14 (26*)

*I use GPIO BCM 26 to simulate the action of the GPIO 14 (UART-TXD) during the boot process by first setting GPIO BCM 26 mode to output and then writing a 1 to GPIO BCM 26 (setting it high) immediately afterward. I currently do this via rc.local (soon to be deprecated), so I'll move it to systemd later on. In addition, in the user_shutdown_setup() function of pi_power.py, I had to insert a time.sleep(2) function call between the GPIO.setup() and the GPIO.add_event_detect() functions for the "shutdown_pin"; otherwise, the Pi will shut down as soon as the GPIO.setup() function is called to setup the "shutdown_pin". I also had to measure actual resistance of the resistors in the voltage dividers to calculate Vout, and run stress tests to determine actual high and low limits of my 6600 mAh LiPo battery...it mattered...especially with the resistors I used (+-5% my bum :) ).

So...for those with similar GPIO conflict problems, this is very doable as it has been stable for several weeks during further development of the project. I suggest, however, that if you try to do this using the original pi_power design, you first develop a GPIO conflict matrix for your design and a board layout and soldering map for your stackable Pi HAT to ensure that you minimize wire run lengths and optimize placement of your components. I even found room to include access headers on the HAT for both used and unused GPIO pins, which makes for easy troubleshooting and expansion.

ADDITIONAL QUESTION: Will an increase in capacitance (e.g., say doubling by placing an additional 100uF capacitor in parallel with the 100uF capacitor that is already in parallel with the 100k resister to ground in the Pi 3 power circuit) allow a consistent reboot of the Pi via the Pixel GUI or "sudo shutdown -r now"? The reason I ask is that more than 50% of the time with the current design I can perform such a reboot, but other times it fails. I haven't tested additional capacitance yet, because my new stackable Pi HAT is buried in its enclosure, I am in too many development rabbit holes at the time to step back to this part of the project, and I thought someone out there more knowledgeable that I am regarding circuit design may know off the top of their head. If someone out there is remotely sure that the concept would at least work in theory with the Pi 3 and this type of pi_power design, I will try to increase capacitance until it works consistently and let you know.

UPDATE: (03-08-17) - I doubled capacitance by placing an additional 100uF capacitor in parallel with the 100uF capacitor in the original circuit (i.e., the one that is in parallel with the 100k resister to ground for the RPi 3 circuit). Since my original post, I have been cutting code daily in my application's kernel, which has required many system reboot events during development and testing. I have had no instances where the reboot process has failed...it has consistently rolled over, latched and powered up. Given the number of times I have had to reboot, I call this doubling a success. As a caveat, if a Pi 3 system is configured differently, requiring a longer reboot, the 200uF solution may fail...but the concept of increasing capacitance appears to work.

Here are a couple pics of the stackable Pi HAT:

stackable pi hat 1

stackable pi hat 2

@NeonHorizon

This comment has been minimized.

Show comment
Hide comment
@NeonHorizon

NeonHorizon Mar 4, 2017

Owner

I think you meant to thank Rob rather than me :)
With reference to the capacitor I think I would find a value by trial and error, it would be hard to guess what would work.

Owner

NeonHorizon commented Mar 4, 2017

I think you meant to thank Rob rather than me :)
With reference to the capacitor I think I would find a value by trial and error, it would be hard to guess what would work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment