Is there a specific board we can use for the new pico 2 based on rp2350 ?
2 Likes
I’m still working out the kinks for supporting it, so I wouldn’t recommend using it just yet, but it’s a work in progress.
- Enable Win32 Long Paths and Git long paths: docs.
- Create a new project for an Arduino Uno, Framework = Arduino
- Overwrite the
platformio.iniwith
[env:rpipico2]
platform = https://github.com/maxgerhardt/platform-raspberrypi.git#rp2350_picosdk
board = rpipico2
framework = arduino
1 Like
In case anyone is having trouble with the Pico 2, there is a hardware bug which occurs when any of the GPIO pins enable the internal pull down resistors.
After the first read of the pin state, the pin is constantly held low so you can never read it correctly again!
Details on You Tube https://youtu.be/sqJQNF9snaE?si=EEpHAGH-liy_DBlJ
Cheers,
Norm.
I’ve gone through the instructions here. I was able to get it to work with a Raspberry Pi Pico W, but not with the Sparkfun Pro Micro RP2350. The PlatformIO output says that board isn’t supported.
My test case is rather complicated - is there something simpler that works with the SparkFun board, or am I just waiting until the software catches up with that board? The board does work with the Arduino CLI using the 4.0.1 release of arduino-pico.
Are you using the rp2350_picosdk branch as I have mentioned above?
[env:sparkfun_promicrorp2350]
platform = https://github.com/maxgerhardt/platform-raspberrypi.git#rp2350_picosdk
board = sparkfun_promicrorp2350
framework = arduino
exists just fine. The current documentation does not reference this branch because it’s just a work in progress.
Again, I hope to merge this back into main shortly, after PicoSDK framework support is completed.
I was copying what I saw in the Arduino-Pico docs - I’ll try it with this and see what happens. I have a couple of other RP2350 boards - the two Invector Labs one and the Pimoroni Pico Plus 2 that I can also test if the SparkFun board works.
By the way, my test case is something useful (to me, anyhow) - Mitch Bradley’s cforth.
I have the SparkFun board working!! I am running in a container and I had some issues with connecting for upload, but putting the board in BOOTSEL mode enabled the upload. I’m about to hunt down the dependencies so I can run on the Fedora Silverblue host.
I can probably hack the PlatformIO udev rules for the new boards that I have if you’re interested in a pull request. I have my own udev rules that are quite insecure - I just allow everyone to read and write the device.
I have the Silverblue testing set up and I have a bit more info on the upload issue. The stock PlatformIO udev rules are installed, and at the moment it looks like both the Pico W and the Pro Micro RP2350 have the same vendor/product code:
❯ lsusb
Bus 001 Device 027: ID 2e8a:000a SparkFun ProMicro RP2350
Bus 001 Device 028: ID 2e8a:000a Raspberry Pi Pico W
❯ ls -l /dev/ttyACM*
crw-rw-rw-. 1 root dialout 166, 0 Sep 2 16:11 /dev/ttyACM0
crw-rw-rw-. 1 root dialout 166, 1 Sep 2 16:11 /dev/ttyACM1
The SparkFun value is a bit of a surprise to me - when I was testing on the same board with some different software it was 1b4f:0026! Something must have over-written that code in the board.
Now on to the upload issue - this is the log from the Pico W test:
<lambda>(["upload"], [".pio/build/test_pico_w/firmware.elf"])
AVAILABLE: blackmagic, cmsis-dap, jlink, pico-debug, picoprobe, picotool, raspberrypi-swd
CURRENT: upload_protocol = picotool
BeforeUpload(["upload"], [".pio/build/test_pico_w/firmware.elf"])
TimeoutError: Could not automatically find serial port for the `Pico W` board based on the declared HWIDs=['2E8A:F00A', '2E8A:F00A']
TimeoutError: Could not automatically find serial port based on the known UART bridges
Auto-detected: /dev/ttyS31
Forcing reset using 1200bps open/close on port /dev/ttyS31
"/var/home/znmeb/.platformio/packages/tool-picotool-rp2040-earlephilhower/picotool" load -v -x .pio/build/test_pico_w/firmware.elf
Loading into Flash: [ ] 0%
Loading into Flash: [ ] 1%
Given that the IDs don’t match, the only mystery to me is why the search over “known UART bridges” didn’t find the board at /dev/ttyACM0 and why it thought it was at /dev/ttyS31, which to my knowledge isn’t connected to anything.
I’m going to see if I can get picotool to put the correct vendor/product codes into the boards and try this again.
FYI, the rp2350_sdk branch is now deleted since https://github.com/maxgerhardt/platform-raspberrypi/pull/72 was merged into mainline. Please delete C:\Users\<user>\.platformio\platforms\raspberrypi* and do a new build.
Right, actually the SparkFun ProMicro RP2350 is supposed to have that too but the VID:PID list is currently in the wrong order; The regular “Pico” VID/PID appears first. I’ll fix that in the platform. Reverse the order of these elements in the array and the VID/PIDs will be fixed.
Pico W upload works fine, just tested by me. Note that for the very first upload, you have to put the Pico W into BOOTSEL mode. The auto-detetecd COM port will be wrong, but picotool should upload it just fine. After that, the autodeteced COM port should be right again (if you didn’t upload a crashing firmware), so that reboot into BOOTSEL mode can be made via the COM port (1200bps tty touch).
@maxgerhardt thanks for the great work.
I just tested our firmware with the Pico2, everything seems to work (incl EEPROM emulation).
I am just wonderung why the Pico2 shows up with the same VID/PID as the Pico (VID_2E8A&PID_000A) whereby in the json file "usb_vid": "0x2E8A","usb_pid": "0x000F"is defined (here).
I see also the generic_rp2350 board. The RP2350 is available at least in a A and B variant with different amount of pins. Wouldn’t it make sense to have two generic boards for both variants? Or is this from your side not required? I already gave this comment to Earle (here)
We need to fix this is in the makeboards.py to not unconditionally give the VID/PID for Pico here. Cosmetic. Will be fixed.
Let’s discuss that in that discussion thread. My current idea would be to just have two precompiled Pico-SDK versions, one for A, one for B variant. That is of course, if we can even guarantee that a e.g. “Sparkfun RP2350 Micro” board will always come with rev A or rev B… might need to actually query the chip at runtime to be correct…
We need to fix this is in the
makeboards.pyto not unconditionally give the VID/PID for Pico here. Cosmetic. Will be fixed.
Great!
Let’s discuss that in that discussion thread. My current idea would be to just have two precompiled Pico-SDK versions, one for A, one for B variant…
I am fine with this, but most likely not a big help as I don’t understand why two different precompiled Pico-SDK versions are required. But this is OK 
Hi, I have done a git pull to update the project and tried rebilding for rpipico2 platform, I get this:
Executing task: platformio run --environment rpipico2
Processing rpipico2 (platform: https://github.com/maxgerhardt/platform-raspberrypi.git; board: rpipico2; framework: arduino)
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/raspberrypi/rpipico2.html
PLATFORM: Raspberry Pi RP2040 (1.13.0+sha.1ab176c) > Pico 2
HARDWARE: RP2350 150MHz, 512KB RAM, 4MB Flash
DEBUG: Current (blackmagic) External (blackmagic, cmsis-dap, jlink, pico-debug, picoprobe, raspberrypi-swd)
PACKAGES:
- framework-arduinopico @ 1.40001.0+sha.6a5f98c
- tool-picotool-rp2040-earlephilhower @ 5.120300.240818 (12.3.0)
- toolchain-rp2040-earlephilhower @ 5.120300.240125 (12.3.0)
Flash size: 4.00MB
Is this correct? It builds ok, but I am not sure from the above if it has built for rp2040 or rp2350.
My platformio.ini is this:
[env:rpipico2]
platform = https://github.com/maxgerhardt/platform-raspberrypi.git
board = rpipico2
framework = arduino
The “HARDWARE” line counts. Yes, all the toolchain and tool names still have “rp2040” in them, but they’re also used for RP2350.
Great Thanks. The code runs fine on an rp2350 board.
Will you be adding support to build for the riscv cpu’s at all?
Thanks.
PS: One thing I notice, I have to press the BOOT0 button for each upload, not just the first time …
…then we have a bug somewhere, because the automatic “1200bps serial port touch to relaunch into BOOTSEL bootloader mode” should be working. I’ll look into it.
Yes. At least 2x ARM-Cortex-M33 and 2xRISCV/Hazard3 RV32IMAC builds will be support. It all just needs time.
1 Like
Great. Another question. What is the differences/benefits of your platformio plugin versus the pico SDK extension for VSC. They seem to do similar things, though not as streamlined as platformio …
I guess you mean https://github.com/raspberrypi/pico-vscode? My platform-raspberrypi fork can’t yet build for the native Pico-SDK framework, while that extension can do that (using the native CMake build system), so that’s that. Otherwise they seem similiar – not sure if it offers all the comforts of PlatformIO, such as automatic toolchain downloads, etc. I have never used the extension, just judging from the README.md.
Yes, that is correct. The pico VSC extension does automatically install the toolchain and SDK, picotool etc into ~/.pico-sdk. … FYI …
Just an FYI. I ran into the errata-E9 silicon bug on the RP2350.
The ADC’s will latch to 2.1v if driven with a voltage from a high impedance source (in my case it was 47k, changing to 1k fixed the issue) Otherwise it seems to work (I don’t have any IO that needs to be pulled down to fix the other cause of the lockup.)
Even had ZeptoForth running on it (as a side bar )