Closed cgalpin closed 6 years ago
That looks correct to me and I'm guessing this is the same software setup you used previously which we know worked, so I guess we need to figure out whats going wrong with the hardware.
My guess is the voltage drop across D1 which will make the 3v3 roughly 2v6 is too low for the enable pin.
Can you power up the Pi directly from its own USB leaving the circuit connected and measure the voltage on the enable pin and check there is 2v6 there?
If there is I guess we have two options. Either some sort of transistor arrangement to bring the 2v6 up higher or more simply you could replace D1 with a link which will bring the enable voltage back up again and instead put it inline with D2, that will bring the 5v USB down to roughly 3v6 which when via the 10k resistor shouldn't harm the Pi.
I am measuring 0.193v on EN if I power it via the pi. I only have 4.8v coming out of the 1000c though during this test.
When powered via the usb on the 1000c I measure 5.19v power out to the pi, and 4.25 at EN. That should be high enough right?
Just to make sure I am not doing something stupid, there is no software involved at this point. If it's running and I unplug the usb, it all powers off, whereas my goal was for it keep running until the pis shuts itself down (which I can do by sshing in and doing a shutdown -h).
I am out of time for today but will take photos of the actual wiring and post them tonight in case I am botching that.
thanks.
The 4.25 is high enough, we know that as it stays on :) 0.193v is waaay waay to low. Have you configured the serial port with RaspiConfig?
How embarrassing! It’s been a week since I read the instructions and completely forgot this was required. I’ll try that tonight when I get home.
I am using raspbian stretch and the serial console config has moved to Interfacing options. After disabling the login shell, it then asks
Would you like the serial port hardware to be enabled?
yes results in enable_uart=1 no results in enable_uart=0
I tried both ways and it still dies when I pull the usb power.
Before
$ dmesg | grep tty
[ 0.000000] Kernel command line: 8250.nr_uarts=1 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708_fb.fbswap=1 smsc95xx.macaddr=B8:27:EB:B3:D5:6F vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000 dwc_otg.lpm_enable=0 console=ttyS0,115200 console=tty1 root=PARTUUID=91218375-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait modules-load=dwc2,g_mass_storage
[ 0.001350] console [tty1] enabled
[ 0.470631] 20201000.serial: ttyAMA0 at MMIO 0x20201000 (irq = 81, base_baud = 0) is a PL011 rev2
[ 0.478847] console [ttyS0] disabled
[ 0.481776] 20215040.serial: ttyS0 at MMIO 0x0 (irq = 160, base_baud = 31250000) is a 16550
[ 1.294303] console [ttyS0] enabled
[ 3.956457] systemd[1]: Created slice system-getty.slice.
$ ls -l /dev/serial*
lrwxrwxrwx 1 root root 5 Nov 11 04:08 /dev/serial0 -> ttyS0
lrwxrwxrwx 1 root root 7 Nov 11 04:08 /dev/serial1 -> ttyAMA0
After:
$ dmesg | grep tty
[ 0.000000] Kernel command line: 8250.nr_uarts=0 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708_fb.fbswap=1 smsc95xx.macaddr=B8:27:EB:B3:D5:6F vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000 dwc_otg.lpm_enable=0 console=tty1 root=PARTUUID=91218375-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait modules-load=dwc2,g_mass_storage
[ 0.001348] console [tty1] enabled
[ 0.465973] 20201000.serial: ttyAMA0 at MMIO 0x20201000 (irq = 81, base_baud = 0) is a PL011 rev2
Does this look like it's disabled properly? The pi zero w has bluetooth, so I believe it needs to be treated like a pi 3, but I'm not sure I fully understand what's needed here, even after reading
https://www.raspberrypi.org/documentation/configuration/uart.md
I was hoping to be able to use bluetooth on this as well.
What I would say you need to do is get it working with the original LiPoPi circuit which we know works then we can move onto this new circuit.
Yes, sound advice. I'll see if I can find some time today, otherwise it will be in about 2 weeks when I'll be able to try it again. Thanks a lot for all the help.
Oh here are pictures of the physical circuit I made.
Reverting to your original circuit revealed I had the resistors switched. Once I swapped those, I could get the pi to power up by pressing the button (in my case touching wires) for a few seconds and it would remain running after I let go. When I shutdown the pi, the charger shutdown (blue led off) with only the green battery led on until removed power from the usb.
I think this validates the serial port settings too right?
Once I reverted to my circuit (with resistors in proper locations), the pi still loses power when I remove power from the USB. So not sure what's wrong at this point, but I'll revisit this with fresh eyes in about 2 weeks.
Thanks again for the help.
Now you have it all set up let me know that voltage on EN again.
Ok, I have 1.36v at EN now.
Do I understand you correctly that you suggest going to a single diode at EN with both lines with the resistors feeding into it?
No, remove D1 so R1 goes straight to EN and instead put it in series with D1 so theres two diodes between USB and EN to drop the USB voltage down.
Ok, still not working.
With that configuration I still only get 1.374v at EN with powering the PI directly (4.18 when powered by USB).
I read 4.6v after the first diode when powered by usb. I read 4.16v at GPIO14 when powered by usb, 1.38 when powered by the pi.
What are you getting directly on GPIO14?
4.16v at GPIO14 when powered by usb, 1.38 when powered by the pi.
Using GND on the 1000c
Hmmm, something is definitely not right. If you disconnect your circuit from GPIO14 what does GPIO14 measure?
I disconnected GPIO14 and referenced to ground on the pi, 0.41v when powered by the pi directly, 1.17 on usb.
I checked an unmodified pi zero w, and get 1.2 powered with an usb add on board too, just to make sure I didn't break something,
I also tested a simple script taking GPIO21 high and it goes to 3.3v
Does this mean my serial port is not configured properly? What's special about GPIO14? Can't I just use software to bring any GPIO pin high when the pi is running and wire that to EN?
Here is what dmesg shows for ttys. I'm not sure if this is correct, but it's the same setup I had when I tested with your circuit before.
pi@teslaCamBuddy:~ $ dmesg|grep tty
[ 0.000000] Kernel command line: 8250.nr_uarts=0 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708_fb.fbswap=1 smsc95xx.macaddr=B8:27:EB:B3:D5:6F vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000 dwc_otg.lpm_enable=0 console=tty1 root=PARTUUID=91218375-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait modules-load=dwc2,g_mass_storage
[ 0.001348] console [tty1] enabled
[ 0.466135] 20201000.serial: ttyAMA0 at MMIO 0x20201000 (irq = 81, base_baud = 0) is a PL011 rev2
pi@teslaCamBuddy:~ $ ls -l /dev/serial*
lrwxrwxrwx 1 root root 7 Nov 25 18:38 /dev/serial1 -> ttyAMA0
Ok, I configured a pin in /boot/config.txt to be high on boot, and this works when I wire that pin to EN instead of GPIO14 (in my case GPIO21). The pi keeps running until I shut it down.
I added this to /boot/config.txt:
# set GPIO21 pin high to signal the 1000c we want to keep running when usb power goes
gpio=21=op,dh
I guess I'll try put the diodes back the way they were before, unless you think this is a bad idea?
Whoohoo, works great with the original circuit you recommended (linked to in my first post)!
I am happy with this. One line of config in /boot/config.txt seems to be a perfectly good solution and allows me to do whatever I want with GPIO14 in terms of TTY or bluetooth.
I guess I now just need to figure out a clean/compact way to wire this up for real.
Thanks so much for the help, I really appreciate it.
Awesome!
I have a similar problem to #39 in that right now of the low battery light next to the battery connector always staying on, even without the battery connected, and I'm pretty sure it wasn't this way when I initially created the circuit, so maybe I have damaged a GPIO or my 1000c as well. My circuit is modified but this portion is no different than the basic lipopi one. But in my case I am using GPIO port 23 connected to the low battery pin and everything else is working as expected. It's configured as an input, active high on the pi and reads 1 when the battery is not low (although admittedly I haven't done a low battery test in a while to see if it goes to 0 - it usually shuts itself down before the battery runs low). Given this, and the fact that it happens with and without a battery connected I am not sure I have the same problem.
If I disconnect the low battery pin on the 1000c the light goes out. If I try another pin on the pi, or ground it, the light comes one. So this would lead me to think it's a problem on the 1000c side not the pi side. Do you have any thoughts on this?
Let's say I leave it like this since everything else is working, with a 350mAh battery, a single red LED will drain the battery in about 17.5 hours correct? I'm assuming the battery won't last long if I keep draining it like that though. Just trying to weight my options. I have a second 1000c, but don't want to use it without understanding what I did wrong so I don't destroy another one :)
tia, charles
If the low battery light comes on when you connect up the low battery wire to the Pi it sounds like the Pi GPIO is not configured as an input? If it is configured as an input it shouldn't make a difference?
With reference to not having a battery connected at all the documentation for the 1000c says you should not do this, but yes it would make sense that the low battery light comes on if you disconnect the battery as the battery voltage is low (non existent).
I was just trying with no battery as a test for this problem, but I guess a non existent battery treated as low battery makes sense.
I am using the same low_bat_shutdown script from lipopi, so I believe it's configured as an input. I switched to port 25 as a test but get the exact same behavior so don't think its an issue on the pi side. As soon as I connect that pin, the light comes on.
If you connect something to that pin and the light comes on I would think something is pulling the pin low.
Yes but what!
I have tried several different pins, using both low_bat_shutdown and python equivalents reading from the pin, and the light comes on as soon as I connect the pin and doesn't change when the script initializes the GPIO and reads. The pin reads correctly too (gets a 1). So i'm totally stumped.
I guess I'll solder in my second 1000c and hope for the best :)
You definitely have nothing else connected to the pin except the Pi's GPIO and the Pi is definitely set as an input in the boot file?
Starting a new issue if you don't mind. I attempted to take your advise on how to wire up a PowerBoost 1000c charger with a Rasperry Pi Zero W so that it will power up when the 1000c gets power, and power off once the pi shuts down from #20 .
As-is, if I wire this up with a battery it stays power off. When I apply power to the 1000c via a usb connector, the 1000c and pi power up. But when I remove power from the usb connector, everything shuts off, instead of running on the battery until the pi shuts down.
Can you take a look at my circuit and see if I wired it up as you suggested, or made a mistake? teslaCamBuddy.pdf