Support for rp2350 micro-controllers

Developers
1

I have been able to bring up an initial version of Klipper on the rp2350 mcu: GitHub - KevinOConnor/klipper-dev at work-rp2350-20241024
This code is in a very early state. It is likely only of interest to other developers actively working in this area of the code.

Note that the rp2350 has a serious hardware bug known as the “RP2350-E9 Errata”. As a result, I do not recommend using this chip at this time, as it doesn’t offer any significant advantages over the existing rp2040 chip. In brief, when the chip configures an input gpio in “digital read mode” it may alter the voltage of the incoming wire (instead of just measuring it). The chip is still interesting though, as the RPi Foundation is indicating that they will soon ship rp2350b chips with more GPIO pins and analog input pins - should they do that, those chips would likely offer a real-world advantage over the existing rp2040 chips. There is also hope that the RP2350-E9 errata will be fixed in later chips.

If one does wish to utilize an rp2350 in a 3d-printer today, then I recommend enabling a pullup on all digital inputs (eg, use ^gpioXX on all endstops, menu buttons, gcode_button, and tmcuart pins). All standard 3d-printer accessories should tolerate a pullup, and as I understand it that should mitigate the errata.

Early benchmarks are indicating that the rp2350 is going to be a top performer. I’m currently getting just over 4million steps per second with 1 stepper active (4167K 1 stepper; 2711K with 3 steppers). This would put it basically on par with the performance of the stm32f4 chips.

The code in the development branch above is in an early state. Known issues:

  • There is some kind of weird timing, cache flush, or similar error occurring that required me to add dummy_task() in order for USB to start properly. I still need to track this down. Fixed: Looks like the rp2350 needed a minor change to USB PLL frequency.
  • The chipid functionality has not been implemented. (So, all rp2350 devices show up as /dev/serial/by-id/Klipper_rp2350_12345-if00) Implemented.
  • It is not possible to enter the bootloader mode directly from Klipper. In order to enter the bootloader mode, one must manually press down the bootsel button and then plugin the USB wire. Once the rp2350 is in bootloader mode, one can use make flash FLASH_DEVICE=2e8a:000f to flash. Implemented. Regular make flash should now work.
  • I have not tested UART mode nor CANBUS mode. I have not tested ADC, SPI, nor I2C devices. These modes are compiling and there is good reason to suspect they will be supported with little additional code changes.
  • Only the first 30 GPIOs are supported. Support for the additional GPIOs on the rp2350b has not been added (nor support for ADC in general on the rp2350b).
  • There are likely plenty of bugs.

Cheers,
-Kevin

EDIT: Note only first 30 gpios supported.

4 Likes
2

Thanks for the feedback. I want to use it as a support board for digital sensors and analog input. I have been working on a filament dia, run out, and motion all in one.

Is any work going on for this with Katapult?

3

I’m sure it is possible to port Katapult to the rp2350, but I haven’t looked at it. I don’t know of anyone currently working on that, but I’ve only been looking at the rp2350 for a few days myself.

Cheers,
-Kevin

4

is this relevant? it looks like serial number handling on a RP2040

5

To my knowledge the RP2350B shipped at the same time as the RP2350A? I know several people who got samples back in August, and products like the RP2350 Stamp XL are available for purchase.

6

RP2350A and RP2350B, same die but different packages (see https://datasheets.raspberrypi.com/rp2350/rp2350-datasheet.pdf)

RP2350 Stamp XL

IMG_0011_1
IMG_0011_1960×640 106 KB

…RP2350B on a PCB for personal developments.

7

Okay, thanks. The “Pico 2” board was readily available, and so I bought some for testing. I did not realize that the rp2350b was also actively shipping. I’m not planning to buy additional test boards at this time, but if someone with a rp2350b test board is willing to run tests, I’m sure we can get code working to support the additional gpio pins.

Cheers,
-Kevin

1 Like
8

You may read Accurate frequency & timing measurement on the Pi Pico RP2040 or Pico2 RP2350 using Python – Lean2 and picofreq/pico_devices.py at main · jbentham/picofreq · GitHub

@jbentham explains very clear :+1:

9

Hi Kevin,

I have not yet seen the RP2350B raw IC available for sale publicly via any distributors, but clearly OEMs like arturo were somehow able to get their hands on some for a small production run. I just received some of that RP2350 Stamp XL which uses the RP2350B chip as shown above. As far as the testing, are we just at the point of having it drive some motors and making sure nothing goes too wrong?

-Ray

10

The rp2350a chips should have pretty good support now with the code at the development branch listed above. So, getting general test feedback would be great.

As far as I understand it, the rp2350b chips should boot up on the code linked above. However, as I understand it, ADC wont work and one wont be able to use pins above GPIO30. If someone has that chip, it would be good to see test results that show that it is booting and working for digital pins GPIO30 and under. If one can verify that, I should probably be able to put together additional test code for ADC and GPIO31+ for the rp2350b (though that might be a week or so out).

Cheers,
-Kevin

11

Hi Kevin,

I have been at this for the past 2 hours, so please forgive any noob sounding questions because I want to find out if I am doing something stupid simple wrong.

TL;DR is that I tried to compile a UF2 file for the RP2350 and it will not take/ flash.

Here is a basic set of steps I took:

  • Used KIAUH to install mainline Klipper onto a Kubuntu desktop, cuz why not.

  • Separately, I git cloned the above klipper-dev repo into a different directory, and git switch to the work-rp2350-20241024 branch.

  • I tested the process with an SKR Pico by following the start of this guide: SKR Pico Klipper Firmware | Voron Documentation
    I compiled for the RP2040 and was able to successfully flash the SKR Pico (drag UF2 file onto mounted drive, drive disappears, and we see the Klipper device with the ls command).

  • I change the Processor model to rp2350 in menuconfig:

    image
    image1889×322 44.3 KB

    I run make clean and make as usual.
    (pic will be posted separately)

I copy the klipper.uf2 onto the mounted drive, and it just stays there, the drive does not disappear. Also, if I unplug and replug the device, I am back to the blinking light from the code I had flashed on there before.

  • For reference, I have both that RP2350B dev board set up now and I also tried with a plain Pico 2 - both have same lack of taking the UF2 file behaviour.

Does anything here stand out as wrong to you, or do you have alternate steps I should try?

Thanks!
-Ray

12

image
image964×1355 270 KB

13

Alas, the rp2350 also suffers from errata RP2350-E10, which cripples flashing by copying a uf2 file to the flash drive. Try flashing by manually placing the rp2350 in boot mode (hold the bootsel button down while plugging the rp2350 in), and then flash with make flash FLASH_DEVICE=2e8a:000f. Make sure you are on the new work-rp2350-20241024 while running that command.

-Kevin

14

And lastly here is the pic of the STAMP XL on the carrier board I have set up. It’s pretty nifty!

image
image1920×1440 280 KB

(sorry for the multiple replies, I just registered for this forum and Discourse is limiting me to 1 embed per post - if you can up my trust level to TL1 would make life easier :slight_smile: )

15

Thanks for educating me on E10, as if E9 wasn’t bad enough…

Tried this several times on the Pico 2, and it does flash your way (yay!), but then ls will not see the device after.

image
image1920×1881 259 KB

Tried this several times, unplugged and replugged in the Pico 2 then ran ls again, and the SKR Pico still shows up via ls if I plug that in. So not sure what’s up here.

And I do confirm I am on work-rp2350-20241024 in the terminal instance I am doing all this in.

16

Alas, I’m not sure what is going on. My pico2 flashes okay.

Could you try flashing the Pico2 (unplug the pico2, hold the bootsel button, plugin the pico2, run make flash FLASH_DEVICE=2e8a:000f), and then unplug the pico2. Then in another window, run dmesg --follow, then plugin the pico2, and then report the output from dmesg here.

Another thing you could try is downloading and compiling picotool ( GitHub - raspberrypi/picotool ) and see if it is possible to flash with that tool. The two possible commands to try are picotool load out/klipper.elf and picotool load out/klipper.uf2. Note it is necessary to manually reboot after flashing with picotool (eg, picotool reboot).

Again, I’m not sure what the issue is.
-Kevin

1 Like
17

To start, the dmesg report shows that the device is flashed as Klipper, but appears to be disconnecting and reconnecting with a new device number each time.

image
image1878×2078 473 KB

This is still with a stock Pico2.

18

Same behaviour with the STAMP XL/ RP2350B, flashed same way as Pico2 previously:

image
image1913×2085 463 KB

Right now the constant is the computer I am using and the firmware file.

Does this suggest to us that the firmware has been loaded, and hopefully correctly?

19

That’s odd. It does seem like Klipper is successfully being flashed and is successfully running. At first glance, the log seems to indicate that as soon as Linux recognizes the device (ttyACM0: USB ACM device) the device reboots (USB disconnect, device number ..). I wonder if there is something on Linux connecting to the device and causing it issues (eg, see ModemManager and similar at Other Single Board Computers (SBC) apart from Raspberry Pis ). It would be odd that the rp2350 would be impacted and not the rp2040 though.

You could look to see if there is information in other logs (besides dmesg). Other available logs vary depending on OS (sometimes journalctl -f works, sometimes one can look in files in /var/log/).

You could try flashing the same code I’m using to see if maybe it is something in the compilation process.
klipper-rp2350.zip (26.5 KB)
Though that also seems an unlikely explanation.

-Kevin

20

image
image1352×1591 458 KB

Here is interesting output from picotool:

picotool load out/klipper.uf2
Family id ‘rp2040’ cannot be downloaded anywhere
ERROR: This file cannot be loaded into the partition table on the device

I got the same result when I tried to load the uf2 in your zip.

I think my next step is to reboot this computer and then try another computer/ actual Pi.