Adafruit ItsyBitsy RP2040 - sketch doesn't run after reset or unplugging, following upload

[Andy2No]

After successfully compiling and uploading a sketch to an Adafruit ItsyBitsy RP2040, with the Boot button pressed as it was plugged int, and confirming that the sketch is running immediately after the upload, I've found that it doesn't run after pressing reset or after unplugging the USB cable, then plugging it back in again.

The sketch also doesn't run if I plug the USB cable into a USB power brick, and I've confirmed that it does work that way if I put the code that it came with back on, by dragging "ItsyBitsy_RP2040.uf2" to the USB drive that I get by holding down the Boot button.

Also, after plugging the USB lead in, the serial port for it does not appear in Device Manager - that only happens after uploading a sketch after plugging it in with Boot button pressed.

I just got a couple of Adafruit ItsyBitsy RP2040, today, and it's been a struggle to get this far, due to lack of driver support (they don't appear to have added it to the last release), but the Zadig procedure from issue #96 got the serial port working, immediately after upload.

I'm using a variation on Blink which also sends messages to the serial port, so at the very least, I should see the red LED blinking - but that only happens immediately after uploading it, until it's reset or power cycled, then it does nothing.

Is it possible that it's only loading the sketch into RAM, so it runs initially but doesn't survive a reset or unplug/re-plug?

[Andy2No]

The same behaviour happens if I plug it in with the Boot button pressed then drag and drop the .uf2 output file from the last compilation, to the USB drive that appears - the sketch runs, but only until I press Reset, or unplug it and plug it back in again.

I've attached a zip with the .uf2 of the code that comes pre-installed on the ItsyBitsy RP2040, plus the .uf2 compiled version and .ino source code of the test sketch (Blink with serial output), and the smaller files from the compilation build folder for the sketch.

Blink_beacon.ino.zip

[Andy2No]

I've now also checked with a simpler form of a Blink sketch, with no usage of the serial port. The behaviour is the same - the sketch runs immediately after uploading but not after pressing Reset, or after unplugging it and plugging it back in again, or connecting it to a USB power brick.

I'm using the current version of arduino-pico, version 1.9.4.

[PontusO]

It sounds like the flash isn't written correctly. Try using the "Generic RP2040" board and setting "Boot Stage 2:" to "W25Q080 SPI/4" and see if it works.

[Andy2No]

It sounds like the flash isn't written correctly. Try using the "Generic RP2040" board and setting "Boot Stage 2:" to "W25Q080 SPI/4" and see if it works.

Thanks for the suggestion, but that did the same thing - other than having to do the Zadig thing again to make the port work temporarily. After a reset or unplug/plug back in, no port appears and it doesn't run the sketch.

The same also happened if I set Boot Stage 2 to "W25Q080 SPI/2"

I've also tried reverting arduino-pico to 1.8.6, because that's the version that was shown on the adafruit page on how to install Earle's core:

https://learn.adafruit.com/rp2040-arduino-with-the-earlephilhower-core/installing-the-earlephilhower-core

Since that did exactly the same thing, I have to wonder how well they tested it.

[dhalbert]

Due to component variations, some samples of some our (Adafruit's) boards require a longer RP2040 XOSC (crystal oscillator) startup time than the minimum defined as the default in the pico-sdk code. We have added a compile-time parameter to pico-sdk, PICO_XOSC_STARTUP_DELAY_MULTIPLIER, to compensate for this.

The code that starts the XOSC and that uses this parameter runs before main(). However, the philhower core uses a precompiled libpico.a that's the same for all boards, so it's not possible at the moment to customize the startup delay. I was just looking at this problem before I saw this issue.

Ideally there would be a pre-compiled libpico.a per board, or it would be compiled at sketch compile time. There is no mechanism to do either of those right now, and I'm looking to see how hard that would be to do.

[earlephilhower]

@dhalbert Isn't the actual change only in the boot2 stage, since that's what's responsible for setting up the SPI hardware config before the ROM jumps to the flash code?

We do have 8 versions of that already built and included (and selected through the board config), so adding one more would be a trivial exercise.

[dhalbert]

@earlephilhower: The boot2 code calls runtime_init(), which is in libpico.a. runtime_init() does a lot of things including calling xosc_init(). We added a #define PICO_XOSC_STARTUP_DELAY_MULTIPLIER, which is used in xosc_init() when a pico-sdk build is done for a particular board.

So the problem is that the delay used in the "universal" libpico.a is not long enough for some boards.

I'm going to submit a PR momentarily which increases the delay for all boards.

See raspberrypi/pico-sdk#457 and raspberrypi/pico-sdk#401 for some background on this problem.

[dhalbert]

@Andy2No Try replacing ~/.arduino15/packages/rp2040/hardware/rp2040/1.9.4/lib/libpico.a with the libpico.a in the pull request: https://github.com/earlephilhower/arduino-pico/blob/391f7af8364f5fc37d6dcb2fa2e2d2fd5d5e1d51/lib/libpico.a (https://github.com/earlephilhower/arduino-pico/blob/391f7af8364f5fc37d6dcb2fa2e2d2fd5d5e1d51/lib/libpico.a?raw=true for a direct download). See if it works with your ItsyBitsy RP2040.

[Andy2No]

@dhalbert EDIT: I had a problem which was apparently caused by MalwareBytes, when I tried that, but after rebooting, deleting the core installation and starting again, that works perfectly. Thanks.

[Andy2No]

(ignore - unrelated problem)

[Andy2No]

@dhalbert FWIW, I've just tried the suggestion from the quoted forum post in raspberrypi/pico-sdk#401 (from blakebr in https://forums.adafruit.com/viewtopic.php?f=60&t=178640) "I have to push the reset button up to a dozen or more times to get the first green LED light.".

That works for me too! Pressing Reset four or five times started the last sketch I loaded running. Unfortunately, it was the LED blink only one, so I can't see or try the serial port, and I'm having trouble getting anything to compile again - putting the old libpico.a back isn't working, but never mind. I'll try reinstalling. This is all very promising, anyway.

[Andy2No]

@dhalbert Sorry for any confusion. My first attempt at trying it failed, but it seems it was Malwarebytes interfering. I've had problems upgrading pico-arduino, due to that before.

Yes, that works perfectly, at least so far. I'll experiment a bit more and let you know if there are any caveats to add. Thanks again.

[hathach]

@Andy2No since you are testing it, would you mind also try to change the boot2 file of the qtpy from from boot2_generic_03h_4_padded_checksum to boot2_w25q080_2_padded_checksum as well, this will dramatically improve the flash speed for executing code.

https://github.com/earlephilhower/arduino-pico/blob/master/tools/makeboards.py#L139

once changed the boot2, you need to run the code then replace it with the original boards.txt

python makeboards.py > boards.txt

Initially when I add the qtpy board #144 , I encounter this issue as well, back then the above fixed mentioned by @dhalbert aren't implemented just yet, and I have to pick the generic boot2 for qtpy able to run at all. I will also try to test it out as well, but it would be great to have another user feedback.

[Andy2No]

@hathach I'd be happy to, but I don't have a QtPy, only the ItsyBitsy RP2040. Do they share the same file(s)?

Also, I'm using Windows, so I don't have python installed, so I can't do this part, easily:

python makeboards.py > boards.txt

If not having a QtPy isn't a problem, and someone wants to give me some clues on getting started, I'll give it a go, but maybe it's best left to someone who actually knows what they're doing :)

[hathach]

@Andy2No opps, I am sorry, my brain confuse my self, I was thinking itsybitsy is the same as qtpy (due to reading this on the phone). Apparently itsybitsy already using boot2_w25q080_2_padded_checksum that is why it has this issue, and qtpy is totally ok with generic 3h. I will do my test :)