Deepsleep issue on FiPy

  • Is anyone else experiencing issues using DeepSleep?
    I have a problem that I do not seem to be able to solve.

    I am using the machine.deepsleep(sleeptime) function to force my device to sleep for roughly 2 minutes.

    Most of the time everything works correctly, but every few hours my system hangs.
    I have tracked the issue down to it actually hanging at the call to deepsleep.

    No errors are generated and the code does not fall back to the repl (this happens with other errors that I have had). The system just remains locked up and requires a hard reset to get things moving again.

    During normal operation, the device spends most of its time asleep and the Pycom module is cool to touch (confirming it is definitely sleeping most of the time). When the lockup occurs, the Pycom module appears to be doing something (not sleeping) as it is warm to touch. However it is not doing what it is supposed to. It appears that the reset is not generated as normal after the unit wakes up. So I believe it is locked in the deepsleep call somehow and never actually goes to sleep

    The deepsleep call is within a While True loop. So if the call failed and fell through my code should continue on and actually do things (flash leads, print messages, etc) but none of this happens.

    My application has lost total control.

    I suspect a bug or hardware issue.

    Any help would be greatly appreciated.



  • @tuftec
    Have you enabled the internal watchdog?

  • @Martinnn While I appreciate your comment, this is not what I expected to hear. I would not expect that some devices work and others just don't. I only have the one upgraded Fipy at this point. I expect it to work as specified.

  • @tuftec Maybe try a different device. Out of my 15 wipy/pysense, some run fine for weeks, some consistently lock up after a few hours. Identical hard/software.

  • Ok.
    So a quick update on my lock up issues.

    I have now spent time looking carefully at the hardward surrounding my FiPy module, but I am still getting lock ups every few hours.
    Here is what I have done so far to alleviate the problem:

    1. upgraded power source. 5V power now comes directly from a UUC252-5 regulator (5V, 3A, LDO) mounted right next to the module. I have monitored the supply pins at the module with my DSO and the supply rails look clean
    2. Disconnected other external monitoring equipment (TTL serial port monitoring) as I suspected this was a source of potential pin input noise.

    These changes have not solved the problem.

    While observing the system behaviour with my terminal cable connected (so I can see console output), I have noticed that some times the FiPy takes many seconds before it appears to go to sleep after being issued the machine.deepsleep command. On other occasions, the module goes to sleep quite quickly. So I am guessing that the module fails to actually go to sleep soetimes and gets locked up in the deepsleep function call.

    Does anyone have any experience with this issue?
    Could this be a firmware bug (running the latest development release)?
    Are there any ideas on how I could track this down a bit further.
    Can I get some input from Pycom support on this.


  • A quick update.
    I have tracked down the main issue with my lock ups.
    These appear to be 2 fold:

    1. power supply with inadequate output capability. I am now using 5v @1A guaranteed.
    2. current being feed into FiPy pins from other devices during deepsleep, etc. This was happening when I connected a USB dongle to monitor serial output. Situation improved by only connecting receive line and not transmit line.

    Thanks for everyone's suggestions.

    I would still like to find details for the actual specified power consumption requirements. Does anyone know where these are exactly. I am looking for a maximum current rating requirement at 5V operation. I am just assuming 1A is addequate for now.

    I will create a new post if other issues arrive.


  • Correction. My previous post should have read "hang on and run for a solid 8 hours".

  • Made some changes in the power supply area to ensure that I have plenty of current and voltage at the device.
    I managed to get the device to hang on and run for a solid hours. It finally crashed, this time reporting a failure of the LTE.deinit() call. The OS reported "no such function".

    So maybe there is some truth in the power supply sensitivity area.

    Yes, I run a serial cable from the device during debug, so I can capture any repl error messages.

    I am not sure that a power meter will give me much more information, I can tell from the temperature of the device that it is running and not in deepsleep when it fails.

    Can someone from Pycom tell me the power supply specifications for the FiPy. I can not find a clear specification for this in the documentation that I have looked at.

    What power supply circuits do others use/recommend on their low power projects for this device?

    I need a supply that will run from a small 6V SLA battery. So needs a low drop out and must be low quiescent current to keep battery consumption as low as possible.

    The FiPy is being adapted into an existing design. If is replacing an existing PIC micro (which has worked successfully in our products for many years). We are attempting to develop a field retrofitable solution.

    As for I/O, the design implements a number of A to D inputs, multiple digital outputs to drive external devices (lights, motors, etc), a serial port connection to a legacy modem. It also uses all the comms capabilities of the FiPy (except BLE).



  • @tuftec Can you measure the power drawn in that situation, ideally over time?

    It's not 100% clear from your description if the issue is the WiPy not going to deep sleep, or not correctly restarting when it should come back from sleep. If current doesn't drop dramatically when you go to deep sleep, then it doesn't actually sleep. Won't necessarily be easy if it takes hours to happen as you would need to be able to keep the current history for a little while to be able to check that.

    What features of the WiPy to you use? Wi-Fi? BLE? External sensors or other peripherals? Timers? Anything else? Have you tried running a test with just switch LED on + sleep a second or so + deep sleep, to see if the problem happens without any other interaction. If it doesn't happen, then you can gradually add features until the problem happens again. Though if the problem takes a few hours to happen, it can take a while to isolate.

    Not sure what code there is in machine.deepsleep that may be waiting for something to happen before sleeping, and too lazy to check the source, but you want want to peek in there for ideas.

    Do you have USB (or another way to see the UART output) connected? There could be some relevant output, like a guru meditation error (or even worse, a guru meditation loop)...

  • @tuftec said in Deepsleep issue on FiPy:

    I am not sure how I could implement the watchdog timer while using deepsleep. When in deepsleep most functions are turned off already.

    Have you checked with a power meter, if the device fails to sleep or fails to wake up? In the first case there's a high chance that the watchdog can help.

    Add some normal sleep before the deepsleep call, if you deinit networks manualy or sending messages in front of the deepsleep.

  • I am already running the development firmware version.
    I am not sure how I could implement the watchdog timer while using deepsleep. When in deepsleep most functions are turned off already.

    It only dies when I attempt to go into deepsleep.

    There is no indication of lockups or anything similar when transmitting in LoRa, SigFox or NB-IoT. The problem only arises when going into deepsleep.

    The unit is already running of solar/battery. Power to the module is derived from 2 x CMOS LDO regulator (5V) with a combined minimum output of 500mA and peak supply of up to 1A (for short periods).

    I will continue further testing.

    Any other suggestions.


  • At first mind that the software watchdog can get your device out of such states.

    If you can use the development branch of the firmware, switch to the latest 1.20. Since 1.20.rc4 a newer esp idf version is used, which fixed a lot of timer problems.

  • @tuftec I currently run five wipy+pysense on a lab power supply. They draw 0.55 A @ 4.2V in total.

  • I don't know. You cold try a Lipo battery. Do you have a raw device? Or have you put it on an expansion board or similar?

  • Thanks for the suggestion.
    How much power do I need?
    I have 0.5A @5V currently at the module.


  • What kind of power supply do you have? I guess the power source is to week to awake your device from sleep. I have similar issues. When I increase voltage of my power supply to 5 V it works fine. So my advice for you is to test another power supply.

    I am also thinking of implementing an external watchdog wich can reset the divice. But I don't know how to do at the moment. ...

Log in to reply

Pycom on Twitter