PlatformIO download stops working after 1st download from platformIO

[fatherseye]

Hi,
Great work on the framework. I have been using the 'stable' platform IO environment with a Rpi pico for a while and it works great. However, all the work you have done on the pico-w and additional feature support is just too cool not to use.
When I try a project with platformio.ini set to:

[env:pico]
platform = https://github.com/maxgerhardt/platform-raspberrypi.git
board = pico
framework = arduino
board_build.core = earlephilhower

It clones the framework, compiles it all, generates the firmware and uploads it and it runs fine. However, when I try to upload again the pico responds to reset from picotool and isn't seen again. To recover the device you need to power up in bootsel mode and copy a different firmware made using an alternative environment to the pico which then starts to behave properly again until you try another download. I've tried it with a standard pico and pico-w and they both behave the same.

Am I doing something stupid?

The output below is from a flash sketch setup and build fresh. You can see the 1st download work. The sketch runs but on the second download the pico vanishes from the USB devices in device manager after the forced reset operation.

*  Executing task: C:\Users\steve\.platformio\penv\Scripts\platformio.exe run --target upload 

Processing pico (platform: https://github.com/maxgerhardt/platform-raspberrypi.git; board: pico; framework: arduino)
----------------------------------------------------------------------------------------------------Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/raspberrypi/pico.html
PLATFORM: Raspberry Pi RP2040 (1.7.0+sha.ff7a675) > Raspberry Pi Pico
HARDWARE: RP2040 133MHz, 264KB RAM, 2MB Flash
DEBUG: Current (cmsis-dap) External (cmsis-dap, jlink, picoprobe, raspberrypi-swd)
PACKAGES:
 - framework-arduinopico @ 1.20401.0+sha.8aad2ca
 - tool-mklittlefs-rp2040-earlephilhower @ 5.100300.220714 (10.3.0)
 - tool-openocd-rp2040-earlephilhower @ 5.100300.220714 (10.3.0)
 - tool-rp2040tools @ 1.0.2
 - toolchain-rp2040-earlephilhower @ 5.100300.220714 (10.3.0)
Flash size: 2.00MB
Sketch size: 2.00MB
Filesystem size: 0.00MB
Maximium Sketch size: 2093056 EEPROM start: 0x101ff000 Filesystem start: 0x101ff000 Filesystem end: 
0x101ff000
LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 27 compatible libraries
Scanning dependencies...
No dependencies
Building in release mode
Retrieving maximum program size .pio\build\pico\firmware.elf
Flash size: 2.00MB
Sketch size: 2.00MB
Filesystem size: 0.00MB
Maximium Sketch size: 2093056 EEPROM start: 0x101ff000 Filesystem start: 0x101ff000 Filesystem end: 
0x101ff000
Checking size .pio\build\pico\firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [          ]   2.7% (used 7056 bytes from 262144 bytes)
Flash: [          ]   2.6% (used 53896 bytes from 2093056 bytes)
Configuring upload protocol...
AVAILABLE: cmsis-dap, jlink, picoprobe, picotool, raspberrypi-swd
CURRENT: upload_protocol = picotool
Looking for upload port...
Auto-detected: COM28
Forcing reset using 1200bps open/close on port COM28
Uploading .pio\build\pico\firmware.elf
rp2040load 1.0.1 - compiled with go1.15.8
...Loading into Flash: [                              ]  0%
Loading into Flash: [=                             ]  6%
Loading into Flash: [===                           ]  12%
Loading into Flash: [=====                         ]  18%
Loading into Flash: [=======                       ]  24%
Loading into Flash: [=========                     ]  31%
Loading into Flash: [===========                   ]  37%
Loading into Flash: [============                  ]  43%
Loading into Flash: [==============                ]  49%
Loading into Flash: [================              ]  55%
Loading into Flash: [==================            ]  62%
Loading into Flash: [====================          ]  68%
Loading into Flash: [======================        ]  74%
Loading into Flash: [========================      ]  80%
Loading into Flash: [=========================     ]  86%
Loading into Flash: [===========================   ]  93%
Loading into Flash: [============================= ]  99%
Loading into Flash: [==============================]  100%


=================================== [SUCCESS] Took 5.43 seconds ===================================
 *  Terminal will be reused by tasks, press any key to close it. 

 
Processing pico (platform: https://github.com/maxgerhardt/platform-raspberrypi.git; board: pico; framework: arduino)
----------------------------------------------------------------------------------------------------Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/raspberrypi/pico.html
PLATFORM: Raspberry Pi RP2040 (1.7.0+sha.ff7a675) > Raspberry Pi Pico
HARDWARE: RP2040 133MHz, 264KB RAM, 2MB Flash
DEBUG: Current (cmsis-dap) External (cmsis-dap, jlink, picoprobe, raspberrypi-swd)
PACKAGES:
 - framework-arduinopico @ 1.20401.0+sha.8aad2ca
 - tool-mklittlefs-rp2040-earlephilhower @ 5.100300.220714 (10.3.0)
 - tool-openocd-rp2040-earlephilhower @ 5.100300.220714 (10.3.0)
 - tool-rp2040tools @ 1.0.2
 - toolchain-rp2040-earlephilhower @ 5.100300.220714 (10.3.0)
Flash size: 2.00MB
Sketch size: 2.00MB
Filesystem size: 0.00MB
Maximium Sketch size: 2093056 EEPROM start: 0x101ff000 Filesystem start: 0x101ff000 Filesystem end: 
0x101ff000
LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 27 compatible libraries
Scanning dependencies...
No dependencies
Building in release mode
Retrieving maximum program size .pio\build\pico\firmware.elf
Flash size: 2.00MB
Sketch size: 2.00MB
Filesystem size: 0.00MB
Maximium Sketch size: 2093056 EEPROM start: 0x101ff000 Filesystem start: 0x101ff000 Filesystem end: 
0x101ff000
Checking size .pio\build\pico\firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [          ]   2.7% (used 7056 bytes from 262144 bytes)
Flash: [          ]   2.6% (used 53896 bytes from 2093056 bytes)
Configuring upload protocol...
AVAILABLE: cmsis-dap, jlink, picoprobe, picotool, raspberrypi-swd
CURRENT: upload_protocol = picotool
Looking for upload port...
Auto-detected: COM29
Forcing reset using 1200bps open/close on port COM29
Uploading .pio\build\pico\firmware.elf
rp2040load 1.0.1 - compiled with go1.15.8
.....................
*** [upload] Error 1
=================================== [FAILED] Took 12.23 seconds ===================================

 *  The terminal process "C:\Users\steve\.platformio\penv\Scripts\platformio.exe 'run', '--target', 'upload'" terminated with exit code: 1. 
 *  Terminal will be reused by tasks, press any key to close it. 

[earlephilhower]

The USB is driven by software on the Pico, so if your sketch crashes or uses TinyUSB and doesn't manually create a serial object then automatic upload can't work.

Does the simple blink sketch work for you? And are you running a RPI Pico or another board? Other boards with different flash chips need different boards to be selected or the bootloader will not work.

[fatherseye]

Thanks for the quick reply.

The test sketch is just this:-

#include <Arduino.h>

const unsigned int pin = PIN_LED;

void setup() {
  //Serial.begin(115200);
  pinMode(pin, OUTPUT);
  digitalWrite(pin, 1);
}

void loop() {
  static int val = 0;
  digitalWrite(pin, val);
  val ^= 1;
  delay(400);
  //Serial.println(val);
}

platformio.ini is as shown above.

The device is a genuine raspberry pi pico board from element14 - although it is a quite early version. I've also tried the brand new pico-w which has the same behavior.

I've reverted to something this simple just to check that it wasn't something I was doing. The blink sketch works i.e. the lamp blinks at 1.25Hz. I added the Serial output (commented out in the code above) which also works via the USB serial monitor. The serial device is reported as present in windows right up until the next upload attempt. It vanishes when the reset is performed.

In the mean time I've been using the framework on the Ardunio 2.0 IDE (nightly build). It works fine and will upload multiple times although I don't think it uses the same mechanism. When I use a pico that has been uploaded using the Arduino IDE it too dies when pico tool does its reset. The reset operation seems to be the thing that crashes in the firmware on the new framework.

This isn't desperately urgent for me because I can use the fancy framework with the Arduino IDE but since you've put so much amazing effort into getting the platformIO stuff working I thought I'd let you know that there could be an issue. Plus platformIO is still a nice environment than the RC Arduino 2.0 IDE.

I'm very happy to help out in any way I can with more tests if there is anything you need to me try.

[earlephilhower]

I'm not a P.IO user so can't help much more, but the serial port is supposed to disappear when uploading.

Basically the uploader (either my Arduino UF2 based one or the Picotool based one in P.IO) sends a special serial port sequence (1200bps connection) which causes the Pico to reboot into a ROM bootloader. That bootloader has a UF2 emulated memory stick interface, and a special picotool special binary upload interface. No serial ports.

[maxgerhardt]

//Serial.begin(115200);

Can you uncomment in the Serial.begin and retry? We rely on the reset-into-bootloader mode through the Serial.

If you can't upload the sketch, put the Pico in bootloader mode and copy the .pio\build\pico\firmware.uf2 once manually on its boot drive.

[fatherseye]

Hi Max, thanks for your interest in my problem.

I've already tried with and without the Serial.begin and when with, also with and without and the Serial.println. In all three cases, the sketch worked but upload still failed. Rebooting the device in bootloader mode and copying the firmware manually always works. I've been messing around with the Arduino IDE and platformIO and it would appear that there is something with the picotool download that is struggling with firmware generated by the new Arduino-pico framework.

1. The Arduino IDE upload always works regardless of whether how the running pico firmware was built.
2. The platformIO IDE upload only works if the firmware running on the pico was build by the stable arduino-pico framework. If the running firmware is from the new framework it hangs after the picotool triggered reset. This is true for the platformIO upload processes with both the new and stable ardunio-pico frameworks. The issue is how picotool is working with the new firmware.

Other than the ability to upload new firmware using platformIO everything about the new framework seems to work perfectly.

Both stable and new platform IO versions use the same version of rp2040load (1.0.1) which seems to just run picotool a number of times and picotool doesn't seem to work with the new firmware - (on my system at least).

I noticed that with the new firmware that the com port number of the device increased by 1. You can see in the upload output above that it changed from COM28 to COM29. Presumably this is indicative of the new bootloader firmware. I can see the following differences between the two versions of the port in device manager

com	Location (General tab)	Information (Events tab)
28	0000.0014.0000.010.000.000.000.000.000	Device USB\VID_2E8A&PID_00C0&MI_00\6&2d5dc608&0&0000 requires further installation.
29	Port_#0010.Hub_#0001	Device USB\VID_2E8A&PID_000A\E6605838838BAB2E requires further installation.

The only change is the firmware downloaded. COM 28 is the stable framework generated firmware, COM 29 is the new.

I'm not sure what the 'required further installation' thing is about since it says it is working properly.

I assume that this is just a problem I am seeing and that no one else has encountered it?

Is it worth trying a more recent version of the updated rp2040load and/or picotool? Is it possible to change the upload protocol since there seem to be other options? Do any of them work over a standard USB connection?

AVAILABLE: cmsis-dap, jlink, picoprobe, picotool, raspberrypi-swd

[earlephilhower]

No changes to the serial port code have happened in quite some time, and the UF2 generation hasn't been touched either.

The COM port can often change between runs with uploads between them at the whim of the OS, so you do always need to make sure you're using the right one to do the 1200bps tickle to reboot it. Under Linux, if I have a minicom or the IDE Serial Monitor open, I have a greater chance of needing to use a new devnode between FW uploads because the OS sees the old devnode is still in use by the serial monitor/app.

[fatherseye]

Since the Arduino IDE download mechanism works perfectly I can only assume it is something going wrong with reset, rp2040load or picotool.
The Arduino IDE uses a python script which is pretty straight forward compared to all that golang and c++ used by the official RPI stuff. It opens the com port at 1200baud and lowers DTR which I guess causes the pico to go into bootsel mode. Then the script checks for removable FAT filesystems. If it finds one it copies the provided UF2 file to it. Done and works!

rp2040load has been updated on the git site and from the help options reported it looks like the picotool is 1.0.1 which also has an update 1.1.0 version available which has a lot of changes. I'll see if the newer versions of rp2040load and picotool can fix my problem but I'm not a windows developer and always struggle to get stuff to compile. I'm not even going to attempt to compile the golang stuff on principle :)

I'll let you know if I make any progress.

[elral]

Since a couple of days I see the same behaviour. I am not 100% sure, but it seems that after updating the framework (first time since a couple of weeks) the upload process aborts as described above. I can see that the COM port is opened with 1200 baud to enter the bootloader, and I can also see that the COM port disappears in Windows, but the new COM port for the bootloader does not show up. But the Pico is in bootloader mode as the Pico drive shows up and the UF2 file can be copied successfull.

I will check this also on my PC (now working on my laptop) if it behaves the same.

/edit: It seems that I updated the framework on my PC beginning of August, and it shows the same behaviour. BUT I tried it with a second Pico and multiple uploads are working....

[maxgerhardt]

Can you try the alternative upload bootloader reset + copy UF2 to bootdrive method by setting

upload_protocol = mbed

in your platformio.ini?

[elral]

@maxgerhardt This way it is working.

In the meantime I have updated the framework on my PC, and now the second Pico can also not be updated with picotool anymore. For me there must have been something changed between the actual release and some (less?) weeks ago. Not sure but with the release from end of July or beginning August it was working.

[fatherseye]

Using mbed as an upload protocol did the trick and mean's I can use it going forward which is awesome! Thanks Max!

In the meantime I'm now convinced it is the picotool that is broken with the new firmware that we're flashing. When I run it on a device built with the stable framework I get this...

PS C:\Users\steve\.platformio\packages\tool-rp2040tools> .\picotool.exe info -a 
Program Information
 none

Fixed Pin Information
 none

Build Information
 none

Device Information
 flash size:   2048K
 ROM version:  2

It looks like it's happy. If I try it with the same device with the newly build firmware using the new framework I get:

PS C:\Users\steve\.platformio\packages\tool-rp2040tools> .\picotool.exe info -a
Assertion failed: this_size, file /__w/rp2040tools/rp2040tools/picotool/main.cpp, line 809

I notice that picotool is in packages/rp2040tools so is common to both old and new frameworks. There is no command line option to get a version for it but looking at github 1.0.1 has an assert on line 809 and version 1.1.0. It appears that there have been significant changes to the tool.

Maybe we need to get an updated version of it which might fix the problem.

In the meantime I have a working platformIO and I'm as happy as a happy thing.

[maxgerhardt]

The picotool version used (1.0.2) is currently outdated (newest 1.1.0). Since https://github.com/raspberrypi/picotool/releases doesn't provide binary releases for all the OSes, I'll have to come up with a way to use the Gitlab CI to compile and package everything. Maybe updating this will fix these issues with newer firmware versions, I'm on it.

[earlephilhower]

I have a suspicion about this.

There is a structure in flash that's supposed to list the resources used by the binary (I'm not really sure why you'd ever want to do this, but I'm sure it made sense to someone).

I have a feeling that the OTA binary, which is now part of all applications, is confusing picotool and it's just completely pooping its pants instead of just uploading the bytes in the .BIN. OTA effectively needs to have not one but two separate applications in flash. The ROM jumps to the OTA app which checks for updates and then jumps to the user app. Might have 2 copies of this magic "I'm using XXX" struct.

Let me dig into this, now that I have a clue...