pimoroni / badger2040

Examples and firmware for Badger 2040 and Badger 2040 W
MIT License
150 stars 50 forks source link

Badger 2040 W does not run on battery until a button is pushed #14

Open cpottle9 opened 1 year ago

cpottle9 commented 1 year ago

When I run the new micropython 0.0.2 from pimoroni/badger2040 on battery after power up the LED does not light and main.py does not run. If I push any of the front buttons it does run.

Running 1.19.16 from pimoroni/pimoroni-pico the LED lights and main.py runs when I power on the battery (with no button push).

I think the 1.19.16 behavior is correct. A fix for the newer version is needed.

Update: I just tried these tests on inky frame 4.0 running 1.19.16 and 1.19.18. Behavior is the same for both. The LED does not light or main.py run until a button is pushed.

I noted a second issue. Related but different.

For both versions, on battery, once main.py is running if I push the reset button the LED turns off and main.py does not run. Looking at the Badger 2040 W schematic this makes sense, but is not obvious. The issue is the reset button does nothing to the PCF85063A. I think it should pull the VDD for the RTC chip low putting it in a reset state too. In my opinion, this is a defect in the board design. I know you are not going to fix it. But it should be documented.

cpottle9 commented 1 year ago

Hel, I am reporting two problems in this issue.

The first is the change in behavior from 1.19.16 to 0.0.2. The second is the fact that the reset button does nothing when on battery and the pico W is powered down.

You added the documentation tag. Does that apply for both problems?

helgibbons commented 1 year ago

Hey there - with the caveat that I'm neither a software developer or an engineer, it sounds to me like things are working here as intended? It is a deliberate hardware design decision that a battery powered Badger (or Inky Frame) will only wake up and run main.py with a front button press (or a nudge from the RTC) - the intention being that the power is 'off by default' to help with power saving. I added the documentation tag as a reminder that we could probably stand to explain this behaviour a bit better.

Have I misunderstood your issue?

cpottle9 commented 1 year ago

Hel, general comment, I had another issue and posted on Pimoroni Buccaneers. In that case I was directed to open an issue on github to get the attention of developers.

The developers need to comment on this issue. Is the behaviour in 1.19.16 correct or 0.0.2.

One can argue either way. Arguing for the 0.0.2 behaviour, I would say main.py should run when the batteries are replaced with no button input.

I've been making changes(minor) to the micropython source code. So, I am able to read the source code and understand it (mostly).

When I look at 1.19.16 source I see a patch is applied to crt0.S (part of pico-sdk) so very early in startup the wakeup pin is set. Writing that patch seems like a lot of work. Someone had a good reason for this code to run early in startup.

Looking at the source for 0.0.2 in the badger2040 repo I see commit 480e13d Experimental: Patch-free wakeup latching. This startup behavior was moved from crt0.S to a module. While I don't fully understand how micropython startup works, it is clear that wakeup pin is set much later.

Again, the second issue that I identified is in my opinion definitely a hardware bug. Pushing the reset button should reset all the hardware on the 2040 W. Only the PICO W is reset, not the PCF85063A rtc chip. I agree this is not going to get fixed and needs to be documented. Let me know if I should open a new issue for this hardware bug.

rgsteele commented 1 year ago

@cpottle9 I disagree that the reset button ought to reset the RTC chip. If it did, you would need to reprogram it with the current time every time the reset button was pressed. This has never been the behaviour of any other RTC-equipped device I have ever encountered.

As for the difference in behaviour between versions 1.19.16 and 0.0.2: it is interesting, but I'm not sure I understand the need for it to be clearly defined. For the device's intended use case of a simple, general-purpose computing device with very low power consumption, connecting and disconnecting power will be a relatively rare occurrence and having to press a button to initiate function is not an impediment.

cpottle9 commented 1 year ago

@rgsteele I agree with your point that the reset button should not reset the RTC chip. Loosing the date/time is a valid issue.

I still think it needs to be documented that the reset button, in almost all cases, does nothing when running on battery. Typically the PICO W is already powered down waiting for a button push or a wakeup from the RTC chip.

On the other hand, when running from USB the Pico W always has power so the reset button always works.

My two use cases with badger2040w and inkyframe 4.0 I do not use the buttons at all. My code runs periodically when the RTC chip wakes up the Pico W. Requiring the user to push a button just to get code to run after a battery change is not intuitive.

rgsteele commented 1 year ago

Thanks for the clarification. I agree that it is not intuitive that the reset button has no effect when the device is in sleep mode, and that should be documented. I can also see your point about code not running at power-on being problematic when the device is being used as a passive display.

joemarshall commented 9 months ago

I just came across this too - I'm running a badger 2040w as a control panel for something. I really just needed an rpi2040 with any screen that is easy to read and doesn't emit light, power isn't really an issue for me, so I'm slightly off topic for the badger really. I assumed my battery connector circuitry was broken and soldered a wire from my 5v supply direct to the rpi board and it is working fine.

Is there any reason that the sleep until buttons pressed behaviour is implemented outside micropython? Would it use way too much extra power if it was just that by default boot.py or main.py included code to go direct to deep sleep mode if not on USB? That way one could just connect via USB, comment that code out and have the old behaviour.