boot.py won't run automatically. Only via pymakr plugin or machine.reset() from repl.

[JonasDe]

Hi everyone!

I apologize if this is not the correct forum for this question, feel free to move this post if that's the case.

I am using a PyTrack+LoPy4 and I'm encountering problems with boot.py unless I manually upload the code via pymakr. It only runs when I re-upload the code through pymakr, which obviously doesn't work in a headless/detached scenario.

This is my boot.py:

# boot.py -- run on boot-up
import time
from machine import UART
import machine
import os
import led

uart = UART(0, baudrate=115200)
os.dupterm(uart)
l = led.LED()
l.cycle()
machine.main('main.py')

l.cycle() simply sets the led to blue once that code is run. If I plug the USB and let the LoPy4 power up it does not switch the led on. However, if I upload the code via Pymakr it does run boot.py and correctly turns the led on.

I can manually connect via minicom /dev/ttyACM0 and access the repl by pressing CTRL-C. Here I can not access any of the variables or imports from boot.py. Doing

>>> import machine
>>> machine.reset()

will reset the device which then runs boot.py correctly and turns the led on.
The folder structure is

/flash/
   boot.py
   main.py
   led.py
   cert/
   sys/
   lib/

Is there something crucial that I have missed?

Thanks in advance,
Jonas

[JonasDe]

I tried connecting it directly to a power outlet instead of via the serial port - that seems to do the trick.
This is however a major problem. What I want to do is capture the stdout of the device automatically.
This can be done easily via minicom or similar. The problem herein lies in that I have to first push the code through the pymakr-atom plugin.

My planned sequence is:

1. Edit some code
2. run flash.sh which is a script that :
   2.1 removes everything except lib, sys, cert, boot.py.
   2.2 copies everything in the current folder to the device
   2.3 resets the device
   2.4 captures the output into a log-file

Being forced to open atom and manually upload the code during step 2.2 makes this a very tedious process when editing a lot of code.

If anyone has a better option I'm open to suggestions, or if you know a way to force boot.py to run even if the code isn't uploaded via pymakr. Clearly the device can receive enough power to run boot.py since it's being run when manually forced to, but just not from the start.

Thanks in advance,
Jonas

[seb]

@jonasde

Can you test the latest firmware, there was an issue with the onboard LED where if the heartbeat was disabled and a colour were sent to soon after, the led would not work. This has been fixed in the latest firmware. Let me know if this solves your issue if not we can investigate further

[JonasDe]

@seb

I have flashed with 1.17.3.b1 but the problem persists. I am quite certain it doesn't lie with the led since I added the led to debug the main issue, which was that the LoPy4 didn't run any of the code in main.py. There I am printing to stdout and also sending a packet over the LoRa network, and neither code seems to run.
When I upload the code with pymakr everything works fine. boot.py runs, main.py also runs and it starts sending packets and is printing to stdout. But booting only by powering the LoPy4 with the serial port won't start anything other than the normal heartbeat LED. I do have access to the REPL when connecting via serial port (where I can do machine.reset(), which then will run boot.py).

[robert-hh]

@jonasde From V1.16.0.b1 there is this nice "feature" that Ctrl-F will boot the device in a kind of safe boot state, ignoring boot.py and main.py. That is used by PyMakr to bring the device in a known state, where it responds to REPL. This crooked state will not go away until you perform a hard reset.
Maybe it's that what you see here.

[JonasDe]

@robert-hh

It does seem like it for sure. All the symptoms of a safe boot is there, but how can I prevent this from happening then when I have it connected to the computer?
It doesn't do it if I plug it into the wall with an adapter, so I'm guessing it's either a power issue (if the serial port doesn't provide enough power for it to boot normally) or something with it recognizing that it's being connected on a serial port which in itself will force it into safe boot?

[robert-hh]

@jonasde For verification, you can use a different and dump terminal software like Putty (Windows), screen (mac, linux) or picocom (Linux).
Just make sure that any kind of handshake is disabled.
For fil etranfer you can use an ftp client like filezilla or fireftp.