So i've had the issue everyone is having right now. My setup is an octopus pro, an ebb36 sb2209 rp2240, and a btt pi.
I didn't realise it at first, but my board came preflashed with canboot (so katapult), and I realise now I could've used this to update my motherboard instead of redoing the entire thing.
Anyway, I am following
https://github.com/Esoterical/voron_canbus/tree/main/mainboard_flashing
I'll try to cite my every steps, so it is easier for you to debug.
Here is my make menuconfig from katapult. My first question is: should the communication interface be set on usb or can? considering i will set it as a can bridge. The guide state USB, but maybe this is the source of my problems?
Anyway. I press Q, then Y, then sudo shutdown now. I power off the printer, add the jumper on the octopus pro, and restart the printer. In the meantime, I confirm i have an STM32F446, and that the board is connected on the USB-C port, so PA11-12 https://github.com/bigtreetech/BIGTREETECH-OCTOPUS-V1.0/blob/master/Firmware/Klipper/README.md
I reconnect via SSH, and do sudo dfu-util -l.
I see the board in DFU, and do cd ~/katapult make sudo dfu-util -R -a 0 -s 0x08000000:force:mass-erase:leave -D ~/katapult/out/katapult.bin -d 0483:df11. I dont change the line, as it's both 0483:df11 and 0x08000000.
As per usual, it starts by saying "dfu-util: Invalid DFU suffix signature", but it then goes successfully..
I do sudo shutdown now, power off the printer after a little while, remove the jumper, and powers it back on.
(continued in the comments)
#I can't setup katapult on my printer anymore
523 messages ยท Page 1 of 1 (latest)
I connect via SSH again, and immediately run ls /dev/serial/by-id/. I see the board correctly, so I proceed.
make menuconfig``` once again
And you can see again the pictures. Are the interfaces correct? Also, in the guide, it says
> You want the Processor and Clock Reference to be set as per whatever board you are running. Set Communication interface to 'USB to CAN bus bridge' then set the CAN Bus interface to use the pins that are specific to your mainboard. Also set the CAN bus speed to the same as the speed in your can0 file. In this guide it is set to 1000000.
However, I don't have a can0 at this point. or rather, i dont know of a can0 file. Could this be the problem ?
Anyway, I do:
-->Q -->y --> make clean --> make
Then `python3 ~/katapult/scripts/flashtool.py -f ~/klipper/out/klipper.bin -d /dev/serial/by-id/usb-katapult_stm32f446xx_3D0023000B50335331383820-if00`
I want to highlight that, for this step, as it is not mentionned, i haven't put the octopus pro in DFU mode. I have done only what I have described and nothing more. It says flash succes, so I then do lsusb, it takes a surprisingly long amount of time to run this, but then tadaaaa: it doesn't show anything can related....
Forgot to add: Same if I do ifconfig: there's no mention of can0
I have tried to fix this with @timid steeple yesterday, you can find the steps we went through here
#klipper_kalico_discussion message
#klipper_kalico_discussion message
but nothing changed. All the images you see were taken today, this is the fourth time I'm attempting this method, and my printer is unusable right now
If you have another method, I would really appreciate it. At this point, I just want my printer running again
THe first step (With katapult) was completely correct, and that's good. The second step, maybe you had an error in your klipper make menuconfig (even though your screenshot is correct, did it save correctly?).
Also, you should have made the /etc/interfaces.d/can0 file by this point, that is on the very first page of the guide before you get to any mainboard flashing stuff. But that wouldn't cause any problems at this stage anyway.
Can you run wget -qO - debug.esoterical.online | sh and post the termbin link it makes?
Isn't supposed to be /etc/network/interfaces.d/can0 ? Because i have the file there, but not the path you mentionned
ah, yeah, /etc/network/interfaces.d/can0. Sorry, just woke up, not firing on all cylinders yet
does your octo definitely have "STM32F446" on the main chip?
actually, nevermind, it would if that worked with katapult
if you remove the DFU jumper (if you haven't already) then press the reset button once on the octopus, does it show to lsusb ?
hold up, i just realised there are two buttons
is it he one above the usb c cable, or the on above the usb a cable ?
the one above the USB should be the reset button I think
USB A ?
still nothung. OK can you double-click that button then lsusb?
double-click should put it back into katapult mode
sweet, does ls /dev/serial/by-id show the katapult ID again?
yes !
if so, can you cd ~/klipper and make menuconfig and screenshot it again please?
ok, hit Q to save and quit, then make clean then make
Also
if you want to make sure yourself that it is indeed an stm32f446
Obvisouly.... the picture has to be flipped hahaa
then run the "flash klipper via katapult" command:
python3 ~/katapult/scripts/flashtool.py -f ~/klipper/out/klipper.bin -d /dev/serial/by-id/your_katapult_id
replacing the your_katapult_id with the /dev/serial/by-id ID of your katapult ID
did you definitely do the make clean and make first? before the katapult flash command?
no, that's correct
This is insane, what is wrong with my setup ๐
the thing is, It looks like it doesn tsee the can0 file
it should be showing up as a "geschwister CAN adapter" to an lsusb, which it isn't
I have seen some architecture changes when it comes to BTT pi, could this be it ?
also, i haven't touched the setup, so everything is still wired up, if that matters
if you have no CAN USB adapter showing then it won't show teh can0 network
okay, its good to know
but then, what does it mean? the flashing didn't succeed? the klipper service hasn't launched ? it has but it is not recognized?
one thing we can try (to just rule out katapult, even though it looks fine) is to put it back into DFU mode so it shows as an "STM device in DFU mode", then do the klipper make menuconfig again and change it so it shows "no bootloader", then make clean and make and make flash FLASH_DEVICE=0483:df11
this will overwrite katapult with straight klipper. If this still doesn't then show up as a CAN adapter in lsusb then I'd say the problem is with the BTT distro on your cb1 or something
I can't help but to notice make clean provided an output this time. Is this because I've changed the menuconfig ?
yeah
that's good, it downloaded
but didn't flash, right ?
it' flashed
everything after "file downloaded successfully" you can ignore
it's just saying it couldn't "reboot" back into DFU mode orsomething, but we don't care about that
what does lsusb show now?
I've run it twice. Once with the jumper, once with the jumper removed. It stills shows as device in dfu mode
should i reboot and check again ?
yeah, reboot
removing the jumper won't take it out of DFU, you need to remove jumper and reboot the board
I can take the rpi of my home assistant and check if it works better, but I'm guessing I will have a lot of reconfiguration to do
honestly, not really. As long as you can get to a base linux shell (not the HASS cut down SSH thing they give you). Don't even need klipper or anything on the linux, we just want to see if the "Geschwister CAN adapter" shows up to lsusb
Im not sure I understand what you mean hahaah
I say there would be reconfiguration to do, because I think some of the folder architecture is different on the btt pi. But I may be wrong
oh, yeah you couldn't put the SD from teh BTT Pi into a "normal" pi. I thought you were going to just grab teh home assistant Pi as-is and plug the octo into it
what does it show up as in lsusb after the reboot?
sorry for the wait, its still coming
i did a reboot instead of a power off and power on
not lookjing great...
yeah nothing. I suspect that BTT pi distro is misbehaving, doesn't have the drivers for a CAN network maybe?
probably worth googling around/asking about/seeing if there is a newer linux version on teh BTT github or something
Im not sure i understand what you mean , how can I check if it has the drivers for CAN network?
also
I'm not saying that's the problem, just something like that maybe, I truly don't know
As mentionned yesterday: my printer was working great until the update. It was flashed using canboot. I know canboot is katapult, BUT, the folder is still there, maybe I can try to use what's there to recreate the condition it was flashed with ?
I didn't update the canboot folder
nah, nothing to do with canboot/katapult. 1. you had katapult installed fine before and 2. now we don't have katapult on there at all and it still doesn't show.
I'd say the distro upgrade did something to break it
Probably worth going back and putting katapult back on (like you had done before you opened this ticket, it looks like it was all good) and then flashing klipper to it again the same way you did the first time (but change the klipper menuconfig to have 32KiB bootloader offset again)
distro upgrade = klipper update ?
if you pressed the "update all" button in mainsail then it'll update klipper and stuff, but also update/upgrade the linux distro itself on the pi
But, I never managed to do it
I bought the kit from siboor, and the octopus and the btt pi can pre flashed, I don't know how they did it
I have flashed multiple skr pico and skr mini, it never had can, and it never was with a btt pi, its why it's driving me insane, I can't make it
Maybe I should reuse the rpi4 of HASS and start over ?
if you are happy to do that, running a "real" Pi and Raspberry Pi OS (or MainsailOS) makes it a lot easier to know what's going on. For me anyway.
otherwise, check the BTT github for a manual or instructions on flashing /upgrading linux on the BTT Pi
Ill do the latter first
You seem to know HASS. Do you kjnow if it can run on a BTT pi ? If it does, then i'm absolutely fine swapping both
or would there be another way to flash klipper, maybe without katapult, to have my printer working again and touching the electronic ? I think my toolhead is still under canboot(katapult), as I haven't reflashed it. Maybe I can set the octopus pro as a can bridge without katapult, and then use katapujlt to update the toolhead?
When you flashed it before with "no bootloader" selected in the Klipper menuconfig? That was flashing without katapult. When you use those settings it overwrites any bootloader (like katapult) that is there and has only Klipper firmware There
I got similar issues with Mellows SB2040 V1, Wont flash with CANBUS or CANUSB. Giving up untill this messy uodate issue is sorted out. I have cloned a working Kilpper V11 so i can back date this update
but it didn't work, did it ?
no, didn't seem to. but that would indicate the problem isn't caused by canboot/katapult
okay, i see what you mean. Ill see what I can do, on the github page of BTT pi, there's only a manual about flashing the btt pi, so idk if ill try to reflash it or simply replace it by a rpi
thanks
Alright I bought a new SD card, so I can make a second flash without loosing the rest yet. Just for testing. I realised that the guide doesn't include everything, like the setting up of the can0 file (unless its done automatically ?)
What else should I pay attention to setup the canbus without a brand new install ?
Creating the can0 file is on the very first page of esoterical's guide
oh okay, that's not he link i was following, let me take a look !
Okay, I have reflashed the btt pi on a new sd card, I have transfered the printer_data folder to retrieve all my printer's data, and ive redone the entire process with katapult, it still isn't working. The weird thing is, the firmware of the cb1 hasn't been updated (at least on the github page). SO maybe there is a compatibility issue with the new klipper firmware that needs to be adressed by BTT. I realised I can't really use a rpi, as I don't have the 5v PSU....
Could you give me a procedure of how you did this? I would be very interested in doing this if it makes my printer print again
What exactly is the actual issue right now?
I can't use katapult to flash or update my octopus pro and my ebb sb2209 rp2040, and apparently, the probleme doesn't come from katapult
We 've tried a lot of things to figure it out with esoterical, like by using the reset button on the mcu to force the mcu into dfu (i think) and check the lsusb at everystep, but it never appears as a can bridge
We have tested without katapult as a bootloader, and it still won't work
I mean, weird, but in terms of getting a working printer, can't you just dfu flash everything then?
Before I answer this, let me tell you I am completely new to CAN bus, so it's possible that I'm unaware of other ways but
if im not mistaken, we have tried without katapult as a bootloader, so isn't it equivalent to just dfu flash everything ?
also
Maybe, probably, but im sure you can recognise that "I can't use katapult" and "I can't get my ebb to flash by any means" are very different statements
I bought my kit from siboor, everything came pre flashed, so that's also why I have no experience in flashing both the toolhead and the octopus pro to work in can
And I don't know which one is true until you tell me ๐
Then I may have misunderstood @timid steeple , when he told me the issue wasn't coming from katapult.
Ill try to find another way of flashing both the octopus pro and the toolhead and we shall see
I mean, flashing the octopus is easy
Put the boot jumper on, hit reset, and use make make flash
Toolhead, almost the same, except the added complication of getting a usb cable to it
I can't flash via the can bus cable ?
No
also, I haven't touched the toolhead yet, so I think it's still under katapault. Is this possible or is it me misunderstanding katapult ?
Is this still correct for the octopus pro without katapult ?
Yes. Katapult is all about flashing via canbus
but it requires the octopus pro to also be on katapult, right ?
No
oh, so I could flash the octopus pro as is, and update the toolhead with katapult ?
Sure
Nice !
let me flash the octopus pro real quick and we shall see
But, out of curiosity, what is the purpose of having the octopus on katapult ? Simply to avoid openning the eletronic bay and adding a jumper ? or is this a "colateral" bonus ?
Basically just that, yes. Once you are using the octopus in can bridge mode, getting it back into dfu for an update involves physical access, which is annoying
Okay, this error is always throwing me off, it did flash correctly, right ?
Looks like, yes.
Generally as long as you see the "downloaded successfully", any error after that is just noise
What is weird is, the octopus still shows as in dfu mode... After flashing with
make flash FLASH_DEVICE=0483:df11```
`lsusb` didn't show it, so i removed the jumper and rebooted the bttpi, and now it shows this
Did you do make clean and make before the make flash?
Did you power down and remove the boot jumper after?
i removed the jumper before powering down I think
and yes I did make clean then make, before the flash
Okay, have you, or have you not rebooted the octopus after flashing
well, now I'm nost sure if I did reboot or turn the printer off and on again ๐
let me sudo shutdown now then power it off and on
Don't necessarily need the cb1 to go down
Tapping reset on the octopus would be good enough
:/
Okay, let's retry building and flashing that firmware, but this time, use the "no bootloader" setting in bootloader offset
Actually, i think that's what we did right here#1201183395997298798 message, but ill try again
Discord is the easiest way to communicate over voice, video, and text. Chat, hang out, and stay close with your friends and communities.
Interesting. That does look the same
I disagree with esoterical's analysis though. If it were a driver issue as he speculates, you'd still see the device in lsusb
Could you show me the output of usbreset ?
And put the board back into dfu mode, then do that again?
Bah. I thought it would give me a little more info. Oh well.
This is getting tricky i guess
Its pretty puzzling
The other weird thing is, it feels like I'm the only one having this issue, so I'm not even sure it comes from the BTT pi
I have taken a look a the siboor's discord and, obviously, there's a lot of post about the current update, that everyone is asking about, but most of them managed to fix it by following esoterical's guide. I don't know what changed here
It doesn't. At least, I don't see how it could.
Just as a long shot
Could you type sudo dmesg -W
Then unplug the octopus usb, wait 5 seconds, then plug it back in?
unplug the usb or the power?
Then tell me what, if anything, shows up in the console
Damn it
Sorry
I skipped a step
Could you do that again, but without the boot jumper please?
I was looking for what if anything shows up in NORMAL mode...
it is still going on, should I let it go ?
Huh.
Well, as silly as it sounds...could you try a new usb cable? Most of the time, that particular error is the cable
Though I have no idea why the new firmware would trigger that more
also, I don't know how much you've read of the apst messages, but I have 100+ hours with the machine, I didn't touch the usb cable
i will still try a new one though, just to make sure
I just need to find one That I know transfers data
I hear you, I honestly do. But I also know that message is ...almost always...cabling
So we gotta at least rule it out
Ya, sounds good
same... It is a cable I used with my keyboard,so it should be able to transfer data
Well then
Actually, wait a second
Hmm?
Ive plugged my phone to my pc with this cable, I dont have the notification about data transfer
okay, its just my pc, I took my laptop and it does work ( my usb connection started bugging on my pc after trying to reflash an sd card for the btt pi, i probably need to reboot it)
Just for curiosities sake, if you build the firmware for regular usb, rather than can bridge, does it work any better?
(I know it doesn't help with the toolhead, but...)
yeah sure, I understand where the idea is coming from, im doing it right now and Ill let you know
I dont know if I should be happy or sad ahaha
Huh. Very interesting
I have seen issues where people couldn't see their mainboard after setting them as can bridge, because of the can bus speed
Let me check If I dont have a 0 missing or one too many...
When usb isn't establishing the low level connection, we're nowhere near a point that can speeds should impact anything
I can imagine scenarios either way honestly
@real sinew mentionned here that he went back to klipper v0.11 until the issue is resolved. This could be worth checking? this would definitely tell us if it's software or not
I certainly wouldn't go that far back
But a small Rollback probably isn't a bad idea to try
well, to the last version it was working with, I dont know which it was
However, I dont know how to do this ๐
Actually, before we try moving backwards, why don't we try forwards?
Why don't you go ahead and just update that, see if that changes anything?
but, isn't it up to date?
wow, so you are telling me an update JUST got out ? ๐
ill update it
No, I'm telling you you're a couple of months behind right now actually
Which is normally fine of course
I've never been one for the "must grab every single update"
But that;s weird considering I have just flashed the sd card, is this normal?
In the meantime, im doing the menuconfig. WIth or without bootloader?
Completely normal
You think btt updates that disk image every single time Kevin pushes a one line change to klipper?
No, rather that when I boot klipper, it automatically checks for update, but you are totally right ! My disk image is back from july, if im not mistaken
Ya, that's a little odd. Not sure why it hadn't checked automatically
Maybe it only does that when klipper is actually behaving or something?
I have just realised
Anyway. You're stuck in without bootloader for now, until such time as we actually do jam a bootloader back onto that board
WHen I assembled the kit, it had some weird version of klipper or idk. I can't recall but something was odd and I had to change the update manager, we didn't check if this was correct ?
( i can't remember what it was exactly)
Err?
Well...on my machine that's not on mainline klipper, there's a warning about it in update manager
Yours doesn't have that warning, so I think it's fine...
Alright, well, should be okay
Fire off that firmware and let's see if anything changes
Oh, damn
..backward ?๐
I just didn't realize what I was looking at
but im not surpsied, i got the error everyone is having after updating klipper, like on friday
so I had little hope that updating this new sd card would change anything, as its probably the same update
So strange
yeah don't worry, I should've been more specific
Honestly, I'd be tempted to just buy a u2c
You shouldn't have to. I'm a very happy can-bridge user myself. But....
Yeah, I'd hate to do it, that would mean 2-3 weeks of wait, and we wouldn't be sure it would work
Can we try going backward with klipper ?
Is there somewhere, in the filesof the btt pi, where I can find a history of the version I've used? if so, we could go back to this specific version
Well, definitely not now that you've reimaged...
As mentionned, this is a new sd card. I did this on purpose to keep everything intact on the other one
Otherwise, its maybe not too important, we can just rollback to the version before
Hey @quasi thicket. You got any git tricks for finding out what specific versions have previously been on a machine?
git reflog of course
THe speed of the man is uncontested
Let me switch sd card and ill do that
actually, before this, theres maybe a tiny detail that may be important? idk
My klipper screen never did this when shutting down
That's just the same stuff we were retrieving from dmesg
It also goes to the console
(Which is just hidden until klipperscreen shuts down)
okay, then nothing new there
Nope
Im guessing thats not how you use it
okay got it
I have to do git checkout HEAD@{1}, is this correct ?
you could also use the git commit ID like git checkout b50d6669
but git will warn you that it's not ideal, you probably want something like git checkout -b recovery b50d6669
(which will create a new local git branch called "recovery", from that git commit)
yeah, that should be pretty quick
git is usually pretty damn fast when it doesn't have to talk to a server
nice, then Ill try reflashing the octopus pro with this verison, and we shall be fixed
it did not... What the hell
but is it normal that here, it still mentions the other version ?
I wouldn't worry about whatever Mainsail says
it pokes at the git repo when it starts up and doesn't update that info unless you restart it or it performs an update itself, I think
you can't do the same git checkout to create it (because it already exists now), but instead you could try git reset --hard <next-git-commit-ID>
Let's try something silly
please tellme, im getting desperate
Strip the octopus down. Disconnect the canbus
You mean only remove the canbus from the octopus, or everything ?
This is what I'm debating honestly
Why don't we start small
Just do canbus, since our problem seems canbus related
But you can be sure that if that doesn't change anything, my next move will be everything except power and usb
just in case
Yep
even the power cable? toward the bed and stuff
okay, let me grab my label printer first
there it is, all naked, except for the power cable. Thers the power cable for the bed left, but its more about safety, cause i dont trust myself
as soon as you confirm its all good, ill power it on and do lsusb
Alright, sounds like a plan
uhhh apparentlz my jumper was still on.... so i dont kow how relevant the past result were...
by past result, i mean the very last one
oh boy
It breathes !
Ill replug everything except for the canbus and try again, or do you have another plan ?
I'd probably replug in groups
Okay, so the easiest first, the motors, as they dont really provide data to the octupus
then the fans, then the thermistor
then the led, and finally the can ?
Makes sense to me
and I power off between each trials ?
Yes. You should always be powered off when doing hookups
motor s: still good
fan: still good
thermistor: still good
aaaaaand led still there. Let's try again with the can bus cable i guess
aaaaaaand it's gone
so what does it mean ?
I mean, I think it means something about the canbus cable is preventing the octopus from initializing properly
Which is kinda weird
I guess I'd try unplugging the OTHER end. Let's find out if the issue is the cable itself, or the board at the far end....
it works
I know you have probably explained it already, but as this is new to me, im kind of lost, but could it be that the toolhead use katapult as a bootloader, and not the octopus pro ?
and because of this, there's a communication issue that voids everything?
I don't see how no
Because initially, it was all flashed through canboot. Then I tried reflashing the mainboard, with katapult, so a newer version of canboot, and suddently, nothing works anylonger
On a side note, I guess I can finally close the electronic bay and put back the printer?
Let's just stop and talk about bootloader for a second
oh, I should also try to rebase klipper to the newer version now i guess
so the bootloader is a very simple piece of software
all it does, is look when the board first starts, and check whether whatever thing (boot jumpers etc) is telling it to go into bootloader mode or not. If yes, it starts communicating on the appropriate interface, listening for firmware to be sent to it. if NOT, it just bails out. hands over control of the mcu to klipper (or whatever other software)
so once that handoff happens, the bootloader has absolutely no bearing on the further activity of that board
and katapult is a bootloader, is that correct?
correct
but if I dont see the printer in lsusb, could it mean it hasn't passed the bootloader? as it neither went in dfu mode, nor handed out the control
like if for some reason, it was just stuck in the bootloader
so get rid of the concept of "the printer"
because we need to be thinking in smaller increments than "the printer"
we're talking about individual boards here
sorry, it was out of habits, i meant the octopus pro
your main mcu is ending up in some kind of strange state, yes
but that mcu doesn't currently have a bootloader installed
so it can't be getting stuck in what isn't there
got it
(I'm technically oversimplifying. dfu mode is also a boot loader, but it's a factory installed one that we can't alter. it shouldn't have much relationship to this)
is it possible that your toolhead board is doing ...something incredibly bizarre that's preventing the main mcu from initializing? ...maybe. though I have very little idea what that would be
which is why I want to test with the wire connected, but the toolhead board disconnected
yes. but let's try the physical thing first
i never managed to put it into dfu mode, or at least visible. Altought, I assumed I couldnt see it because the can bus bridge wasn't set up
there's no scenario where dfu cares about canbus
dfu is a usb tool (well, and serial,but lets ignore that)
but the toolhead communicates through can ? so if there's no can, the mcu cannot see the toolhead in dfu mode, right ?
you're conflating unrelated things again
๐
the toolhead communicates over can in normal usage yes
the toolhead also communicates over can when we're flashing it via Katapult
that functionality is essentially why katapult exists
however
when we're flashing a board (no matter what board. toolhead or octopus) over dfu we need a usb connection
dfu is also our get-out-of-jail-free card though. because it's a factory burned in thing that can't be altered... it always works no matter how you've managed to scramble the software
okay
but wehen you say usb connection, you mean through usb port right ?
or can the can cable act as a usb connection too ?
Yes, I mean with a usb cable
You will need to take an extra USB cable, and temporarily plug it into the toolhead
From the pi to the toolhead
But you still haven't done my test (or still haven't told me the results at least)
what did you mean by the physical thing first ?
if thats removing the cable on the toolhead's end, then yes, it works
Okay. Well, fair enough. Toolhead is doing *something * crazy then
So okay. Get a usb hooked up to it, and put the toolhead into dfu mode
let me just check if I did it correctly. I pressed both buttons while plugging the usb c cable
I don't think it has to be all at once with those
oh okay, I need a jumper, let me find these little thing first ( I think they are smaller for this board)
Plug in cable first, then hold boot, while tapping reset
but I need the 5v jumper right ?
im watching this https://bttwiki.com/EBB 2209 CAN RP2040.html#firmware-updatevia-dfu
there it is
Aren't you getting power from the canbus cable?
Or is it still disconnected
Anyway. Cool. Board is there.
So I guess we reflash it from scratch now. Going through esotericals full guide for that board
Katapult, followed by klipper
I have removed the canbus cable for the time being
I'll take screenshot of both menuconfigs, at the very least
Oh so we still do it via katapult ? Okay, let me start over
No
We don't want to go VIA katapult (at least not for the first step]
But we do want to INSTALL katapult, so you can use it in the future
i think I understand the difference
but just to make sure, i do cd ~/katapult make menuconfig as per esoterical guide
correct?
Yes
Is this corect? I followed the images from the link I've provided
this is the katapult make menuconfig
What I find weird is the CAN RX gpio number and CAN TX gpio number, I think I should specify a gpio, but btt didn't specify any in their guide
Okay I went ahead, and it alrady shows when I look for UUID, which is already an improvement
and here, I should go for klipper without using katapult, is this correct ?https://github.com/Esoterical/voron_canbus/tree/main/toolhead_flashing/common_hardware/BigTreeTech SB2209 (RP2040)#klipper-when-not-using-katapult
Thats the bit Im not sure I understood (between not going VIA katapult, but still install katapult)
Ah. No
You should use the make menuconfig settings for with katapult
We'll flash it over dfu, when we get that far
But from a configuration standpoint, it still needs to be setup for use with katapult
okay, and finally
python3 ~/katapult/scripts/flashtool.py -i can0 -u 18c13c3fe2b8 -f ~/klipper/out/klipper.bin, right ?
(I have already changed the UUID in this command )
no. that's where we're going to deviate
Im just asking all of these questions because I feel like it's HERE you don't want to go via katapult ( so the script) but I should instead go with make flash or idk
won't this overwrite katapult ?
ohhh I think I finally understand
err
this is an rp2040, so it's actually NOT going to be dfu
it's going to be the rp2040's BOOTSEL or whatever
the offset as in, you want to keep that memory for the bootloader
same difference though
exactly
it is only a like 30k file ๐
How large is the one for the octopus ?
about the same
uh, oaky, I thought it was a bit longer for the octopus
probably
shall i power off the printer, replug the canbus, remove the usb c and power it on ?
different moving pieces there for sure
anyway, yes. I think that's the thing to do
let's find out if we'
if we changed anything useful!
Looks promising!
let me plug those UUID in the printer.cfg
What is a canbus uuid check showing?
Is it getting two devices, both running klipper?
better
1 katapult 1 klipper
Hmmm, klipper isn't starting properly i think, It's stuck in
time for a reboot !
No, that's not better
oh ?
You should be seeing two klipper devices
So somebody (and I'm pretty sure it's the toolhead) isn't quite with us yet
Maybe flashing klipper on the toolhead with make flash didn't work for some weird reason
Pull that jumper, but I doubt it'll change it
We may have to try a flash using katapult now....
do I need to redo make clean and make or not ?
Mmm....shouldn't need to.
Hold up, why did you use THAT uuid?
isnt it the one of the toolhead ?
well...
dont tell me i have to start over
No
It's probably fine
But slow your roll for a second and consider what you're looking at
well I see the octopus in DFU
Klipper provides canbus bridge mode
Not rhat
Before you went and did that
Klipper provides bridge mode. Katapult does not
So
If you're seeing two uuids, one klipper, one not, the ONLY WAY that occurs, is if the octopus is completely happily running klipper (in bridge mode) and the toolhead board is in katapult
but I dont see that anymore, is this an issue ? or will rebooting fix this ?
So when you're reading the two uuids in that listing, the one that says katapult must be the toolhead
Does that make sense?
Try to focus here.
yes totally, I agree with you
We're doing understanding right now
the thing is, I prepared the command beforehand
when I was only seeing 1 UUID. As the fact that I was finally seeing a UUID was new, i considered it was the toolhead, so I prepped the command
I don't think anything has actually been flashed to the octopus
but I agree that in the second picture with the two uuid
its absolutely obvious which is the toolhead and which is not
It just is in dfu mode waiting for stuff to be pushed
there's only one of the two that has katapult. It was just me being too hasty
So I think a simple reset or reboot will get it back in operation
But how did it go into dfu mode without katapult nor a jumper tho ?
Klipper is capable of rebooting it into dfu mode
And the flashing script must have triggered that functionality
Which is actually pretty cool . I didn't know it could do that
Katapult puts it into katapult flashing mode over usb, which is...same but different. But ya. Til
and it starts of with a bang hahahaa, But I think I know what this is
but heym thank you SO MUCH !
I truly appreciate the time you've taken to help me there, and I cannot express enough my gratitude toward you
Hey, you're welcome. That was a STRANGE problem, and I'm glad we were able to run It down
(Granted, I still don't know exactly WHAT the toolhead was doing that was breaking things so badly. But...details.)
Im just so happy that you stuck by, because nothing was helping us pin down the issue