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.
I having problems with the upload on Lubuntu20.04
While the picotool detects and reset the Pico automatically on /dev/ttyACM0, it is not able find the flash-volume which appears on my machine at /media//RPI-RP2.
When I follow the suggested solution and add upload_port=/media//RPI-RP2 to the platformio.ini, the picotool fails as is trying to reset /media//RPI-RP2 instead of /dev/ttyACM0
The use of of âupload_portâ for both the volume_name and the serial port seems to be wrong.
I found my way around the problem by using a custom upload script.
Itâs available on GitHub - wurmtal868/PicoLoad
You were close. This worked for me (also on ubuntu 20.04):
pio run --target upload -e pico --upload-port /dev/sda1
Where /dev/sda1 was the device associated with the /media/RPI-RP2 mount point.
However beforehand I had to press the reset button prior to plugging the pico in.
I really appreciate your comment here.
I had such an hard time to solve the issue and found out that pico is preset to be used with raspberry pi computer⌠which is not what most people do for a big project.
Just after I re-install the usb driver and make the board into BOOTSEL mode then specify the upload port manually, I could finally upload the file into my lovely pico.
Thanks LOL~!
FYI: I use the following code in my Pico Arduino sketches to solve the issue that SDA and SCL are not defined for the RPi Pico board (not sure if it has been fixed in a more recent version of the RP2040 Arduino Core):
#ifndef SDA
#define SDA PIN_WIRE_SDA
#endif
#ifndef SCL
#define SCL PIN_WIRE_SCL
#endif
Just logged in to tell you about a bug that Iâve found in [maxgerhardt/platform-raspberrypi: Raspberry Pi: development platform for PlatformIO (GitHub - maxgerhardt/platform-raspberrypi: Raspberry Pi: development platform for PlatformIO)
Btw, super job implementing picoprobe support, Max!
After a wild goose chase (a few hours lost), thinking there is some kind of hardware issue with my picos (a picoprobe and a target), libusb driver issues,etc , eliminated all that by using pyocd succesfully to both program and debug with my setup.
I then started reading through platformio framework, to see how a platform comes together how a build process is defined, etc.and found the culprit.
My problem was during upload. This was the output:
ploading .pio\build\pico_arduinocore_mbed\firmware.elf
Open On-Chip Debugger 0.10.0+dev-g14c0d0d-dirty (2021-01-27-15:43)
Licensed under GNU GPL v2
For bug reports, read
debug_level: 1
Warn : Transport "swd" was already selected
adapter speed: 5000 kHz
target halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00
target halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00
** Programming Started **
Warn : no flash bank found for address 0x20000000
Warn : no flash bank found for address 0x200114b8
** Programming Finished **
** Verify Started **
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0000012a msp: 0x20041f00
Error: checksum mismatch - attempting binary compare
embedded:startup.tcl:530: Error: ** Verify Failed **
in procedure 'program'
in procedure 'program_error' called at file "embedded:startup.tcl", line 591
at file "embedded:startup.tcl", line 530
*** [upload] Error 1
After doing a verbose debug, I saw that there is an offset argument with the openocd call that shouldnât be there, not with elf anyway.
So I dig trough the source ./builder/build.py and at starting at line 384 : I modified
from
board.get("upload.offset_address", "0x10000000")
to
board.get("upload.offset_address", "")
Because of the logic selecting elf or firm (bin), we need to default to no offset because we already defaulted to elf a few lines below when no offset is needed (i.e board_upload.offset_address is not set in platformio.ini file)
Everything works as expected now.
@maxgerhardt, I already updated in my own repo fork (GitHub - dlbogdan/platform-raspberrypi: Raspberry Pi: development platform for PlatformIO), and made a pull request.
Regards,
Bogdan