• If I run my user deepsleep code as in a battery powered gpy its reliable. But if I try to run it as from a different folder in flash with as

    import machine, time, pycom
    print('trying for', hook)

    it eventually stops working with the white light on so I know failed to run it. I know I've introduced an extra step but this should work consistently shouldn't it?

  • @kjm Yes, when the file system was corrupted. You can rebuild it with os.mkfs. I would prefer to take the larger hammer and erase the whole flash, reload the firmware and the files.

  • @robert-hh So I just went to do some more work on this & os.listdir() returns

    x00\x00.\x00\x00\x00', '\x00\x00\x00\x00\x00\x00\x00\x00.\x00\x00\x00', '\x00\x00\x00\x00\x00\x00\x00\x00.\x00\x00\x00', '\x00\x00\x00\x00\x00\x00\x00\x00.\x00\x00\x00', '\x00\x00\x00\x00\x00\x00\x00\x00.\x00\x00\x00', '\x00\x00\x00\x00\x00\x00\x00\x00.\x00\x00\x00', '\x00\x00\x00\x00\x00\x00\x00\x00.\x00\x00\x00', '\x00\x00\x00\x00\x00\x00\x00\x00.\x00\x00\x00', '\x00\x00\x00\x00\x00\x00\x00\x00.\x00\x00\x00', '\x00\x00\x00\x00\x00\x00\x00\x00.\x00\x00\x00', '\x00\x00\x00\x00\x00\x00\x00\x00.\x00\x00\x00', '', 'sys', 'lib', 'cert', '', 'project.pymakr']

    All these identical extra directories have mysteriously appeared. They are listed in Filezilla as CDUP 31 31:63 followed by a string of little y characters with 2 dots over them. Have you ever seen anything like this before?

  • @robert-hh So I looked into it. Hearbeat is started in main.c, ~ line 125. The code itself is in util/mperror.c, function mperror_heartbeat_signal(), it is directly called by the freertos_idle_hook, and I cannot see that it is affecting the WDT. Finally, it uses the RMT for controlling the LED, like the machine.rmt module. The only difference I see in using the RMT call is, that in the machine.rmt the call to rmt_write is enclose in a MP_THREAD_GIL_EXIT(), MP_THREAD_GIL_ENTER() pair.
    So it seems that something else fails. Did you try to add print statements to,. or the like open entry and exit?

  • @robert-hh So just an update where I'm at with this:

    1. If user code is present in flash as or it eventually fails to run (usually after several hundred deepsleeps). When this happens the gpy drops into zombie repl mode (blue light flashing but no usb or adhoc wifi & wdt_on_boot disabled).
    2. If user code is present in flash as & is explicitly run with via machine.main('') it eventually fails to run but gpy does not drop into zombie repl mode.
    3. #2) means wdt_on_boot reboots it & we're good for another few hundred cycles. Hey it's not pretty but it works!
    4. I have a hunch that this has something to do with lte since I've never seen user code fail to run when it's using wifi instead of lte, will confirm when sure about this.

  • @kjm I do not know whether the heartbeat interrupt affects the WDT, and actually I have doubts, that it does. I have to look into the code for analysis.

  • @robert-hh Sure would be nice if zombie heartbeat didn't kill pycom.wdt_on_boot(True), makes it a real cul-de-sac!

  • @kjm The respective code should be in esp32/mktask.c. Looking at it, that may happen if there is a problem in executing or which causes a FORCED_EXIT, whatever causes this (lines 278 and 300 of mptask.c). More anaylsis to be done.

  • @robert-hh I still can't get to the bottom of this. A couple of observations about the 4s blue flash mode the gpy drops into:

    1. It looks like regular blue flash mode (4s blue flashes) except it isn't. Can't log in on USB or the gpy ad hoc wifi.
    2. In regular blue flash mode I have to connect P12 to 3v3 then press the rest button to get safe boot. In this mode connecting P12 to 3v3 starts the orange safe boot light flashing, no need to press the reset button.
      Does this tell us anything about what might be happening to stop it running our code after a deepsleep & dropping into this zombie state instead?

  • @robert-hh REPL does not seem to feed the WDT in my experience. When in REPL mode my FiPy and GPy units will still reset themselves when the timer has elapsed if I haven't manually fed it.

  • @kjm said in reliability:

    import pycom; pycom.wdt_on_boot(True); pycom.wdt_on_boot_timeout(10000)

    I do not know. I would have to search if the wdt is maybe re-fed in REPL mode. That seems reasonable. But could'nt you just re-enable the WDT with the line above in Then at least you know that it is enabled. Still that would not affect re-feeding by REPL.

  • @robert-hh I used

    import pycom; pycom.wdt_on_boot(True); pycom.wdt_on_boot_timeout(10000)

    from the cmd line to setup a 10s reboot if our code is not feeding the dog. I figured if the gpy booted into the 4s flash default mode after a deepsleep, the device would reboot after 10s. This doesn't happen even though the flag is still set

    >>> import pycom
    >>> pycom.wdt_on_boot()

    Why is the default 4s blue flash mode immune to wdt_on_boot?

  • @kjm The same as now, except for the last statement, which tells to call client/ instead of

  • @robert-hh So what code should I have in in this instance?

  • @kjm No. always runs before or what you define in to run instead of My suggestion was to skip that re-pointing of in and copy the code from into, such that the sequence of execution is:

    and not, as you tried to define it:

  • @robert-hh So you're saying make my code & leave empty? I don't see the point of this? I've already established that runs before & is more reliable than

  • @kjm There are both and in frozen bytecode, which are executed before contains:

    # -- always run on boot-up, even during safe boot
    import os
    from machine import UART
    os.dupterm(UART(0, 115200))
 is empty.
    About your setup with and That way you actually use the mechanism of and, only than you tell the firmware to use client/ instead of You could try to copy the code from client/ into and drop the reassignung of That way, you can isolate the problems, whther it is a problem in your code or a problem with assignuing the name of a file, which is executed instead of

  • @robert-hh I haven't tried that. seems bullet proof. If I load my code into flash as it always runs after deepsleep. I'm less impressed with, it mostly runs if there is no or nothing in other than the default 29bytes, but not always. Mean time to not loading is around 300 x 6min deepsleep cycles

    When I try to run my code from via machine.main I'm sure the eventual failure is due to not loading because the code uses the rgb led a lot for diagnosis & the colour I see when it stops working indicates the only thing that has run is, albeit unsuccessful in it's attempt to run my code.

    I'm not sure if this is relevant but the gpy has this strange behaviour with new code after a power cycle that troubles me. If I load a new regimen into flash, say a change from my code called by to my code as, I see led patterns in the first few seconds of the first run that indicate it is trying the previous scheme briefly. It's like there is an area in flash, invisible to us users, that the gpy goes to first, like an echo of the previous setup, before it switches to the new one.

  • @kjm Are you sure it completely fails to load/run Or could it start and just crash a bit further during execution?

    Are you also sure it never fails with the script directly in

  • @kjm does it work when you put at the same place as


Pycom on Twitter