Raspberry Pi Pico W - firmware logs

[programer-a]

Hey everyone,

there is a RP Pico W I am using with MicroPython and I am experiencing some issues running it as the main.py is not starting always reliably when running from a USB charger supply. I have elliminated other errors and made some logging in my setup. There is no stratup message printed by the device sometimes and the device doesn't seems to run until the next restart.

I am using now the bellow firmware, but experienced this effect with previous versions too, while developing my software.
v1.19.1-471-g46d02c246 (2022-10-05) .uf2

Is there a way to dump some system level logs made by the firmware?
I have made searches, but haven't found details about making such logs. Are there any available resources for this somewhere?
After that I am happy to open a bug, if seems still reasonable, but without this info I think I have too few details to share about my issue.

[robert-hh]

You could try connecting a serial interface for off board logging, or just use the led to blink at certain stages of main.py.
Under stable power conditions, main.py only refuses to start, if boot.py failed.
If power is not stable, anything can happen.

[programer-a]

Hey @robert-hh,

Thank you for your the reply.
To be able to log a bit easyer, without changing the supply I have used through UART another Pico and sending a start up message at the beginning of the main.py. When the problem occurs, I am not receiving this log message.
The Pico W should start to control a relay board with leds, so I can see that as a physical feedback but that one is still too in the mentioned case.
My code in main.py is in a try expcet block. I am writing the given exception to a file, if any and also sending it to the other pico, but there are none of these getting triggered.

I wasn't be able to eliminate the possibility that this is related to the specific power source I am running the board. It seemed logical to me trying to find out if some OS level operations are failing on startup, maybe that could help, maybe not to stabilize my setup, if there is really something what is failing/throwing an error.

It is a good hint that there is a boot.py, when I will have some time I would like to check this concep, I am not sure if creating one is possible by me and if it could help to make it possible to log errors, which I haven't been able to catch from the main.
I haven't seen it in guides before.
Is there page somewhere discussing it and how to use it?
The official Pico guide mentions that the boot.py as reserved file name and there is more info about it and main.py later in the guide document, but I haven't found anything there about boot.py there.

[robert-hh]

There is nothing magic about boot.py and main.py. They are started one after the other, boot.py first. And if boot.py ends with an exception, main.py is skipped. None of them has to exists. They are "reserved" in the sense that they are started in the boot process. On some boards USB communication is enabled in the gap between boot.py and main.py. I did not find the place in the documentation where this is mentioned. Strange.

[programer-a]

Thank you for the reply and the describing the flow of controll. I'm not sure how I could use the USB when connected to the power supply which is not capable to communicate with the device, I have seen some description about the DEBUG pins and UART and as I am not using C I have decided to make some logging with the later. Also I am not sure how to use this capabiliby. When the boot.py would finish (I haven't created one), the control is on the firmware side if I understand it right. I was wondering if it would be possible to read messages via the DEBUG pins from the firmware, if any. I am not familiar with the firmware code, so I am just trying to understand what are the options to get a bit more information, when I am using MicroPython

[robert-hh]

You can of course us a UART to print debug messages, both in boot.py and main.py.

[programer-a]

Hey @robert-hh,

I am using UART already to make logs from my code parts and that is how I have realised that my main.py not seems to run.

"To be able to log a bit easyer, without changing the supply I have used through UART another Pico and sending a start up message at the beginning of the main.py. When the problem occurs, I am not receiving this log message."

My question is could I do the same with the firmware?

[jimmo]

the main.py is not starting always reliably when running from a USB charger supply.

@programer-a does this issue ever happen if you're running from a different power supply (e.g. USB connected to your computer?)

Do you enable WiFi? At what point in startup does that happen? Do you see the issue if you don't enable WiFi?

[robert-hh]

I just noticed that I was wrong. main.py will be called even if boot.py failed.

My question is could I do the same with the firmware?

To talk witj Radio Erivan: principally yes. You can call the internal functions from the machine_uart.c file from the firmware, but setting up the arguments is not easy. Especially the call to machine_uart_make_new() requires Python type objects as arguments. Sending data is easier, just call machine_uart_write(). It has a simple argument structure, since it is used in a C context. @jimmo certainly knows how to do that.

[programer-a]

Than you @robert-hh. It sounds promissing that it is possible :)
Maybe it is a bit more complicated then I have expected, but if I have some time maybe I will play around with making the build work and setup the basics to send messages.

I would appriciate any further guidance about the parametrization @jimmo.
Thank you for both of you.

Maybe I haven't answared all the questions yet, but if I will have a bit more time, I will try to reproduce with and without wifi if I can. If I find something then I can come back here or open a bug later to talk about it further.

[programer-a]

Hey @jimmo and @robert-hh,

I have found a stabile physical test case for the problem. In my setup I am using to power the Pico W with a solar panel.
If I am covering it and uncovering enough to run the Pico that has different results depending on the speed of uncovering it. Maybe in another setup, like with a potenciometer meter this can also be reproduced.
When I uncover my panel in about 20-30s then the startup fails and the device is not calling my main.py after the current strength should be enough, even if I am uncovering the whole panel and other connected, non-programmed devices have enough energy to operate.
Maybe there is a electro technical solution, like a switch which would turn on only above a given current strength, but I am not aware of any yet.
I am not sure if the failure can be eliminated on firmware site as I am not that familiar with the implementation.

If you think, I can switch off the WiFi also, or try to check it with a normal Pico, but not sure how much that could help.

[programer-a]

Hey @jimmo, Yes, I am using WiFi. I have tried to disable the WiFi before once, because some older threads suggested it had some similar effect on startup previously. There was a way to turn logging on for the WiFi operations, but I don't remember where did I see this. I will try to continue searching. My time is a bit limited to work with this now, but I will try to check this gradually. In docs of network and the WLAN class, I have found the active("down") as an option to turn the interface off. Thank you for your suggestion, I will try to eliminate the relationship with WiFi if possible in tests. I am usually using other power sources only for programming until now. Sometimes I am experiencing connection issues via USB, but I had some errors also after my main call I have found. To reproduce and then test. will take me lots of time. It there no way to see at least some feedback from the firmware about the start up by creating a file or some other way?

[robert-hh]

You can create a log file and write messages to it. Just thing of calling flush or close the file after each message to be sure, that the message in in the file, in case that the device crashes. I would prefer using a UART to send messages.