If I’m not mistaken the error “Timeout on connect → Serial connection closed” really means Klipper is
If I’m correct that means klipper firmware is not running on the MCU. The creality 4.2.2 board is notoriously dificult to flash.
Add to that the GD32F330 is not a “mainstream” MCU.
Sorry, your “serial connection port” is wrong.
In your latest klippy.log (klippy_01.20.log)
Line 215: serial = /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0
.
.
Line 280: mcu 'mcu': Unable to open serial port: [Errno 13] could not open port /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0: [Errno 13] Permission denied: '/dev/serial/by-id/usb-1a86_USB_Serial-if00-port0'
I am not sure if difficult to flash is right. Every time I flash a firmware it seems to work as expected, blank screen really being the only clue. I have flashed back to stock firmware a few times without issue. The two frustrating things is that without the serial connection there is no good way to tell other than a blank screen which is advised to unplug anyway.
The real killer seems to be silent board changes that make firmware building a crapshoot with limited ways to figure out what is going on. Maybe I just need to keep working through the firmware options and hoping for the best.
I do not understand.
dietpi@DietPi:~$ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 1a86:7523 QinHeng Electronics CH340 serial converter
Bus 001 Device 003: ID 0bda:8179 Realtek Semiconductor Corp. RTL8188EUS 802.11n Wireless Network Adapter
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
dietpi@DietPi:~$ ls /dev/serial/by-id/*
/dev/serial/by-id/usb-1a86_USB_Serial-if00-port0
Long shot but I asked Copilot (AI) to search out information on flashing Creality 4.2.2 boards. It claims that GD32f330 is fundamentally different in that it has an onboard USB interface not a CH430 USB<>Serial chip.
If Copilot is correct that could explain a lot of issues.
So try this
Copilot also has opinions on file names for flashing this board.
Not sure I believe that since lsusb shows a CH340 as the printer then again dmesg shows it as a CH341?
I am willing to give it a shot, but the AI output doesn’t track with what I see.
dietpi@DietPi:~$ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 1a86:7523 QinHeng Electronics CH340 serial converter
Bus 001 Device 003: ID 0bda:8179 Realtek Semiconductor Corp. RTL8188EUS 802.11n Wireless Network Adapter
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
[ 3829.604434] usb 1-1: USB disconnect, device number 2
[ 3829.606006] ch341-uart ttyUSB0: ch341-uart converter now disconnected from ttyUSB0
[ 3829.606192] ch341 1-1:1.0: device disconnected
[ 3831.091906] usb 1-1: new full-speed USB device number 4 using xhci_hcd
[ 3831.229845] usb 1-1: New USB device found, idVendor=1a86, idProduct=7523, bcdDevice= 2.64
[ 3831.229892] usb 1-1: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[ 3831.229914] usb 1-1: Product: USB Serial
[ 3831.234950] ch341 1-1:1.0: ch341-uart converter detected
[ 3831.236436] usb 1-1: ch341-uart converter now attached to ttyUSB0
That’s yours. CH340 and CH341 have even the same datasheet. Just connect and disconnect to make sure.
Do yourself a favor and forget that crap…
I did try that make menuconfig for shits and giggles and got no change.
Two things that bug me is that most of the printer.config files have this alternative section about “If you prefer a direct serial connection”. Like who knows? It isn’t addressed in the Klipper docs that i can find. I don’t know if I prefer that or if the board needs that, but it sure seems recommended most often. THe second thing is that the GD chips are rarely mentioned despite how ofteh they seems to have been used. The only ender 3 config I found that mentioned it was the ender 3 pro.
So yeah, I will try to flash again with USART1 PA10/PA9 and USART3 PB11/PB10 and report back.
If you have a PC with a real serial port or want to run RS232 over 2 GPIO pins on your PI then you need that. In your case you would need a USB dongle (with a 9 pin out in most cases) to bypass the onboard CH340. Might work but I’d put the $ toward a new mainboard (BTT SKR mini is a drop in upgrade). I don’t know anyone using “direct serial”. Even boards with the host and MCU on the same circuit board use USB.
I can mark this solved!
The issue was with dietpi and the lack of group inheritance of the dialout group!
I reflashed with the USART1 PA10/PA9 and have a MCU connection!!
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
