Thanks @maxgerhardt , I setup the driver with Zadig and now the upload works. I am not sure why a special driver is needed since the Pico boot mode emulate a disk and requires a simple file copy but there must me a reason.
My next step before starting the application’s is to setup a hardware debugger. Anything that works, a Pico as a debugger or a commercial one if it’s not way way expensive. Is such a platformio/pico compatible debugger available?
Currently, PlatformIO doesn’t support Pico debugging via jlink or stlink. However, it may be able to support a Picoprobe.
The SEGGER driver for a J-Link probe (e.g. Edu Mini) already supports the Pico. You can debug a Pico elf file using a SEGGER J-Link probe & Ozone debugger.
Also, I have debugged the Pico using a Picoprobe with PatformIO Debugger, building with cmake extension. You can use either another Pico (or a Raspberry Pi) as a hardware Picoprobe (see https://datasheets.raspberrypi.org/pico/getting-started-with-pico.pdf).
With a Picoprobe, you’ll need to build OpenOCD with the Picoprobe driver, as detailed in the above link.
Thanks @zpm1066, I think I will wait for a more out-of-the-box platformio debugger for the Pico.
What is a good place to track progress? Is there a thread or an issue to discuss the debugger?
There were several mentioning here about the pain of entering the Boot mode so here is a solution that works for me with my dev Pico board. Clicking on the left button enters the boot mode and clicking on the right button enter the run mode (board reset), everything else works the same.
The tricky part is connecting to the BOOTSEL signal. I did by soldering to the onboard BOOTSEL switch.
Principle of operation: The resistor and the diode are to decouple the BOOTSEL signal which also acts as an output and has transitions during the operation of the board from the RUN input. The capacitor is used as a differentiator, issuing a short RUN command when the BOOTSEL is pressed.
If you try it, please post here how it works for you.
(Note: the wiring on the other side of the board is not shown)
It helps to read other users’ posts…
This was already mentioned not far above.
Pico debugger related issues can be tracked in the following thread.
With regard to the BOOTSEL/RESET with the standard Raspberry Pi Pico board, there isn’t really a need to perform any soldering. Just connect a switch to the RUN pin and a GND pin.
To enter the BOOT mode, connect the Pico to a Mac/PC USB port. Hold down the BOOTSEL, then press & release the RESET, and release the BOOTSEL. RPI-RP2 volume will get mounted onto the desktop.
To enter the BOOT mode, connect the Pico to a Mac/PC USB port.
Hold down the BOOTSEL, then press & release the RESET, and release the BOOTSEL.
Thanks @zpm1066 .
That was the goal of my ‘design’ to replace that procedure with a simple click. 
Some STM32 boards have these two buttons next to each other which allows to enter BOOT mode with a rolling finger maneuver.
Hi all, I have a few question few questions regarding platformio/pico. Will post them here to avoid spamming with another thread. Please let me know if I should take them somewhere else.
Is https://github.com/Wiz-IO/wizio-pico ahead of the official platformio/pico when it comes to debugger support? Worth trying?
I tried to run the second core but could not include “pico/multicore.h”. Will the dual core feature be supported?
Any idea how to make the Pico’s printf() directed to Serial? On some environments all it takes is implementing a putc(char) function or similar but not sure how it’s done with the pico?
gpio_set_mask() and gpio_clr_mask() do work but gpio_set_dir_out_masked() doesn’t seem to set the pins as outputs. Any idea why?
gpio_set_dir_out_masked(1 << LED_BUILTIN | 1 << LED1_PIN | 1 << LED2_PIN | 1 << LED3_PIN);
I was getting many warning during build (not from my code) and had to add this flag to suppress them build_flags = -Wno-ignored-qualifiers. Is this a known issue?
Is the compilation of the Pico framwork significantly slower than that of STM32 or I just imagine it?
The implementation is called arduino-mbed. Why are they combined? Does it provide both Arduino and mbed APIs?
BTW, I was able to implement a continuous acquisition program with two analog inputs and alternating DMA buffers and it was significantly easier than with STM32, so I expect this platformio/pico combination to be a winner. Thanks for everybody that makes it happen.
I2C compilation issue:
I fixed the issue with I2C (‘OLED display’):
Strange enough SDA and SCL are not defined in the Arduino-embed core.
I used definitions I2C_SDA and I2C_SCL instead which are defined in the BSP but they could not be resolved during compilation. I now use the PIN_WIRE_SDA and PIN_WIRE_SCL definitions instead which works fine:
#ifndef SDA
#define SDA PIN_WIRE_SDA
#endif
#ifndef SCL
#define SCL PIN_WIRE_SCL
#endif
Compilation issues caused by include file named “pico.h”
My other issues with Arduino framework and Raspberry Pi Pico have also been solved:
I got many errors during compilation of which I did not understand what was causing them. It appeared to be an include file in my application called pico.h with include guard #ifndef PICO_H_. It turned out that the Arduino-embed core uses an include file with exactly the same name and same header guard.
Changing only the name of my header guard proved to be insufficient, even while I explicitly included my pico.h file from a specific folder. I had to rename my own pico.h include file to something else (and rename the header guard accordingly).
After this my problem was solved and the code compiled successfully.
The Arduino-mbed core for the raspberrypi (RP2040) platform has now been upgraded to v2.1.0.
A number of RP2040 bugs have been fixed, https://github.com/ARMmbed/mbed-os/pull/14488/commits.
Run pio platform update raspberrypi from the PlatformIO command line to upgrade the Arduino-mbed core.
I have problems with uploading to the Raspberry Pi Pico. When I use the command ‘run -t upload’ I get an error.
But then the Pico appears as a USB connection RPI-RP2 and I can copy the file build/pico/firmware.uf2 to this map, it disappears and it works then fine. I use the following platformio.ini:
[env:pico]
platform = raspberrypi
board = pico
framework = arduino
I have tried several suggestion here, but it did not help.
When performing the upload, Did you place the Pico into the bootloader mode by holding the BOOTSEL button down before and during USB insert?
No, I didn’t push the BOOTSEL button down.
You need to place the Pico into the bootloader mode prior to any upload.
I know to upload a program by first entering in the bootloader mode. But this is somewhat inconvenient as my pico is part of a system that I hope to run on a raspberry pi zero with a remote ssh connection. I solved this by using two gpio’s of the rpi and connect them with the tp6 and the run pin on the pico. Then I could pull these pins down in the right order and get into the bootloader mode using software.
I had hoped this would no longer be necessary when using the platformio software and that I simply could upload using the ‘platformio run -t upload’ instruction. Now I can solve this using a shell script that first tries to upload with the platformio run -t upload instruction, wait until the bootloader is started and then use a copy instruction that copies the firmware.uf2 file to the USB port RPI-RP2.
But it was my hope that this was not really necessary since upload works fine with the other modules I tried (arduino nano, seeeduino xiao, nodemcu,).
Once you’ve uplaoded the first Arduino sketch, manual reset is not necessary anymore as it’s being handled by a 1200bps serial port touch to reenter bootloader mode.
I don’t understand this.
When I do a ‘pio run -t upload’, this is what I receive:
Configuring upload protocol…
AVAILABLE: cmsis-dap, picotool, raspberrypi-swd
CURRENT: upload_protocol = picotool
Looking for upload port…
Auto-detected: /dev/ttyACM0
Forcing reset using 1200bps open/close on port /dev/ttyACM0
Uploading .pio/build/pico/firmware.elf
rp2040load 1.0.1 - compiled with go1.15.8
…
*** [upload] Error 1
============================= [FAILED] Took 13.06 seconds ========================
While this is going on, the USB connections open: RPI-RP2 .
Then I can copy the file
.pio/build/pico/firmware.uf2
to the USB port and then the program starts to run.
Unfortunately this does not work correctly.
I had it working a few times (Windows 10), but most of the times it just doesn’t work and I have to put the board in BOOTSEL mode first.
I’m not sure if this is related to using serial over USB for the serial monitor, or not.
For those who are experiencing the same problem:
I added (soldered) a reset button (example(s) can be found on Youtube) to one of my Pico’s that I use for development .
This makes it possible to put the board in BOOTSEL mode without having to unplug and replug the USB and without screwing up any active serial monitor connection.
When uploading, as soon as the text ‘uploading’ (or something similar) appears, then press and hold the BOOTSEL button, then press and release the reset button and then release the BOOTSEL button again. The drive will then appear and uploading will start (and after the upload an existing serial monitor session will just continue).
On Windows I do have to specify upload protocol and upload port (drive) as described further above, otherwise upload will not work at all.
I would rather prefer that upload always works automatically, without manual intervention every time/most of the times.
Without a reset button added (which the Pico unfortunately does not come with) having to unplug and replug USB before every upload (which also rudely aborts any active serial monitor session) is a real PITA.