Fill out above information andin all cases attach yourklippy.logfile (use zip to compress it, if too big). Pasting yourprinter.cfgis not needed Be sure to check our “Knowledge Base” Category first. Most relevant items, e.g. error messages, are covered there
Describe your issue:
so I made a new klipper system on the rpi with the image writer from raspberry. mainsail is what I used so I stick with that.
I configured the make menuconfig with the correct processor and q and saved it
I then checked the ls /dev/serial/by-id/ and wrote down the serial number. What I did not realised at the time is that this already means that the pi can communicate with the mcu but I followed the instructions and then noticed this bit about flashing the mcu with the klipper.bin
I copied this file onto an sd card and renamed this file firmware.bin.
I poked it in the octopus and restarted this.
Since then the rpi cannot find the mcu anymore.
I checked the sd card and this firmware.bin is now called firmware.cur, so it has done something with it.
How do I now proceed to correct this error? I am rather far out of my comfortzone with these firmware issues and haven’t done it often enough to be certain of what I do. This will be my first klipper that I build myself from near scratch.
While you’re at it, I’d recommend switching to Katapult.
Use the same settings as you would for building Klipper.
Build the deployer app.
Copy it to the SD card and let it flash.
If it was successful, the board should appear in dmesg with:
[171231.030762] cdc_acm 6-1:1.0: ttyACM1: USB ACM device
[171251.791634] usb 6-1: USB disconnect, device number 3
[171253.119422] usb 6-1: new full-speed USB device number 4 using ohci-platform
[171253.354492] usb 6-1: New USB device found, idVendor=1d50, idProduct=6177, bcdDevice= 1.00
[171253.354542] usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[171253.354562] usb 6-1: Product: stm32h723xx
[171253.354578] usb 6-1: Manufacturer: katapult
[171253.354593] usb 6-1: SerialNumber: 1B0029000151313433343333
[171253.358901] cdc_acm 6-1:1.0: ttyACM1: USB ACM device
Then build and flash Klipper with:
make flash FLASH_DEVICE=/dev/ttyACM1
Modify /dev/ttyACM1 according to the dmesg output.
Thank you @Sineos , I will have a long and hard look at this katapult first and then follow the instructions again. I am at work now but tonight after work I will start on this.
When building Katapult, you can also activate the LED on pin PA13. This has the nice effect of providing a visual indication when the board is in bootloader / Katapult mode.
Since the Octopus boards come in many flavors and revisions, make extra sure to select the correct one. Other than that, Katapult is nothing to be afraid of and it is straightforward to use.
My apologies for the lack of response. Life got in the way a bit and I have not had time nor energy to even look at it since your advice. It will happen, and this update is simply to keep the thread alive a bit longer, but it will be after easter holidays now.
Had I been more familiar with the process I might have found odd bits of time here and there, but honestly I think in my case it will be best if I start with enough time to proceed and finish.
Still your tips will be followed and are greatly appreciated, it will just take a short while longer.
Mayor edit!
I asked AI what could be wrong and it tolld me that I should compile the firmware.bin using my current klipper version. If you have updated the klipper and it had not yet any connection with the mcu, it will have mismatching versions.
So I recompiled the menuconfig directly from the pi running klipper, build the firmware.bin. shut down all and put this sd card in my laptop, extracted the firmware.bin file and reflashed my mcu with it. Now it connects.
So not sure what I did wrong exactly but clearly this katapult created my bin file without any knowledge of what klipper I was running and thus it did not recognise it.
All seems ok now so up to the next step, connecting the machine to the mcu and getting rid of all the errors.
Ignore below this unless you want to laugh at my inexperienced self induced chaos. If you laugh I will notice and you will owe me a beer
So I got back on this today and used katapult to produce me a menuconfig for my mcu. I had some initial trouble getting the board in dfu mode, but after I hooked it to my laptop and with the help of some AI I got it to respond to the jumper on boot0 together with the reset button for 3 seconds. I erased the chip on board and after that I flashed it with the firmware.bin via sd card. afterwards the sd card changed the name to firmware.cur. I think I am right in believing that this means it was successful at flashing it.
After that I installed mainsail for my rpi and configured it for ssh. I inserted it in the pi and did the startup. Found the new ip address and now I have mainsail on my browser. Happy days so far.
However as it threw the usual errors at me which I corrected, I mean the lack of the cfg file, homing file and so forth, it finally went past that and tried to connect to the mcu. This it failed and I searched for this error and my board setup but I cannot find relevant info.
Here is my klippy log as well, I am not sure if that helps but I am in the dark on that anyway. klippy(4).log (81.1 KB)
The machine is a voron v2.4 350
I have not yet set all the things in the cfg so some will be showing wrong things I am sure.
but basically I wanted to just see the mcu connected since this was my headache in the first place.
What am I doing wrong? O is the board bricked?
I have run a full update on klipper, forgot about that. But the issue is the same, here is the new klippy log klippy(5).log (137.7 KB)
I have to admit that I do not really follow through, but maybe some general remarks to get you back on track:
Katapult is a bootloader that will get the board into a state where it either accepts to be flashed with new software (Klipper firmware) or starts the already flashed software (also Klipper in our case).
Many boards have a built-in bootloader that cannot be changed and an additional software bootloader that can be changed. Naturally, Katapult can only be the latter. This is just for information.
Putting the board into DFU mode and flashing or flashing via SD card essentially yield the same result but are totally unrelated and unconnected processes.
If you either followed the correct DFU procedure or flashed the deployer.bin via SD card, it will erase the entire board and the board will start in Katapult bootloader mode, ready to be flashed with Klipper. Of course, flashing Klipper is mandatory in this case.
The error message
mcu 'mcu': Unable to open serial port: [Errno 2] could not open port /dev/serial/by-id/usb-Klipper_stm32f446xx_330005001650335331383520-if00: [Errno 2] No such file or directory: '/dev/serial/by-id/usb-Klipper_stm32f446xx_330005001650335331383520-if00'
indicates that Klipper is probably not correctly flashed. Follow these steps:
Build Katapult with the same settings as you would Klipper, including the “Deployer App”.
Copy the deployer.bin as firmware.bin to your SD card and reboot the board. It should change to firmware.cur.
If not, then put the board into DFU mode (verify with the lsusb command) and execute (you might need a reset afterwards):
sudo dfu-util -a 0 -D ~/katapult/out/katapult.bin --dfuse-address 0x08000000:force:mass-erase:leave -d 0483:df11
Execute sudo dmesg and find your board. It should read “Katapult” now.
Yes the mcu was not flashed correctly although it worked from the *.cur file point of view, the version was wrong.
I now think I misunderstood the katapult thing and did not correctly proceeded with the klipper installation. so by doing the two sperately, i.e. one from katapult and the other with the raspberry pi imager, the two were not related as such and could not cummunicate. I did not fully understand they have to be related to work together, something learned again.
I solved this by recompiling the menuconfig directly from the rpi and create a new flash file to put on a sd card and reflash the mcu.
So although I started with katapult, I did not finish with it and reverted back to the old way.
It does now work and I only have to connect everything to my controler to get rid of the out of range errors.
After that I can pick up the cfg building process and start looking at how to flash my can, u2c and my cartographer.
Even so I did not fully use the katapult correctly, your advise was spot on and helped me feeling confident enough to tackle this. You have no idea how far this old machine engineer is outside his comfortzone doing this firmware business. I used up all my free question tokens on all the AI registrations I have. And after that my brother had to play helpdesk too.
But I feel I learned some things today, and that is the takeaway of it all.
I do have a spare pi5 and a spare spyder board which I may subject to a day of test using klipper all the way through and for both mcu and the pi. For now I am just happy this has resulted in a pi that talks with my board. I was really scared I destroyed my controler board.
Thanks again and forwards to the next step, the wiring conection to the board.
As I marked this thread as solved already. if I run into new problems I will start a new thread if I have to.
