Code testing without wires

[kjm]

My fav way to test code that deepsleeps is to run it overnight plugged into Atom & check the diagnostic prints in the morning. This works great on the USB port but not so good over wifi. The gpy re-establishes its wifi (either AP adhoc or STA to the router) after a deepsleep but Atom doesn't reconnect to it unless I click the 'Connect Device' button. I'm struggling to understand why Atom can't automatically reconnect to a post deepsleep gpy over wifi the same as it does over USB. Can someone enlighten me?

[Antonis Gotsis]

@kjm I can't really understand the "reconnect to a post deepsleep gpy over wifi" for checking printouts. In order to see the debug printouts you need a cable and a serial prompt.

[kjm]

@Antonis-Gotsis When Atom is connected via usb the gpy wakes up from a deepsleep, runs the program, prints any errors it encounters, deepsleeps. When Atom is connected via wifi the same happens on the first cycle. On subsequent cycles Atom doesn't show the prints unless I'm there to press Atom's 'Connect Device' button after the gpy wakes up & reconnects to the router.

I don't understand why the gpy stays connected to Atom after a deepsleep over usb but not wifi.

[robert-hh]

@kjm The USB connection through a UART/USB bridge stays active even when the ESP32 is shut down. So Atom may not notice the deepsleep, and will be able to capture whatever comes along from the first moment on the ESP32 wakes up again. This is different to devices where the MCu has the USB controller built-in, like the new ESP32-S2 or STM32 or RP2040. There, the USB connection will get lost during a reset. The Wifi link between PC (Atom) and the xxPy will be closed when the device goes to deepsleep. The link has to be actively opened again by the PC, and the xxPy will not service that open request until the telnet server is started. That happens during boot, but not at the first moment.
So for reconnecting Atom would have to permanently try opening the link again, and still some of the boot messages will be lost.

[Gijs]

On our side, we usually use minicom on a linux machine for overnight logging that logs to a file, this 'always' survives the deepsleep. If you have no other option that logging wireless,
You could create either a log-file on the device and write to it from micropython, something like this: (unfortunately this will not capture any coredumps in the logfile)

f = open('/flash/[date].log', 'wb')

def log(thing)
   print(time.time(), 'logging: ', thing)
...

Or perhaps use a pybytes solution, where you

pybytes.send_signal('log')

But again, that does not log any coredump data, you can only retrieve that through USB, as it is not communicated over telnet.

[robert-hh]

@Gijs said in Code testing without wires:

On our side, we usually use minicom on a linux machine for overnight logging that logs to a file, this 'always' survives the deepsleep.

That's what I am doing too, if I need logging.

[Antonis Gotsis]

@robert-hh @kjm Personally, I am also using a Linux machine with simple Python script that reads the serial port (/dev/ttyUSB0), makes some formatting and dumps data to a file (in this way you can handle outputs that "overwhelm" terminal prompt)

[robert-hh]

@Antonis-Gotsis What I do is starting the usual teminal emulator - picocom or tio - and pipe the output into tee. That way I see the screen and the output is written to a file too. tio has the nice option to add a timestamp to each line if requested.

[kjm]

@robert-hh said in Code testing without wires:

So Atom may not notice the deepsleep

Interesting Rob. I notice on longer deepsleeps (>1hr) that Atom over usb often misses the wakeups too. I don't understand the mechanism though. Some nights Atom will show every hourly wakeup print. On the occasions where it misses one it never reconnects.