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

  • @kjm said in reliability:

    @jcaron This was crashing before I added the led to see where it was happening.

    There are multiple ways how your program may fail during startup. If you have only a small RAM device you may run into out of memories during compile or init time. Memory fragmentation may vary for eexample with loops waiting for network or other resources.

    Importing faulty modules may halt the system without useful error messages. Test your imports. I ran into this by typing into the wrong window and noticed it only when it ran into the right path on startup.

    The pytrack needs some time time for a clean i2c access. My device needs up to 5 seconds. Be sure that you are testing the device with nearly the same timings. So don't use print statements only when *Py is connected to your development machine.

    At best you cahnge the LED color at the first line of your
    Additionaly after a few imports, so you can do a binary search for a failing import.

    Add a try-except statements aournd your main parts and write the exception into flash.

  • @jcaron This was crashing before I added the led to see where it was happening. I'm logging the LiPo cell voltage, it shows the same upward trend regardless of the days temperature. If this happened when I tried to use the lte I'd suspect the battery but simply loading a program from a different folder shouldn't change the current demand. The gpy is specd to work from 3.5-5.5v supply on Vin so as long as the battery stays above 3v5 I figure it should work.

  • @kjm Maybe the LED is adding a few extra degrees, or adding a bit to the power consumption, and your battery doesn't like the combination of heat and extra power requirements?

    Batteries can behave quite differently when deviating significantly from "usual" room temperatures.

  • Already tried that plus a few other path combos Rob, always stops working eventually. I've got a suspicion it's temperature related. Always happens in the heat of the day, gets up to 55 celsius in the little solar enclosure that keeps the battery charged. But 50 celsius should be OK shouldn't it? And it doesn't fall at that temperature if I make my program

  • @kjm Since the RGB LED get's white, is executed. What does not seem to get executed is, which is called instead of Could you try to specify the full path name '/flash/client/' ?

Pycom on Twitter