rp2040: Added rp2040 support. #45

sh83 · 2022-10-20T21:05:37Z

This PR add support for the rp2040 mcu. All of USB, CAN and UART communication interfaces are supported, but only USB was tested well. The most of the code was taken from klipper, pico sdk and canboot. The folder lib/ was taken from klipper as is, without modifications.
The existing code mostly was not unchanged, so no regress on other mcu is expected.
The companion PR Klipper3d/klipper#5844
I have added online comments to the non-trivial places.

Signed-off-by: Alex Malishev malishev@gmail.com

sh83 · 2022-10-20T21:23:10Z

src/generic/armcm_reset.c

@@ -9,10 +9,16 @@
 #include "board/irq.h" // irq_disable
 #include "board/misc.h" // try_request_canboot

+#if CONFIG_MACH_RP2040
+#define BOOTLOADER_START (CONFIG_RP2040_BOOTLOADER_START)


User bootloader should be placed just after boot2 block at START_FLASH+256 address. Simple CONFIG_FLASH_START & 0xFF000000 do not work here.

sh83 · 2022-10-20T21:25:21Z

src/rp2040/timer.c

+ ****************************************************************/
+
+void
+timer_setup(void)


timer from generic/timer.c do not work on cortex-m0+

sh83 · 2022-10-20T21:31:59Z

src/rp2040/rp2040_link.lds.S

+        _bss_end = .;
+    } > ram
+
+    _stack_start = CONFIG_RAM_START + CONFIG_RAM_SIZE - CONFIG_STACK_SIZE - 1024;


Magical "-1024" is really magical. _stack_start is used to place request key what should be preserved after reset. But rp2040 bootrom uses and of the ram to copy boot2(256 bytes) from flash and boot2 uses some stack on top of what. so ~300 bytes around CONFIG_RAM_START + CONFIG_RAM_SIZE are damaged by the boot process of the rp2040. That is why we shift stack by 1024 bytes.

sh83 · 2022-10-20T22:07:55Z

src/rp2040/Kconfig

+    default 0x10000000
+
+config APPLICATION_START
+    default 0x10004000


16kb is reserved for the bootloader. The current bootloader size is 5kb for usb, 7 kb for can.

Arksine · 2022-10-21T11:17:15Z

Looks like a good addition to CanBoot. Can you break this up into separate commits? Preferably, there would be separate a commits for:

Importing the source from Klipper
Modifications to the Klipper Source (its fine if this includes the addition of flash.h/flash.c)
Modifications to Canboot Source

I can be confident that Klipper's source is solid, so I just need to review the changes. This is much easier when I can review the diffs in each commit. Thanks.

sh83 · 2022-10-21T11:49:05Z

Thank you. You suggestions make sense. I will split pr into multiple commits.

Signed-off-by: Alex Malishev <malishev@gmail.com>

(https://github.com/raspberrypi/pico-sdk/tree/master/src/rp2_common/hardware_flash, https://github.com/raspberrypi/pico-sdk/tree/master/src/rp2_common/pico_bootrom) as is. Signed-off-by: Alex Malishev <malishev@gmail.com>

Signed-off-by: Alex Malishev <malishev@gmail.com>

Implemented canboot timer interface. Simplified chipid.c to use common flash interface. Signed-off-by: Alex Malishev <malishev@gmail.com>

Modified linker script and loader to load whole bootloader to the RAM. Removed whatchdog. Fixed gpio.c compilation. Signed-off-by: Alex Malishev <malishev@gmail.com>

Signed-off-by: Alex Malishev <malishev@gmail.com>

sh83 · 2022-10-21T20:50:39Z

I did cleanup of the pr as suggested.
The first and second commits contain direct imports from klipper and pico-sdk.
The last and before last commits contain modification of the common canboot code.

Please note what rp2040 flash do not support concurrent read end erase/program. So interrupt handlers are suspended during erase operation. It is not good for the software can driver we use. So I have changed linker script and startup file armcm_canboot.c to load whole bootloader to the RAM. This way we do NOT disable interrupts during flash erase and write.

sh83 · 2022-10-21T21:06:01Z

src/rp2040/rp2040_link.lds.S

    } > rom

    . = ALIGN(4);
    _data_flash = .;

    .data : AT (_data_flash)
    {
-        . = ALIGN(4);
+        . = ALIGN(128);


Actually ALIGN do not do anything, cause we are at the start of the ram anyway :)
Leaved it for the documentation purpose, cause vector_table should be 128 byte aligned.

sh83 · 2022-10-21T21:10:00Z

src/rp2040/rp2040_link.lds.S

-        _text_vectortable_end = .;
-        *(.text .text.*)
-        *(.rodata .rodata*)
+        KEEP(*(.vector_table_flash))


The only VectorTableFlash , ResetHandler and reset_handler_stage_two are executed from flash. reset_handler_stage_two moves everything to the ram.

sh83 · 2022-10-21T21:12:08Z

src/rp2040/rp2040_link.lds.S

        _data_start = .;
+        KEEP(*(.vector_table))


We copy vector_table to the RAM and update VTOR, so core could use it.

sh83 · 2022-10-21T21:15:31Z

src/rp2040/armcm_canboot.c

+    uint32_t count = (&_data_end - &_data_start);
+    for(int i = 0; i < count; i++) {
+        (&_data_start)[i] = (&_data_flash)[i];
+        barrier();


At this point it is not safe to call anything, cause we did not copied code yet. So barrier() here to prevent compiler from use memcpy and memset.

Signed-off-by: Alex Malishev <malishev@gmail.com>

sh83 · 2022-10-24T18:45:43Z

Added global CONFIG_BOOTLOADER_START to avoid idefs in the code. This is the same change as in klipper PR.

jtrmal · 2022-10-28T15:52:53Z

I tried this and I get the following error during make flash:

make flash FLASH_DEVICE=2e8a:0003
  Building rp2040_flash
gcc -c -Wall -ggdb -I../rp2040/ `pkg-config libusb-1.0 --cflags` main.c -o main.o
main.c: In function ‘main’:
main.c:177:46: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘size_t’ {aka ‘unsigned int’} [-Wformat=]
  177 |     fprintf(stderr, "Loaded UF2 image with %lu pages\n", image->num_blocks);
      |                                            ~~^           ~~~~~~~~~~~~~~~~~
      |                                              |                |
      |                                              |                size_t {aka unsigned int}
      |                                              long unsigned int
      |                                            %u
gcc -c -Wall -ggdb -I../rp2040/ `pkg-config libusb-1.0 --cflags` picoboot_connection.c -o picoboot_connection.o
gcc  main.o picoboot_connection.o `pkg-config libusb-1.0 --libs` -o rp2040_flash
  Flashing out/canboot.uf2
Loaded UF2 image with 21 pages
No rp2040 in BOOTSEL mode was found

I do however have the rpi connected:

pi@tri:~/CanBoot $ lsusb
Bus 002 Device 002: ID 090c:1000 Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.) Flash Drive
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 1d50:614e OpenMoko, Inc. stm32f446xx
Bus 001 Device 003: ID 1d50:606f OpenMoko, Inc. Geschwister Schneider CAN adapter
Bus 001 Device 005: ID 2e8a:0003 Raspberry Pi RP2 Boot
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

jtrmal · 2022-10-28T15:56:18Z

OK, resolved... I just have to flash via root/sudo. SORRY!

sh83 · 2022-10-28T17:36:00Z

@jtrmal Thanks for testing it.
I think instructions should be updated. One thing to note is sudo usage. Also flash should be erased before if no bootloader entry mode is defined(double reset or button). Will do it later.

Do it work well after all? What board do you use?

jtrmal · 2022-10-28T18:02:53Z

yeah, it looks like its working. I do have some issues that do not most probably correlate with the canboot but I tried to resolved them by using canboot (unsuccessfully). My board behaves ok after soft restart (i.e. staying on power but being restarted after flashing), but when I unplug and plug again, it is dead. I tried both CAN and USB and it still behaves the same. But I'm sure it's not can boot, was happening even before it. This is all just to explain why I'm not able to confirm with 100% certainty
I'm using SB2040

jtrmal · 2022-10-28T19:14:27Z

Things that were confusing for me:

not specifying the bootloader offset and related stuff
If I should flash the uf2 file

sh83 · 2022-10-28T19:30:19Z

Well, most low level parameters should be ok by default.
Recommended install procedure is following:

Boot into buildin bootloader mode - apply power with mode button pressed
Flash binary flash_nuke.uf2 (https://learn.adafruit.com/getting-started-with-raspberry-pi-pico-circuitpython/circuitpython) via mass storage method or via rp2040_flash
Wait a minute or two. Dyring this flash_nuke.uf2 will erase all flash
Boot into buildin bootloader mode again
Build canboot.uf2 and flash canboot.uf2 by the same method
Check usb or can bus - canboot should be up running and connected
Now it is possible to flash klipper.bin from my klipper pr. Bootloader option should be enabled in klipper menuconfig.
This should work given hardware is ok.

jtrmal · 2022-10-28T19:44:57Z

I will try to play with the flash-nuke thanks!

…

On Fri, Oct 28, 2022 at 3:30 PM Alex ***@***.***> wrote: Well, most low level parameters should ok by default. Recommended install procedure is following: 1. Boot into buildin bootloader mode - apply power with mode button pressed 2. Flash binary flash_nuke.uf2 ( https://learn.adafruit.com/getting-started-with-raspberry-pi-pico-circuitpython/circuitpython) via mass storage method or via rp2040_flash 3. Wait a minute or two. Dyring this flash_nuke fb2 will erase all flash 4. Boot into buildin bootloader mode again 5. Build canboot.uf2 and flash canboot.uf2 by the same method 6. Check usb or can bus - canboot should be up running and connected 7. Now it is possible to flash klipper.bin from my klipper pr. Bootloader option should be enabled in klipper menuconfig. This should work given hardware is ok. — Reply to this email directly, view it on GitHub <#45 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACUKYX2VZOCT52ELX5UWRD3WFQSVNANCNFSM6AAAAAARKRKOPU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

Signed-off-by: Alex Malishev <malishev@gmail.com>

sh83 · 2022-10-28T20:36:42Z

I have added option (enabled by default after make menucofig) to force bootloader entry before new application flashed. nuke_flash.uf2 (i.e. steps 2,3,4 above) is no longer needed.

jtrmal · 2022-10-29T13:49:50Z

Hi, I just went through the hoops and updated klipper and the canboot to @sh83's repo. Everything seems to work flawlessly. Update via CAN even without triggering the canboot via button also works. Didn't find smallest issue.
And the last commit ("flash-nuke") is super-useful.

sh83 · 2022-10-29T16:13:19Z

@jtrmal thank you for your feedback and testing. Really good news.

Arksine · 2022-10-30T14:37:38Z

Thanks. I have begun my review and overall it looks solid. I do have a few observations:

bootrom.c, hw_flash.c, and hw_flash.h look like library files, so I suspect they should be placed in lib/rp2040 somewhere rather than src/rp2040.
The deployer should have a build option rather than default to the application address.
With the 256 byte bootloader offset, we probably need to change the following block in deployer.c to use CONFIG_BOOTLOADER_START:

    // Check if flash has already been written
    void *fstart = (void*)CONFIG_FLASH_START;
    uint32_t cbsize = deployer_canboot_binary_size;
    if (memcmp(fstart, deployer_canboot_binary, cbsize) == 0) {
        try_request_canboot();
        halt();
    }

Assuming we set fstart to `CONFIG_BOOTLOADER_START' we might have an issue erasing the first page when using the deployer with the rp2040.

I'm going to try to test this on real hardware today to see how the deployer works. Hopefully it something we can get working but it isn't a huge issue if we can't, we just need to disable it and document it.

sh83 · 2022-10-30T15:02:44Z

Deployer work fine in my setup as is . No fixup is required afaik.
It is a bit confusing: canboot binary contains boot2 ( first 256 bytes) as it should. But canboot itself(i.e. interrupt table) start at 0x10000100. So klipper should look at this to find canboot presence .
Answer other questions later.

- moved external files to lib folder - fixed typos - added optional "sudo" to flash command - fixed redundant file close in script - fixed compilation warning

sh83 · 2022-10-30T18:58:03Z

Added misc fixes:

moved external files to lib folder
fixed typos
added optional "sudo" to flash command (To make it a little bit user friendly rp2040: Added rp2040 support. #45 (comment))
fixed redundant file close in script
fixed compilation warning (see rp2040: Added rp2040 support. #45 (comment))

sh83 · 2022-10-30T19:07:02Z

@Arksine, thanks for review. Answers to your notes:

I moved files as suggested
I think I did not touch deployer build, it should not be different from other targets. It do not harm to build it anyway )
deployer.c should not be changed. Although canboot itself (vector table) starts at 0x10000100, we append boot2 before (see magic with stage2.o in rp2040/Makefile). CONFIG_BOOTLOADER_START only used to locate canboot vector table in deployer and klipper.
no problem here, see above

Arksine · 2022-10-31T11:23:36Z

Thanks for the explanation, makes sense. Everything looks good and tests well on my end, so I merged.

tnap1979 · 2022-10-31T16:12:02Z

hey guys, i have a question.
im running the mellow SB2040 v1 canbus printhead...
on manta m4p/cb1 combo running the latest btt cb1 full image with klipperscreen and a UtoC-3
im able to get a succesful UUID from the sb2040
but klipper still seems unable to connect to the sb2040 mcu via can
the can network is obviously up and running if im able to get the uuid no ?
what gives ? why wont klipper connect to the mcu?
i have a proper .cfg setup with mcu id and cnabus uuid

nvrprfct · 2022-11-02T16:38:49Z

hey guys, i have a question. im running the mellow SB2040 v1 canbus printhead... on manta m4p/cb1 combo running the latest btt cb1 full image with klipperscreen and a UtoC-3 im able to get a succesful UUID from the sb2040 but klipper still seems unable to connect to the sb2040 mcu via can the can network is obviously up and running if im able to get the uuid no ? what gives ? why wont klipper connect to the mcu? i have a proper .cfg setup with mcu id and cnabus uuid

Well, most low level parameters should be ok by default. Recommended install procedure is following:
1. Boot into buildin bootloader mode - apply power with mode button pressed
2. Flash binary flash_nuke.uf2 (https://learn.adafruit.com/getting-started-with-raspberry-pi-pico-circuitpython/circuitpython) via mass storage method or via rp2040_flash
3. Wait a minute or two. Dyring this flash_nuke.uf2 will erase all flash
4. Boot into buildin bootloader mode again
5. Build canboot.uf2 and flash canboot.uf2 by the same method
6. Check usb or can bus - canboot should be up running and connected
7. Now it is possible to flash klipper.bin from my klipper pr. Bootloader option should be enabled in klipper menuconfig.
This should work given hardware is ok.

once canboot is flashed, you need to flash klipper from sh83s klipper fork, at least until his pull request is merged.

Flob74 · 2022-11-06T15:34:35Z

Hi guys,

Thank you for your work for integrating RP2040 to canboot.

I'm also trying to install the SB2040 with the Octopus board. But I'm not able to complete :

I flashed Canboot firmware on both mcu octopus and SB2040 (STM32Cube method & storage flash method)
I flashed the octopus with klipper as USB to CAN bus bridge
I setup can0 on my Raspberry Pi
I found my two UUID and updated the printer.cfg file.
I flashed klipper to the SB2040

Then I got the klipper error mcu "'SB2040': Unable to connect" and when I restart the printer, the SB2040's blue light for "flash successfull" turn off. The wiring seems fine as I flashed Klipper throught CanBoot CAN command. I think that I missed something in the canboot's menuconfig.

Please, can anyone explain me simply which option did I missed ? Thank you

sh83 · 2022-11-06T15:45:12Z

@Flob74 The klipper pull request is not merged yet. I expect it will be done in a few days. For now you could use klipper from pull request branch https://github.com/Klipper3d/klipper/tree/work-rp2040canboot-20221103 , or just wait a bit until klipper is ready. Also in klipper menuconfig bootloader support(16kib) should be enabled.
By the way what is gpio24 on sb2040?

tnap1979 · 2022-11-06T15:45:47Z

hey guys, i have a question. im running the mellow SB2040 v1 canbus printhead... on manta m4p/cb1 combo running the latest btt cb1 full image with klipperscreen and a UtoC-3 im able to get a succesful UUID from the sb2040 but klipper still seems unable to connect to the sb2040 mcu via can the can network is obviously up and running if im able to get the uuid no ? what gives ? why wont klipper connect to the mcu? i have a proper .cfg setup with mcu id and cnabus uuid

Well, most low level parameters should be ok by default. Recommended install procedure is following:

Boot into buildin bootloader mode - apply power with mode button pressed

Flash binary flash_nuke.uf2 (https://learn.adafruit.com/getting-started-with-raspberry-pi-pico-circuitpython/circuitpython) via mass storage method or via rp2040_flash

Wait a minute or two. Dyring this flash_nuke.uf2 will erase all flash

Boot into buildin bootloader mode again

Build canboot.uf2 and flash canboot.uf2 by the same method

Check usb or can bus - canboot should be up running and connected
7. Now it is possible to flash klipper.bin from my klipper pr. Bootloader option should be enabled in klipper menuconfig.
This should work given hardware is ok.

once canboot is flashed, you need to flash klipper from sh83s klipper fork, at least until his pull request is merged.

Yea, I'll admit.. I had a total brain dump when I realized I STILL had to flash klipper after canboot... considering I've done canboot on the btt stuff a few times .. thanks for the response..
After all said and done, the system IS running very stable and so far hasn't presented any issues.. and has now made about 5 consecutive prints in a row

tnap1979 · 2022-11-06T15:48:58Z

@Flob74 The klipper pull request is not merged yet. I expect it will be done in a few days. For now you could use klipper from pull request branch https://github.com/Klipper3d/klipper/tree/work-rp2040canboot-20221103 , or just wait a bit until klipper is ready. Also in klipper menuconfig bootloader support(16kib) should be enabled. By the way what is gpio24 on sb2040?

This is a led indicator on the side of the board to basically let you know if it flashed or not.. or status?? I'm not sure.. but I used my gpio24 enabling and disabling to make sure canboot flashed ok

jtrmal · 2022-11-06T15:50:33Z

Hi, gpio24 is a status led -- Mellow does not explain in their docs what does it do, so people just keep copying it from their example config (https://mellow.klipper.cn/#/board/fly_sb2040/flash) But generally I've found it's better to treat it as a status led in the canboot, so that I can distinguish between canboot active (blinking) and klipper active (solid) y.

…

On Sun, Nov 6, 2022 at 10:45 AM tnap1979 ***@***.***> wrote: hey guys, i have a question. im running the mellow SB2040 v1 canbus printhead... on manta m4p/cb1 combo running the latest btt cb1 full image with klipperscreen and a UtoC-3 im able to get a succesful UUID from the sb2040 but klipper still seems unable to connect to the sb2040 mcu via can the can network is obviously up and running if im able to get the uuid no ? what gives ? why wont klipper connect to the mcu? i have a proper .cfg setup with mcu id and cnabus uuid Well, most low level parameters should be ok by default. Recommended install procedure is following: 1. Boot into buildin bootloader mode - apply power with mode button pressed 2. Flash binary flash_nuke.uf2 ( https://learn.adafruit.com/getting-started-with-raspberry-pi-pico-circuitpython/circuitpython) via mass storage method or via rp2040_flash 3. Wait a minute or two. Dyring this flash_nuke.uf2 will erase all flash 4. Boot into buildin bootloader mode again 5. Build canboot.uf2 and flash canboot.uf2 by the same method 6. Check usb or can bus - canboot should be up running and connected *7. Now it is possible to flash klipper.bin from my klipper pr. Bootloader option should be enabled in klipper menuconfig.* This should work given hardware is ok. once canboot is flashed, you need to flash klipper from sh83s klipper fork, at least until his pull request is merged. Yea, I'll admit.. I had a total brain dump when I realized I STILL had to flash klipper after canboot... considering I've done canboot on the btt stuff a few times .. thanks for the response.. After all said and done, the system IS running very stable and so far hasn't presented any issues.. and has now made about 5 consecutive prints in a row — Reply to this email directly, view it on GitHub <#45 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACUKYX3TF6MOPAKG5CEKPOLWG7ACLANCNFSM6AAAAAARKRKOPU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

tnap1979 · 2022-11-06T15:52:11Z

Hi, gpio24 is a status led -- Mellow does not explain in their docs what does it do, so people just keep copying it from their example config (https://mellow.klipper.cn/#/board/fly_sb2040/flash) But generally I've found it's better to treat it as a status led in the canboot, so that I can distinguish between canboot active (blinking) and klipper active (solid) y.
…
On Sun, Nov 6, 2022 at 10:45 AM tnap1979 @.> wrote: hey guys, i have a question. im running the mellow SB2040 v1 canbus printhead... on manta m4p/cb1 combo running the latest btt cb1 full image with klipperscreen and a UtoC-3 im able to get a succesful UUID from the sb2040 but klipper still seems unable to connect to the sb2040 mcu via can the can network is obviously up and running if im able to get the uuid no ? what gives ? why wont klipper connect to the mcu? i have a proper .cfg setup with mcu id and cnabus uuid Well, most low level parameters should be ok by default. Recommended install procedure is following: 1. Boot into buildin bootloader mode - apply power with mode button pressed 2. Flash binary flash_nuke.uf2 ( https://learn.adafruit.com/getting-started-with-raspberry-pi-pico-circuitpython/circuitpython) via mass storage method or via rp2040_flash 3. Wait a minute or two. Dyring this flash_nuke.uf2 will erase all flash 4. Boot into buildin bootloader mode again 5. Build canboot.uf2 and flash canboot.uf2 by the same method 6. Check usb or can bus - canboot should be up running and connected 7. Now it is possible to flash klipper.bin from my klipper pr. Bootloader option should be enabled in klipper menuconfig. This should work given hardware is ok. once canboot is flashed, you need to flash klipper from sh83s klipper fork, at least until his pull request is merged. Yea, I'll admit.. I had a total brain dump when I realized I STILL had to flash klipper after canboot... considering I've done canboot on the btt stuff a few times .. thanks for the response.. After all said and done, the system IS running very stable and so far hasn't presented any issues.. and has now made about 5 consecutive prints in a row — Reply to this email directly, view it on GitHub <#45 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACUKYX3TF6MOPAKG5CEKPOLWG7ACLANCNFSM6AAAAAARKRKOPU . You are receiving this because you were mentioned.Message ID: @.>

Nice.. did not know it could be used for status...
Ya.. mellow docs aren't the best... they need work.
Well now I know I'll be setting up status led on my voron tridex build

jtrmal · 2022-11-06T15:56:10Z

[image: Screenshot 2022-11-06 at 10.53.41 AM.png] this is my "suggested" config for SB-2040.... it should enable you to enter canboot also by shorting the two-pin endstop pins (there are three slots for endstops on SB-2040, so I'm using the one I'm not using for endstop) y.

…

On Sun, Nov 6, 2022 at 10:52 AM tnap1979 ***@***.***> wrote: Hi, gpio24 is a status led -- Mellow does not explain in their docs what does it do, so people just keep copying it from their example config ( https://mellow.klipper.cn/#/board/fly_sb2040/flash) But generally I've found it's better to treat it as a status led in the canboot, so that I can distinguish between canboot active (blinking) and klipper active (solid) y. … <#m_2375375500144913956_> On Sun, Nov 6, 2022 at 10:45 AM tnap1979 *@*.*> wrote: hey guys, i have a question. im running the mellow SB2040 v1 canbus printhead... on manta m4p/cb1 combo running the latest btt cb1 full image with klipperscreen and a UtoC-3 im able to get a succesful UUID from the sb2040 but klipper still seems unable to connect to the sb2040 mcu via can the can network is obviously up and running if im able to get the uuid no ? what gives ? why wont klipper connect to the mcu? i have a proper .cfg setup with mcu id and cnabus uuid Well, most low level parameters should be ok by default. Recommended install procedure is following: 1. Boot into buildin bootloader mode - apply power with mode button pressed 2. Flash binary flash_nuke.uf2 ( https://learn.adafruit.com/getting-started-with-raspberry-pi-pico-circuitpython/circuitpython <https://learn.adafruit.com/getting-started-with-raspberry-pi-pico-circuitpython/circuitpython>) via mass storage method or via rp2040_flash 3. Wait a minute or two. Dyring this flash_nuke.uf2 will erase all flash 4. Boot into buildin bootloader mode again 5. Build canboot.uf2 and flash canboot.uf2 by the same method 6. Check usb or can bus - canboot should be up running and connected 7. Now it is possible to flash klipper.bin from my klipper pr. Bootloader option should be enabled in klipper menuconfig. This should work given hardware is ok. once canboot is flashed, you need to flash klipper from sh83s klipper fork, at least until his pull request is merged. Yea, I'll admit.. I had a total brain dump when I realized I STILL had to flash klipper after canboot... considering I've done canboot on the btt stuff a few times .. thanks for the response.. After all said and done, the system IS running very stable and so far hasn't presented any issues.. and has now made about 5 consecutive prints in a row — Reply to this email directly, view it on GitHub <#45 (comment) <#45 (comment)>>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACUKYX3TF6MOPAKG5CEKPOLWG7ACLANCNFSM6AAAAAARKRKOPU <https://github.com/notifications/unsubscribe-auth/ACUKYX3TF6MOPAKG5CEKPOLWG7ACLANCNFSM6AAAAAARKRKOPU> . You are receiving this because you were mentioned.Message ID: @.*> Nice.. did not know it could be used for status... Ya.. mellow docs aren't the best... they need work. Well now I know I'll be setting up status led on my voron tridex build — Reply to this email directly, view it on GitHub <#45 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACUKYX3TVAZSH555F64KGS3WG7A2NANCNFSM6AAAAAARKRKOPU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

Flob74 · 2022-11-06T16:32:34Z

Thank you for your quick answers. I think that I will wait a couple of days that klipper merge the branch.

For the GPIO24, jtrmal was true, I just copied it from the Mellow Fly documentation.

jtrmal : Mellow does not explain in their docs what
does it do, so people just keep copying it from their example config

Also, please jtrmal, as the message was posted from an email my navigators can't launch the image : [image: Screenshot 2022-11-06 at 10.53.41 AM.png]. It seems very interesting.

jtrmal · 2022-11-06T16:40:58Z

ok, I uploaded it again, didn't know that github won't add the pic. I actually didn't figure out if the "doublick" option does something for SB-2040, as it does have only boot button. Also, it's not super-important to have the endstop as "button" enabled, as flash_can can trigger canboot on its own.

tnap1979 · 2022-11-06T16:41:30Z

Thank you for your quick answers. I think that I will wait a couple of days that klipper merge the branch.

For the GPIO24, jtrmal was true, I just copied it from the Mellow Fly documentation.

jtrmal : Mellow does not explain in their docs what
does it do, so people just keep copying it from their example config

Also, please jtrmal, as the message was posted from an email my navigators can't launch the image : [image: Screenshot 2022-11-06 at 10.53.41 AM.png]. It seems very interesting.

@Flob74 if you use the latest Kiauh klipper helper.. you can install @sh83 version of klipper directly thru kiauh, that's how I did mine

sh83 mentioned this pull request Oct 20, 2022

rp2040: Added canboot bootloader support for rp2040. Klipper3d/klipper#5844

Closed

sh83 commented Oct 20, 2022

View reviewed changes

sh83 force-pushed the master branch from cdc70b7 to 3886ec2 Compare October 20, 2022 21:39

sh83 mentioned this pull request Oct 20, 2022

CanBoot for RP2040 #42

Closed

sh83 force-pushed the master branch from 3886ec2 to 644e9dc Compare October 20, 2022 21:59

sh83 commented Oct 20, 2022

View reviewed changes

sh83 added 6 commits October 21, 2022 23:12

rp2040: Initial import from klipper as is.

63afca9

Signed-off-by: Alex Malishev <malishev@gmail.com>

rp2040: Import flash and bootrom related files from pico-sdk

7360c90

(https://github.com/raspberrypi/pico-sdk/tree/master/src/rp2_common/hardware_flash, https://github.com/raspberrypi/pico-sdk/tree/master/src/rp2_common/pico_bootrom) as is. Signed-off-by: Alex Malishev <malishev@gmail.com>

rp2040: modified and renamed pico sdk files.

d0597c1

Signed-off-by: Alex Malishev <malishev@gmail.com>

rp2040: Implemented canboot flash interface.

62bed27

Implemented canboot timer interface. Simplified chipid.c to use common flash interface. Signed-off-by: Alex Malishev <malishev@gmail.com>

rp2040: Added needed options to Kconfig, cleaned up.

3955dc1

Modified linker script and loader to load whole bootloader to the RAM. Removed whatchdog. Fixed gpio.c compilation. Signed-off-by: Alex Malishev <malishev@gmail.com>

build: rp2040 added to the main Kconfig.

dfb3343

Signed-off-by: Alex Malishev <malishev@gmail.com>

sh83 force-pushed the master branch from 644e9dc to 4b01b98 Compare October 21, 2022 20:26

sh83 commented Oct 21, 2022

View reviewed changes

sh83 force-pushed the master branch from 4b01b98 to ba9e5e2 Compare October 24, 2022 18:42

reset: fixed rp2040 bootloader entry point

7376508

Signed-off-by: Alex Malishev <malishev@gmail.com>

sh83 force-pushed the master branch from ba9e5e2 to 7376508 Compare October 24, 2022 18:44

rp2040: added option to force bootloader before new application flashed

d05a956

Signed-off-by: Alex Malishev <malishev@gmail.com>

common: misc fixes:

55cccf6

- moved external files to lib folder - fixed typos - added optional "sudo" to flash command - fixed redundant file close in script - fixed compilation warning

sh83 force-pushed the master branch from 1a2dad6 to 55cccf6 Compare October 30, 2022 18:56

Arksine merged commit 2990480 into Arksine:master Oct 31, 2022

rp2040: Added rp2040 support. #45

rp2040: Added rp2040 support. #45

Conversation

sh83 commented Oct 20, 2022 • edited Loading

sh83 Oct 20, 2022

Choose a reason for hiding this comment

sh83 Oct 20, 2022

Choose a reason for hiding this comment

sh83 Oct 20, 2022

Choose a reason for hiding this comment

sh83 Oct 20, 2022

Choose a reason for hiding this comment

Arksine commented Oct 21, 2022 • edited Loading

sh83 commented Oct 21, 2022

sh83 commented Oct 21, 2022

sh83 Oct 21, 2022 • edited Loading

Choose a reason for hiding this comment

sh83 Oct 21, 2022

Choose a reason for hiding this comment

sh83 Oct 21, 2022

Choose a reason for hiding this comment

sh83 Oct 21, 2022

Choose a reason for hiding this comment

sh83 commented Oct 24, 2022

jtrmal commented Oct 28, 2022 • edited Loading

jtrmal commented Oct 28, 2022 • edited Loading

sh83 commented Oct 28, 2022 • edited Loading

jtrmal commented Oct 28, 2022 • edited Loading

jtrmal commented Oct 28, 2022

sh83 commented Oct 28, 2022 • edited Loading

jtrmal commented Oct 28, 2022 via email

sh83 commented Oct 28, 2022

jtrmal commented Oct 29, 2022

sh83 commented Oct 29, 2022

Arksine commented Oct 30, 2022

sh83 commented Oct 30, 2022 • edited Loading

sh83 commented Oct 30, 2022 • edited Loading

sh83 commented Oct 30, 2022 • edited Loading

Arksine commented Oct 31, 2022

tnap1979 commented Oct 31, 2022

nvrprfct commented Nov 2, 2022 • edited Loading

Flob74 commented Nov 6, 2022

sh83 commented Nov 6, 2022 • edited Loading

tnap1979 commented Nov 6, 2022

tnap1979 commented Nov 6, 2022

jtrmal commented Nov 6, 2022 via email

tnap1979 commented Nov 6, 2022

jtrmal commented Nov 6, 2022 via email

Flob74 commented Nov 6, 2022

jtrmal commented Nov 6, 2022

tnap1979 commented Nov 6, 2022

sh83 commented Oct 20, 2022 •

edited

Loading

Arksine commented Oct 21, 2022 •

edited

Loading

sh83 Oct 21, 2022 •

edited

Loading

jtrmal commented Oct 28, 2022 •

edited

Loading

jtrmal commented Oct 28, 2022 •

edited

Loading

sh83 commented Oct 28, 2022 •

edited

Loading

jtrmal commented Oct 28, 2022 •

edited

Loading

sh83 commented Oct 28, 2022 •

edited

Loading

sh83 commented Oct 30, 2022 •

edited

Loading

sh83 commented Oct 30, 2022 •

edited

Loading

sh83 commented Oct 30, 2022 •

edited

Loading

nvrprfct commented Nov 2, 2022 •

edited

Loading

sh83 commented Nov 6, 2022 •

edited

Loading