main.py completes with repl but not with reset or cold boot

[pyblendnet-js]

I have discovered some unexpected behaviour of the RP2040 after a hardware reset.
If I run the following code as main.py using rshell and repl, the on board LED turns red then green.
But if I reset or re-power the board, the LED stays red, which tells me the main.py failed during the call to sleep().

#test to determine if program was completed when booted on power only for RP2040
from time import sleep
import machine

#LED only required to determine processor status
#note: I am not using a std rp2040 board, which has onboard led on pin 25
#      my Waveshare RP2040-Zero has a single Neopixel RGB LED on pin 16 
import neopixel 
neopix = neopixel.NeoPixel(machine.Pin(16), 1)  
neopix[0] = (10, 0, 0)  #red to indicate starting program
neopix.write()

sleep(0.5)  #0.4 second is okay for power only boot, but 0.5 second is not (ie. program halts here)
  
neopix[0] = (0, 5, 0)  #LED to green to indicate program complete
neopix.write()

Note, if I reduce the sleep() duration to 0.4 seconds, all is well.
I believe this behaviour is isolated to the rp2040. I tried the following with a ESP8266 and the LED goes off after 5 seconds regardless of how the program is booted.

#test to determine if program was completed when booted on power only for ESP8266
from time import sleep

from machine import Pin
led = Pin(2, Pin.OUT)  #D4 on WeMos ESP8266
led.off()

sleep(5) 
  
led.on()

The RP2040 is on a Waveshare RP2040-Zero and the micropython installed is MicroPython v1.19.1-724-gfb7d21153 on 2022-12-01; Raspberry Pi Pico with RP2040
I develop on kubuntu.

The nearest similar discussion I could find was on an archive but that seemed to concern boards without auto-reset. I also saw mention of something similar if the i2c clock is set too high, but that is probably irrelevant.
My guess is that any process longer than 0.4 seconds is going to cause the same issue, but I'd rather not go down that rabbit hole blindly.
Is there a default watchdog timer perhaps?
What is different about the soft reset?
Does Repl disable something that a hardware reset does not?
Is this behaviour related to Micropython at all?
Thanks for any guidance.
Cheers.
P.S. I'm using rshell because it allows me to develop on two microcontrollers at the same time. I discovered this problem when the magnetometer library I was using had a one second delay if it couldn't find a calibration file.

[steveh127]

I've tested this on a SeeedStudio XIOA RP2040 module which also has a single neopixel though on GPIO 12. And it works as expected whatever the sleep period.

Have you tried using an external LED? At least check that it's not a problem with neopixel. With an issue like this the minimal case will help to isolate the problem.

[pyblendnet-js]

Thanks Steve. I did as you suggested and it works without REPL with an external LED, but now it is also working with the code using the Neopixel. Also works when I power the RP2040 using a battery. The only thing that's changed since yesterday is the usb port for the rshell connection. Excuse me while I go and bash head against wall. Maybe next time this happens I'll just leave the problem overnight and it will go away by itself. :)

[robert-hh]

I have a strange problem with RP2040 that they do not reliably show up when connected to a USB hub, but directly connected to the PC they work fine. Not reliably means: not all, or after 40 seconds, or instantly, without a clear pattern. Maybe there's a similar situation at your set-up. I did not search a lot for the reason. Maybe a should. Until now I just curse and change the slot. No reason to damage the wall.

[pyblendnet-js]

Thanks Robert. I've discovered that for the two micropython boards I've tried (RP2040 Pico-Zero and WeMos ESP8266) the Linux OS sometimes assigns a new device name when I plug them into the same USB port, sometimes not. I've not see Linux do that before. I think I've had trouble with Arduinos when using a USB hub. The complexities of the sub-systems are such that it is amazing anything works at all.

[dhalbert]

I am not sure this is related, but we found on a number of boards that the xtal clock does not stabilize as quickly as the default delay for this. I PR'd a fix for this, raspberrypi/pico-sdk#457, which we apply to all Adafruit boards (added PICO_XOSC_STARTUP_DELAY_MULTIPLIER, and set it to 64). In our case, things did not start at all. It's an easy thing to try: just set another compile-time constant for use inside the pico-sdk.

[pyblendnet-js]

That does sound like a plausible cause. If I see the problem return, I will try your remedy. Can the behaviour of the xtal depend on the weather or maybe cosmic particle activity? I hate it when problems get down to the quantum level.
In my case, it was odd that the program started then stopped during a sleep. I don't actually know what it is doing during a sleep.