Printer Model: Ender 3 v2
MCU / Printerboard: STM32 f103chip , 4.2.2 board
Linux Mint: Linux SERVER-CED 5.15.0-101-generic #111-Ubuntu SMP Tue Mar 5 20:16:58 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
Describe your issue:
I can neither flash nor find the MCU of my board on the computer.
I have tried the debian bullseye fix, brittly and modemanager and i still cant find anything to make it work. Linux_debugging.zip (29.7 KB)
Linked my klippy log and my dmesg.txt file if you can find anything worthwile, im a few days away from buying a new motherboard T_T
Okay i managed to make it work… i reflashed my board at least 5 times but i was always still getting back a .bin so i was thinking that it wasn’t working… So i gave up, plugged the printer and when i went to mainsail in my printer.cfg it detected a serial device so i just put the full path in the MCU. it looks like this:
[mcu]
serial:/dev/serial/by-path/pci-0000:00:1a.0-usb-0:1.1:1.0
It is by path tho, but i don’t plan on restarting it so i don’t mind so far.
The general way to find a USB serial port is to run ls /dev/serial/by-id/* from an ssh terminal on the host machine. It will likely produce output similar to the following:
The name found in the above command is stable and it is possible to use it in the config file and while flashing the micro-controller code. For example, a flash command might look similar to:
sudo service klipper stop
make flash FLASH_DEVICE=/dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
sudo service klipper start
Be sure to copy-and-paste the name from the “ls” command that you ran above as the name will be different for each printer.
If you are using multiple micro-controllers and they do not have unique ids (common on boards with a CH340 USB chip) then follow the directions above using the command ls /dev/serial/by-path/* instead.
Just to leave a comprehensive picture here. Linux creates multiple endpoints for such aboard:
/dev/ttyXXX → Unstable, depends on the sequence of enumeration
/dev/serial/by-path/... → Quite stable, depends on the used USB port
/dev/serial/by-id/... → Highly stable, but might lead to collisions if multiple devices with the same serial, e.g. CH34x, FTDI, etc, are connected
If No 2 is created then there is usually No 3 present as well and I’m currently not aware of any constellation that would spoil this (except multiple devices that produce the same serial)