boot.py reliability

[robert-hh]

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

[kjm]

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

1. If user code is present in flash as boot.py or main.py 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 main.py & is explicitly run with boot.py via machine.main('main.py') 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.

[robert-hh]

@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 boot.py,. main.py or the like open entry and exit?

[kjm]

@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', 'main.py', 'sys', 'lib', 'cert', 'boot.py', '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]

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

[kjm]

@robert-hh I used the large hammer as per your suggestion & load user software as main.py with the boot.py below.

import machine, pycom
red=0x7f0000; green=0x007f00; orange=0xff5100; blue=0x00007f; off=0x000000; white=0x7f7f7f; magenta=0x7f007f; cyan=0x007f7f; lowhite=(0x101010); yellow=(0x7f5100)
hook='main.py'
print('trying for', hook)
pycom.heartbeat(False)
pycom.rgbled(white)
cycle=pycom.nvs_get('cycleboot'); cycle+=1; pycom.nvs_set('cycleboot', cycle)
wdt=machine.WDT(timeout=20000)                                                                                                                                  # 20s for main.py to run & extend the wdt timeout
machine.main(hook)                                  

Because there are independent cycle counters in main.py & boot.py I can see how often boot.py fails to run main.py
Timestamp observed Timestamp received Value
2019-01-17 8:24 AM 2019-01-17 8:24 AM 1 cycle boot fail found @ cycle 161
2019-01-17 1:17 AM 2019-01-17 1:17 AM 1 cycle boot fail found @ cycle 87
Results much as before

[cmisztur]

I get these CDUP folders too on 1.19.0.b4. os.fsformat('/flash') fixes it but then it gets all jacked up again.

[alexpul]

I recently ran a test with the WiPy where it woke up, executed boot.py, which directed it to run "filename" using machine.main(filename), then went to deepsleep. It was connected to a battery (through a breadboard, not the expansion board). After some number of runs it stalled and when I looked at the files it had the same long list of '\x00\x00\x00\x00\x00\x00\x00\x00.\x00\x00\x00' files. I had run the script dozens of times before with the WiPy connected to a wall socket using a USB to UART cable and have never seen corrupt files like that. Is it the battery and machine.main() combo that does this?

[robert-hh]

@alexpul It looks like an unstable supply problem, caused by the battery and the breadboard connections. USB supplies 5V, the battery (assuming Li-Ion) about 3.6V. So the headspace for dealing with power fluctuations is smaller. And you did not tell the type and capacity of the battery.
Using machine.main() does not at all affect the file system It just stores a string in memory with the file name, which is executed instead of main.py. Similar to an "import filename" at the end of boot.py.

[alexpul]

@robert-hh Thanks for the reply! So basically an unstable power supply can lead to flash errors. Good to know.
(And you had it, I was using a Li-Ion 3.6V battery. I'll make sure to mention that next time)