camera issues - drivers and hubs

[jattie-ire]

I believe I figured what the specific manifestation on my printer is that causes the camera failures, but I am out of my depths trying to figure our how the services and drivers work on the Creality K1 busybox Linux implementation and was hoping to gain some deeper insights from the participants here since I cannot piece this together from web searches or chatgpt.

So listing the usb devices using "lsusb" and "lsusb -t" and dmesg I identified the failing device as the Linux foundation root hub. This then causes the camera disconection since it runs through the hub. The hub reconnects up to 25 times and then finally terminates.

root@creality /root [#] lsusb
Bus 001 Device 003: ID 0c45:6366 Microdia
Bus 001 Device 005: ID 1a86:55d3 QinHeng Electronics USB2.0 Hub
Bus 001 Device 002: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
root@creality /root [#] lsusb -t
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 1: Dev 5, If 0, Class=Communications, Driver=cdc_acm, 12M
        |__ Port 1: Dev 5, If 1, Class=CDC Data, Driver=cdc_acm, 12M
        |__ Port 3: Dev 3, If 0, Class=Video, Driver=uvcvideo, 480M
        |__ Port 3: Dev 3, If 1, Class=Video, Driver=uvcvideo, 480M
        |__ Port 3: Dev 3, If 2, Class=Video, Driver=uvcvideo, 480M

The driver for the hub is dwc2 and lives here:

root@creality /sys/bus/platform/drivers/dwc2 [#] ls
total 0
lrwxrwxrwx    1 root     root             0 May  1 20:36 13500000.otg_new -> ../../../../devices/platform/ahb2/13500000.otg_new
--w-------    1 root     root          4096 May  1 20:36 bind
--w-------    1 root     root          4096 May  1 20:36 uevent
--w-------    1 root     root          4096 May  1 20:36 unbind

• Any ideas on how to restart these drivers?
• Any Idea what the hub looks like and where I can find it? It's loosing power of communications, probably a dodgy cable.

[jattie-ire]

In case someone else has a similar camera fail manifestation, I found a workaround for my problem. I noticed a repeat pattern in dmesg:

2024-05-04T22:13:08,480274+01:00 usb 1-1.1: USB disconnect, device number 5
2024-05-04T22:13:10,982365+01:00 usb 1-1.1: new full-speed USB device number 6 using dwc2
2024-05-04T22:13:11,076081+01:00 usb 1-1.1: New USB device found, idVendor=1a86, idProduct=55d3
2024-05-04T22:13:11,083501+01:00 usb 1-1.1: New USB device strings: Mfr=0, Product=2, SerialNumber=3
2024-05-04T22:13:11,091567+01:00 usb 1-1.1: Product: USB Single Serial
2024-05-04T22:13:11,096640+01:00 usb 1-1.1: SerialNumber: 5719024095
2024-05-04T22:13:11,102844+01:00 cdc_acm 1-1.1:1.0: ttyACM0: USB ACM device
2024-05-04T22:13:11,296147+01:00 usb 1-1.1: USB disconnect, device number 6
2024-05-04T22:13:12,006453+01:00 usb 1-1.1: new full-speed USB device number 7 using dwc2
2024-05-04T22:13:12,262395+01:00 usb 1-1.1: new full-speed USB device number 8 using dwc2
2024-05-04T22:13:12,356066+01:00 usb 1-1.1: New USB device found, idVendor=1a86, idProduct=55d3
2024-05-04T22:13:12,364738+01:00 usb 1-1.1: New USB device strings: Mfr=0, Product=2, SerialNumber=3
2024-05-04T22:13:12,372593+01:00 usb 1-1.1: Product: USB Single Serial
2024-05-04T22:13:12,377626+01:00 usb 1-1.1: SerialNumber: 5719024095
2024-05-04T22:13:12,383082+01:00 cdc_acm 1-1.1:1.0: ttyACM0: USB ACM device
   .
   .
   .  

2024-05-04T23:20:40,980744+01:00 usb 1-1.1: USB disconnect, device number 34
2024-05-04T23:20:41,190816+01:00 usb 1-1.1: new full-speed USB device number 35 using dwc2
2024-05-04T23:20:41,352501+01:00 usb 1-1.1: New USB device found, idVendor=1a86, idProduct=55d3
2024-05-04T23:20:41,359884+01:00 usb 1-1.1: New USB device strings: Mfr=0, Product=2, SerialNumber=3
2024-05-04T23:20:41,367825+01:00 usb 1-1.1: Product: USB Single Serial
2024-05-04T23:20:41,372778+01:00 usb 1-1.1: SerialNumber: 5719024095
2024-05-04T23:20:41,395599+01:00 cdc_acm 1-1.1:1.0: ttyACM0: USB ACM device
2024-05-04T23:20:52,821288+01:00 helix-venc 13200000.helix: h264 stop streaming !
2024-05-04T23:20:52,829923+01:00 helix-venc 13200000.helix: [1] encoder release
2024-05-04T23:20:52,840863+01:00 helix-venc 13200000.helix: h264 stop streaming !
2024-05-04T23:20:52,850300+01:00 helix-venc 13200000.helix: [2] encoder release
2024-05-04T23:20:52,856225+01:00 helix-venc 13200000.helix: jpgd stop streaming !
2024-05-04T23:20:52,864671+01:00 helix-venc 13200000.helix: [0] encoder release
2024-05-04T23:20:53,879409+01:00 dwc2 13500000.otg_new: dwc2_hc_halt() Channel can't be halted
2024-05-04T23:26:22,404453+01:00 usb 1-1: clear tt 1 (9232) error -145
2024-05-04T23:26:23,407644+01:00 usb 1-1: clear tt 1 (9232) error -145
2024-05-04T23:26:24,411790+01:00 usb 1-1: clear tt 1 (9232) error -145
2024-05-04T23:26:25,415666+01:00 usb 1-1: clear tt 1 (9232) error -145

A USB port was connecting and disconnecting untill the camera eventually went dead.

using lsusb I figured out some hub was doing this:

root@creality /root [#] lsusb
Bus 001 Device 003: ID 0c45:6366 Microdia
Bus 001 Device 004: ID 1a86:55d3 QinHeng Electronics USB2.0 Hub
Bus 001 Device 002: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
root@creality /root [#] lsusb-t
-sh: lsusb-t: not found
root@creality /root [#] lsusb -t
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 1: Dev 4, If 0, Class=Communications, Driver=cdc_acm, 12M
        |__ Port 1: Dev 4, If 1, Class=CDC Data, Driver=cdc_acm, 12M
        |__ Port 3: Dev 3, If 0, Class=Video, Driver=uvcvideo, 480M
        |__ Port 3: Dev 3, If 1, Class=Video, Driver=uvcvideo, 480M
        |__ Port 3: Dev 3, If 2, Class=Video, Driver=uvcvideo, 480M

I then searched for cdc_acm in logs and startup scrips and found this log file:

root@creality /root [#] tail -30 /usr/data/creality/userdata/log/device_manager.log|grep '^\['
[2024/05/05-17:14:07:777128]-[INFO]-[device_manager.c](494) laser_set_state: ubus_notify: {"laser_plugged":1}
[2024/05/05-17:16:39:556308]-[INFO]-[device_manager.c](494) laser_set_state: ubus_notify: {"laser_plugged":0}
[2024/05/05-17:16:40:144833]-[INFO]-[device_manager.c](494) laser_set_state: ubus_notify: {"laser_plugged":1}
[2024/05/05-17:19:53:621928]-[INFO]-[device_manager.c](494) laser_set_state: ubus_notify: {"laser_plugged":0}
[2024/05/05-17:19:54:165546]-[INFO]-[device_manager.c](494) laser_set_state: ubus_notify: {"laser_plugged":1}
[2024/05/05-17:20:12:583265]-[INFO]-[device_manager.c](494) laser_set_state: ubus_notify: {"laser_plugged":0}
[2024/05/05-17:20:13:109338]-[INFO]-[device_manager.c](494) laser_set_state: ubus_notify: {"laser_plugged":1}
[2024/05/05-17:23:56:818023]-[INFO]-[device_manager.c](494) laser_set_state: ubus_notify: {"laser_plugged":0}
[2024/05/05-17:23:57:432453]-[INFO]-[device_manager.c](494) laser_set_state: ubus_notify: {"laser_plugged":1}
[2024/05/05-17:43:55:628174]-[INFO]-[device_manager.c](494) laser_set_state: ubus_notify: {"laser_plugged":0}
[2024/05/05-17:43:56:140360]-[INFO]-[device_manager.c](494) laser_set_state: ubus_notify: {"laser_plugged":1}

The hub failures coincides with the laser plug state changes, so I unplugged the laser and lo and behold, the problem went away.

So it looks like the hub, "Bus 001 Device 004: ID 1a86:55d3 QinHeng Electronics USB2.0 Hub" is actually inside the laser sensor and is in fact a single usb to serial device. It looks like this device connects and disconnects causing all cameras to eventually fail.