Deep Sleep Not Waking Up

[SmokeySpace]

I'm just getting into Pycom and the Fipy, and I want it to go into deepsleep for 10 minutes, wake up, take a distance reading, and go back into deep sleep again, however when I use "machine.deepsleep(10000)" (just testing with 10 seconds) it doesn't wake up, I'm not sure what the problem is, if it's the board doesn't supply deepsleep, or if I'm missing something in my code, any help would be appreciated!

[Paul Thornton]

Could you post the code your using so we can take a look?

[John Baird]

@smokeyspace And the hardware in use? Taking a distance reading implies listening, or talking, to something else. What is it that measures distance and how is it interfaced?

[SmokeySpace]

@john-baird I am using an ultrasonic range sensor (HC-S0R4) and calculating range from that

[SmokeySpace]

@paul-thornton I’m away from my computer but I believe this is what I had -

import time
from machine import Pin, Timer
import machine

echo = Pin(Pin.exp_board.G7, mode=Pin.IN)
trigger = Pin(Pin.exp_board.G8, mode=Pin.OUT)

trigger(0)

chrono = Timer.Chrono()

def sensor():
    chrono.reset()

    trigger(1)
    time.sleep_us(10)
    trigger(0)

    while echo() == 0:
        pass

    chrono.start()

    while echo() == 1:
        pass

    chrono.stop()

    distance = chrono.read_us() / 58.0

    if distance > 400:
        print("Out of range")
    else:
        print("Distance {:.0f} cm".format(distance))

    print(“test 1”)
    machine.deepsleep(10000)
    print(“test 2”)
 
    sensor()


sensor()

I also had the “def sensor():” function as a “while True:” statement but that did not work either

[jcaron]

@smokeyspace you may want to switch the led on and possibly change its colour at different places in your code to see if anything actually happens.

You may also want to add a short sleep before going to deep sleep. The ESP32 may go to sleep before the UART has had the time to transmit everything (or anything).

Also, remember that machine.deepsleep never returns. Wake up will result in a restart from the beginning of boot.py and main.py, exactly like a first boot or a reset.

[SmokeySpace]

@jcaron well it prints “test 1” but not the test 2, and I knew it restarted, I was just trying to get it to wake back up before I worried about that, it doesn’t run anything at all after it goes to sleep, but I’ll try the short sleep and see if that helps

[crumble]

@jcaron said in Deep Sleep Not Waking Up:

Also, remember that machine.deepsleep never returns.

Depends :)
If it behaves like the pytrack, it may never go to sleep and never increase the program counter. I assume a catched i2c issue in combination with the pytrack. If the OP has a USB volt meter, he can simply verify this. If it still draws a lot of power, it does not sleep and can therefore never wake up. The software watchdog is able to get it out of this state.

On my system it is not easy to reproduce. It may need a few hundred deepsleeps before this error occurs.

[SmokeySpace]

@smokeyspace the short sleep did not seem to work :/ The heartbeat shuts off and never comes back on and no code is run again, do I need a boot.py file and do something with that?

[crumble]

Try to use the FiPy Names for your pin configuration. FiPy pinout

You configured pin G7 as an input pin. But this one is used by the LTE modul as well ( G7 == P20 == LTE_TX ).

Try to use a pin which is neither used by a module of the FiPy nor the expansion board. Or you can try to deinit the LTE modul.

[SmokeySpace]

@crumble That worked! Thank you so much! I just switched G7 to G9 and it worked like a charm!

[SevenW]

@crumble : do you have more information on this failure mode or found a work around? I think I have been bothered by something similar, See this post: Fipy does not always wake from deepsleep:

My Fipy does not wake once in a while, and can only be recovered by pressing the reset button or power cycling the module.

I can always wake it. Either by a reset from deepsleep or by Watchdog timer. It might be that in the case of the watchdog timer wakeup it is not deepsleep, and when it is in deepsleep it does not wake by the WDT. That would explain all the behaviour I observe. Needless to say is that I need it to go to deepsleep always for battery life reasons.