Fipy does not always wake from deepsleep

[SevenW]

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 am using the machine.deepsleep(nnnn) approach. I am aware of the option to use the pytrack.go_to_sleep() but in my future application there might be no pytrack.

The failure occurs somewhere between 50 to 500 deepsleeps. I made the minimal program to test it and the usbserial output alwasy stops after logging "sleep". That is why I assume it does not wake. A leave the program running so it wakes on the timer. But when stuck, it also does not wake on the button on the pytrack board anymore.

What could this be?

test program

import machine
import pycom
print("wake")
print(machine.wake_reason())
machine.pin_sleep_wakeup(pins = ('P14',), mode = machine.WAKEUP_ALL_LOW, enable_pull = True)
sleeps = pycom.nvs_get('sleeps') + 1
pycom.nvs_set('sleeps', sleeps)
print("sleep: %d" % (sleeps))
machine.deepsleep(2000)

typical output when stuck:

ets Jun  8 2016 00:22:57

rst:0x5 (DEEPSLEEP_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff8028,len:8
load:0x3fff8030,len:1984
load:0x4009fa00,len:0
load:0x4009fa00,len:19088
entry 0x400a05e4
Initializing filesystem as FatFS!
wake
(2, None)
sleep: 123

[SevenW]

I actually gave up on the FiPy for not getting this sorted out. The problem is not in the use of a GPIO to wake the board. The problem is in entering or exiting the deepsleep mode. Now reading some more in the forum I found one reference to sometinh that might be related to the issue that I experienced:

@crumble said in Deep Sleep Not Waking Up:

@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.

[rskoniec]

@optimho said in Fipy does not always wake from deepsleep:

(...) The pins which have this capability are: P2, P3, P4, P6, P8 to P10 and P13 to P23 - the pin you are using is not mentioned P14?

But P14 is not in the range of P13 to P23?

[optimho]

Hello, how did you get on with this? I am trying to do the same thing but was not sure of the syntax of pin_deepsleep_wakeup?

I am trying pin_deepsleep_wakeup I see you are using pin_sleep_wakeup?

I did notice that the manual says that the following pins can be used Configure pins to wake up from deep sleep mode when using the machine.pin_sleep_wakeup. (development version documentation)

The pins which have this capability are: P2, P3, P4, P6, P8 to P10 and P13 to P23 - the pin you are using is not mentioned P14?

Regards
Michael

[optimho]

Hello, I am trying to achieve a similar thing. have you tried another pin?

[SevenW]

Experimenting with watchdogtimer (WDT) instead of or next to deepsleep:

Using the WDT with infinite machine.deepsleep() : Get stuck after anumber of cycles just like timed deepsleeps.

Combination of WDT (at boot) and deepsleep: The program seems to run forever. It now made over 14000cycles in 24 hours time. Output:

ets Jun  8 2016 00:22:57

rst:0x7 (TG0WDT_SYS_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff8028,len:8
load:0x3fff8030,len:1984
load:0x4009fa00,len:0
load:0x4009fa00,len:19088
entry 0x400a05e4
Initializing filesystem as FatFS!
wake
0
sleep: 14974, DS: 2805, WD: 12167

Weird observation: In 18.7% it waks from deepsleep(2000). In the majority of cases it wakes form WDT(5000). As the deepsleep is 3 seconds shorter in this test progam than the WDT, it should always wake form depesleep (100%)

I guess there is some race condition in programming the wake timers. Any help is appreciated. Obviously this unpredictible behaviour is not giving sufficient reassurance to build a remote sensor that should be able to perform unattended for years.