-
Notifications
You must be signed in to change notification settings - Fork 31
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
LiFePO4wered Pi+ doesn't power on? #35
Comments
Oops, I had AUTO_BOOT enabled. I thought I disabled. As for powering on, it seems to want to boot at 3.45 volts. |
Running it without the daemon is not supported in any way, shape or form. You're running only half a system. It sounds like you made various register changes, so I have no clue why it might be doing what it does. Are you still having a problem? I can't really tell from your post. |
Oh, I thought it was optional.
I am still having an issue with it not booting sometimes. Here's my
regsiter dump:
```
I2C_REG_VER = 7
I2C_ADDRESS = 67
LED_STATE = 1
TOUCH_STATE = 0
TOUCH_CAP_CYCLES = 0
TOUCH_THRESHOLD = 12
TOUCH_HYSTERESIS = 2
DCO_RSEL = 14
DCO_DCOMOD = 148
VIN = 4889
VBAT = 3358
VOUT = 4986
IOUT = 381
VBAT_MIN = 2850
VBAT_SHDN = 2950
VBAT_BOOT = 3150
VOUT_MAX = 3500
VIN_THRESHOLD = 4498
IOUT_SHDN_THRESHOLD = 0
VBAT_OFFSET = 78
VOUT_OFFSET = 51
VIN_OFFSET = 74
IOUT_OFFSET = 0
AUTO_BOOT = 0
WAKE_TIME = 0
SHDN_DELAY = 40
AUTO_SHDN_TIME = 65535
PI_BOOT_TO = 0
PI_SHDN_TO = 0
RTC_TIME = 1596062923
RTC_WAKE_TIME = 0
WATCHDOG_CFG = 0
WATCHDOG_GRACE = 20
WATCHDOG_TIMER = 20
PI_RUNNING = 1
CFG_WRITE = 0
```
…On Wed, Jul 29, 2020 at 08:36:01AM -0700, Patrick Van Oosterwijck wrote:
Running it without the daemon is not supported in any way, shape or form. You're running only half a system.
It sounds like you made various register changes, so I have no clue why it might be doing what it does. Are you still having a problem? I can't really tell from your post.
If so, can you post the output of `lifepo4wered-cli get`? Alternatively, remove the battery for a minute or so and put it back to reset the registers to their default values (if you didn't write them to flash).
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#35 (comment)
|
[Best to reset PI_BOOT_TO to 300 and PI_SHDN_TO to 120 (their default values) again BTW.] Can you explain "an issue with it not booting sometimes" more? Is it the button not responding? In your previous situation with no daemon running, the button did not respond because according to the system, you were still trying to boot and the deamon wasn't present to trigger a safe shutdown. So the only thing available was the 10-second button push forced-off. I hope you didn't over stress the button trying to push it hard when it wasn't doing what you expected. One thing to try is check whether shorting the BTN pads with a wire does respond like a button press? |
Okay, I've set them to their default values. I see now about the previous situation. No, the button is fine and works, it's working now even. I think there's some code on the MSP deciding not to respond? Is there overvoltage protection that might trigger this state? |
Is there another power source powering the Pi? The LiFePO4wered/Pi+ refuses to turn its power on if there is. I think the only way to move forward is if you sent me a video of the behavior you're seeing because I'm confused about what the problem is. How do you know the button works if the MSP doesn't respond? |
I checked using a multimeter and also shorted the BTN pads.
I'm not using this on a Pi but another SBC with an Pi header. There's no
reverse powering at all (I've removed the abilitity to power it from
anything but the header), and I've had the same behaviour happen when I
disconnected the actualboard and just tried turning it on.
I'll get a video when it happens again.
…On Wed, Jul 29, 2020 at 07:35:36PM -0700, Patrick Van Oosterwijck wrote:
Is there another power source powering the Pi? The LiFePO4wered/Pi+ refuses to turn its power on if there is.
I think the only way to move forward is if you sent me a video of the behavior you're seeing because I'm confused about what the problem is. How do you know the button works if the MSP doesn't respond?
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#35 (comment)
|
I spent way too many hours tonight debugging this happening again and I think I have a working theory of what's happening: First, the MSP430 firmware stops working for one reason or another. Maybe because the battery runs out, maybe because I unplug Shorting the battery pins discharges the caps and powers off the MSP430. Then plugging in the battery or charger has everything again. Does the firmware not have a wathchdog to reset itself if something goes wrong? |
The MPS430 used is a very bare-bones part (MSP430G2332IPW20R). It has a watchdog timer, but you can either use it as a watchdog or a low power timer, and in this design it's used as a low power timer. So, no watchdog unfortunately. I agree the reset behavior isn't great. We test that each unit is responsive when it's shipped and if someone has a need to reset their unit, we recommend leaving the battery out for 10 minutes before putting it back, to ensure all caps are discharged, due to the ultra-low power nature of the design. |
I just wanted to post some of my thoughts on this. I can provide a video of this actually happening if necessary (it's reproducible now) but I'm more worried than anything about how to fix this or work around it since I'll be deploying this to a situation where the user can't unplug or remove the battery. I assume I'm going to have to add a reset button that briefly switches between battery and shorting 3V3 to GND. |
I'm confused, this should not be necessary. The problem only happens when you disconnect/connect the battery, right? Which is not done in normal use. |
Possibly, but I'm not entirely sure. I recall that this would happen when discharging the battery or messing with the configuration a bit. The board would power off then not come back on. I'll try to reproduce this later today. |
How far did you discharge? I mean, did you just run the system until it shut down (2.95V)? Or did you discharge the battery deeper by some other means? The micro is supposed to run down to 1.8V but the battery should never go below 2.0V. |
Just to it turning off, so 2.95V. It happened both times when I was
adjusting settings on it and rebooting, so I was wondering if it was a
bug there. I haven't been able to reproduce it in either case.
…On Fri, Aug 14, 2020 at 06:10:37PM -0700, Patrick Van Oosterwijck wrote:
How far did you discharge? I mean, did you just run the system until it shut down (2.95V)? Or did you discharge the battery deeper by some other means? The micro is supposed to run down to 1.8V but the battery should never go below 2.0V.
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#35 (comment)
|
I've been running the board for a while, and I'm having an extremely difficult time booting and shutting down the board. I've changed PI_SHDN_TO and PI_BOOT_TO to 0 since I'm using a system without the daemon and it was turning off automatically, but now it just doesn't turn on, pressing the button does nothing. When it did previously I couldn't turn it off, the green light just blinked as I held the button.
I spent some time testing voltages and connections. The battery is at 3.46 volts, the charging works, the power button is connected to the MSP430G2, the MSP430 has power and I assume a working clock, but the MSP430 doesn't output the ENABLE or PWR LED signals.
The text was updated successfully, but these errors were encountered: