Pytrack deepsleep wakeup on pin problems
I'm trying to have my GPy on a Pytrack wake up from deepsleep once the onboard button is pushed.
I'm trying to use the pycoproc deepsleep function as this gives me a lower sleep current.
I'm neither able to use the P14 on board button nor the P9 "INT Pin" to wakeup.
What is a known hardware setup to get the Pycom pin wakeup working?
Is there any way to use an existing button (GPy reset or P14) instead of a new one?
Alternatively, how do I disable all Pytrack chips without turning the GPy's power off so I can sleep it separately?
The exact problem apart from no real documentation on how to set the INT pin up is that I have another device on Pin 9 and would like to get around undoing that whole thing.
(I'm using P9, P10, P11, P18, P19, P20 for an e paper display)
With machine.deepsleep() and every radio disabled I get about ~30mA current draw. With the same code on an Expansion board instead of a Pytrack I get ~500uA, With py.go_to_sleep() I get either ~6mA (probably due to a problematic wakeup pin config / setup) or <150uA (which is expected because of my peripherals and OK-ish) with no real pattern.
I am using this to turn off GPS and
self.lte.disconnect() self.lte.detach() self.lte.send_at_cmd('AT!="CBE::powerOff"') self.lte.deinit()
to turn the LTE as off as possible.
my boot.py is
import network import gc import os import pycom pycom.heartbeat(False) bt = network.Bluetooth() bt.deinit() ap = network.WLAN() ap.deinit() server = network.Server() server.deinit() gc.enable()
which should cover all bases.
To try the Pytrack deepsleep with Pin Wakeup I've tried
py.setup_int_wake_up(False, False) py.setup_int_pin_wake_up(False) py.setup_sleep(20) py.go_to_sleep(False)
which does nothing when jumping P#9 to either GND ore 3V3.
The timed restart is also so-so as it sometimes doesn't restart after my 20s but instead after a minute, 5 or never.
@Peter-Ehses The whole Pytrack/Pysense wake-on-pin is a bit of a mess in my experience, but you can make it work.
The trick is to cut (or somehow isolate) P9 on the *Py module. Otherwise you'll get all sorts of weird behaviour because P9 is (indirectly) pulled low during Pytrack/Pysense-controlled deep sleep.
The right order for the calls on a Pysense is (or was, the last time I played with that):
py.setup_sleep(SLEEP) py.setup_int_pin_wake_up(not p) py.go_to_sleep()
pis the current state of the pin, so it dictates whether we want to wake up on falling or rising edge)
Don't quite remember where the
setup_int_wake_upcall fits (didn't use it in my case), but most likely after the
See previous discussions on this topic: