Also interesting potential conflict: picotool sees Program Information none when in BootSel mode, but unplugged and replugged the Pico2 back in after and it is the same disconnect/ reconnect behaviour as yesterday.
Hi Kevin,
One final update for now - I tried plugging the flashed Pico2 into a Pi400 and it exhibited similar connect/ disconnect cycles in dmesg as before.
I went through the same install and flashing steps on the Pi400 and the result is again the same, several connect/ disconnect cycles and nothing shows up in ls.
Iām sorry, Iām not sure what more I can try or how to get past this issue.
Would you like me to ship you some of this hardware? (I assume you are in the US?)
I could send you the misbehaving Pico2 and also I can solder up one of these RP2350B Stamp XL on a carrier board, like in this pic. That way you can test and dev for yourself.
The RP2350 was announced as being available in volume by the end of the year. It looks like the form for requesting early samples was recently taken down, presumably in preparation for that.
2 Likes
I was able to reproduce this error locally. But only if I compile the code on older versions of gcc. Specifically, arm-none-eabi-gcc (15:8-2019-q3-1+b1) 8.3.1 20190703 (release) [gcc-8-branch revision 273027] and arm-none-eabi-gcc (15:7-2018-q2-6) 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907] show the problem. However, arm-none-eabi-gcc (Fedora 14.1.0-1.fc40) 14.1.0 does not show the problem.
Can you recheck if the binary I uploaded before works on your boards?
sudo ~/klipper/lib/rp2040_flash/rp2040_flash /path/to/kevins/klipper.uf2
Iām still tracking down why the older versions of gcc are not working. Itās reproducible across different Kconfig options and gcc optimization levels.
-Kevin
2 Likes
After further testing, it seems the error only occurs with older versions of gcc when using USBSERIAL mode - I donāt see the error when compiling for UART.
It looks like something on older versions of gcc, somewhere in the USB code, causes an unhandled event of some kind, which causes the DefaultHandler() code to run, which results in the watchdog triggering, which causes a reset loop. I have not yet tracked down the actual root cause.
-Kevin
1 Like
I was able to track down the problem with older versions of gcc. It seems various versions of newlibc may deploy a memcpy() implementation that emits unaligned memory accesses. Thus it is not valid to call memcpy() on the USB device ādpramā memory (as that memory area does not support unaligned accesses).
I have made that fix to the rp2040/rp2350 support.
I have also committed the rp2350 support to the main Klipper repository ( Add support for rp2350 micro-controllers by KevinOConnor Ā· Pull Request #6725 Ā· Klipper3d/klipper Ā· GitHub ).
-Kevin
2 Likes
Hi Kevin,
I believe we have success:
I grabbed a new Pico2 so I will try this with previously used hardware later.
This is using the current klipper/master and just the basic commands set, including USBSERIAL.
Thank you so much for your diligence in tracking down this truly weird issue.
-Ray
1 Like
Hi Kevin,
Quick question as I could not tell from reading the new commits, have you added support for the RP2350B IC? As in, can I try to configure the higher GPIO pins and use the ADC pins on the B chip with the current code?
Thanks!
Ray
No - the current code only supports the first 30 gpio pins. As I understand it, it should be possible to bootup an RP2350B chip with the current code, but gpios>30 wont work and neither will any of the adc pins.
If you (or someone else) has access to an RP2350B and are willing to run tests, then I can probably send over development code. If interested, verify the current code flashes and boots with the current code, and then attach the full klipper log here.
Cheers,
-Kevin
Here is the RP2350B dev board I have.
I have successfully flashed the new firmware to it and see it with the ls command:
It will take me longer to get set up to run tests. Assuming you are in the US, would you like me to ship you this hardware so you can play for yourself? Iād be happy to do it, feel free to DM me.
-Ray
1 Like
Hey @koconnor im trying to use a RP2350 feather from adafruit whenever i make flash it says it finished fine but it disconnects and never reconnects
Iām working on a motherboard for Klipper based on the RP2350B (RP2040 doesnāt have enough IO pins). Is there support for pins GPIO 31+ on the RP2350B?
No change since Support for rp2350 micro-controllers - #29 by koconnor . It doesnāt look too hard to add code for the rp2350b additional gpio, but code would be needed.
Cheers,
-Kevin
2 Likes
What can be my Problem?
Klipper is up to date. RP 3b with Pico2.
i see a difference in the number of Pages displayed.
Are you sure you actually build the firmware for the RP2350?
Hi,
i have been getting the same error (No rp2040 in BOOTSEL mode was found) while trying to flash rp2350. For some reason the autodetect of rp2350 isnāt working.
miko@octoprint:~/klipper$ sudo lib/rp2040_flash/rp2040_flash out/klipper.uf2
Loaded UF2 image with 153 pages
No rp2040 in BOOTSEL mode was found
But if you manually specify the bus and address is does work
miko@octoprint:~/klipper$ lsusb | grep RP2350
Bus 001 Device 028: ID 2e8a:000f Raspberry Pi RP2350 Boot
miko@octoprint:~/klipper$ sudo lib/rp2040_flash/rp2040_flash out/klipper.uf2 1 28
Loaded UF2 image with 153 pages
Found rp2040 device on USB bus 1 address 28
Flashingā¦
Resetting interface
Locking
Exiting XIP mode
Erasing
Flashing
Rebooting device
miko@octoprint:~/klipper$ lsusb | grep rp2350
Bus 001 Device 029: ID 1d50:614e OpenMoko, Inc. rp2350
Hope it helps.
Hello, I hope it will be fine to post in this topic. Iām trying to use RP2354 with integrated flash on my custom board. When I load the hello_world usb example from pico sdk it works perfectly fine and serial comm is working. However after loading klipper the usb communication canāt be estabilished anymore.
My makemenuconfig:
$ sudo make flash FLASH_DEVICE=2e8a:000f
Flashing out/klipper.uf2 to 2e8a:000f
sudo lib/rp2040_flash/rp2040_flash out/klipper.uf2
Loaded UF2 image with 152 pages
Found rp2040 device on USB bus 1 address 49
Flashingā¦
Resetting interface
Locking
Exiting XIP mode
Erasing
Flashing
Rebooting device
But after that dmesg shows:
[ 3655.982120] usb 1-2.2: Device not responding to setup address.
[ 3656.186100] usb 1-2.2: Device not responding to setup address.
[ 3656.390063] usb 1-2.2: device not accepting address 77, error -71
[ 3656.390238] usb 1-2.2: WARN: invalid context state for evaluate context command.
[ 3656.390288] usb 1-2-port2: unable to enumerate USB device
[ 3656.706090] usb 1-2.2: new full-speed USB device number 78 using xhci-hcd
[ 3657.098101] usb 1-2.2: device descriptor read/64, error -71
[ 3657.698104] usb 1-2.2: device descriptor read/64, error -71
[ 3657.990088] usb 1-2.2: new full-speed USB device number 79 using xhci-hcd
[ 3658.410111] usb 1-2.2: device descriptor read/64, error -71
[ 3659.122119] usb 1-2.2: device descriptor read/64, error -71
[ 3659.226308] usb 1-2-port2: attempt power cycle
Iām also not sure, but some things were fixed in pico sdk 2.2, and Iām not sure if klipper is already using that SDK.
I donāt recall seeing anyone confirm the rp2354 in particular, but I also donāt know of any reason it would not work. As far as I know, the rp2354 is basically the rp2350 with a flash chip in the same package.
Is this the rp2354b or the rp2354a?
You could try flashing using picotool as mentioned earlier in this thread at Support for rp2350 micro-controllers - #16 by koconnor
-Kevin
Iām really tight on my prototype toolhead board, thatās why I was happy with the RP2354, as it doesnāt require additional flash. But I also assumed that it will work somehow, as rp2350 support was added.
picotool complains about the uf2 image, because the elf2utf is outdated and not putting correct chip to uf2, so Iām using make flash, which works. Iāve spent some hours moving around few lines of code which are blinking the LED for me, but nothing really conclusive.
Iāve disabled watchdog, so that the board stop resetting all the time. With LED blinking I managed to trace, that the code executes well until ctr_run_initfuncs(), this one I have no idea how to debug inside, but I donāt think that is relevant.
Usbserial_init goes through, but when I add led blink to USB_handler (trying to catch on the interrupts), the led doesnāt blink, and now Iām completely lost 
After commenting out the watchdog, Iām getting additionally new errors -110 and -62, but these are just timeouts I believe.
It is RP2354A.