boot.py reliability

[kjm]

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

[robert-hh]

@kjm There are both _boot.py and _main.py in frozen bytecode, which are executed before boot.py. _boot.py contains:

# _boot.py -- always run on boot-up, even during safe boot
import os
from machine import UART
os.dupterm(UART(0, 115200))

_main.py is empty.
About your setup with boot.py and m2m.py: That way you actually use the mechanism of boot.py and main.py, only than you tell the firmware to use client/m2m.py instead of main.py. You could try to copy the code from client/m2m.py into main.py and drop the reassignung of main.py. 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 main.py.

[kjm]

@robert-hh I haven't tried that. boot.py seems bullet proof. If I load my code into flash as boot.py it always runs after deepsleep.

main.py I'm less impressed with, it mostly runs if there is no boot.py or nothing in boot.py 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 boot.py 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 boot.py, 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 boot.py to my code as boot.py, 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.

[jcaron]

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

Are you also sure it never fails with the script directly in boot.py?

[robert-hh]

@kjm does it work when you put m2m.py at the same place as main.py?

[crumble]

@kjm said in boot.py 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 m2m.py
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.

[kjm]

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

[jcaron]

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

[kjm]

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 boot.py

[robert-hh]

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