[Rozwiązany] OctoPrint suddenly disconnecting, micro-usb going bad?  

OctoPrint suddenly disconnecting, micro-usb going bad?

Can the MINI's micro-usb port just go bad?  Yesterday my Pi running OctoPrint suddenly started disconnecting from my MINI.  I can get it to reconnect right after I restart the MINI but then it disconnects a few seconds later. As far as I know of nothing changed on OctoPrint but I am running the 4.3.3 RC firmware on my MINI to get the customer extruder eStep configuration.  I haven't dropped/bumped/etc. my printer to physically damage the port.  The only thing I've done is had the hotend getting to 270 a number of times because I removed the Bondtech heatbreak and put back the original one and I had to clear out a clog.  I've tried multiple USB cables and different ports on the rPi, all of them behaved the same.

OctoPi: Version 0.18.0, running on Raspberry Pi 4 Model B Rev 1.4
OctoPrint: Version 1.6.1

Here is the log from OctoPrint:

Changing monitoring state from "Offline" to "Detecting serial connection"
Performing autodetection with 1 port/baudrate candidates: /dev/ttyACM1@115200
Trying port /dev/ttyACM1, baudrate 115200
Handshake attempt #1 with timeout 2.0s
Connected to: PackingSerial<id=0xade96b50, open=True>(port='/dev/ttyACM1', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=2.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
Send: N0 M110 N0*125
Recv: echo:  G21    ; Units in mm (mm)
Recv: 
Handshake attempt #2 with timeout 2.0s
Send: N0 M110 N0*125
Recv: echo:Filament settings: Disabled
Recv: echo:  M200 D1.75
Recv: echo:  M200 D0
Recv: echo:Steps per unit:
Recv: echo: M92 X100.00 Y100.00 Z400.00 E415.00
Recv: echo:Maximum feedrates (units/s):
Recv: echo:  M203 X180.00 Y180.00 Z12.00 E80.00
Recv: echo:Maximum Acceleration (units/s2):
Recv: echo:  M201 X1250.00 Y1250.00 Z400.00 E4000.00
Recv: echo:Acceleration (units/s2): P<print_accel> R<retract_accel> T<travel_accel>
Recv: echo:  M204 P1250.00 R1250.00 T1250.00
Recv: echo:Advanced: B<min_segment_time_us> S<min_feedrate> T<min_travel_feedrate> X<max_x_jerk> Y<max_y_jerk> Z<max_z_jerk> E<max_e_jerk>
Recv: echo:  M205 B20000.00 S0.00 T0.00 X8.00 Y8.00 Z2.00 E10.00
Recv: echo:Home offset:
Recv: echo:  M206 X0.00 Y0.00 Z0.00
Recv: echo:Auto Bed Leveling:
Recv: echo:  M420 S0 Z0.00
Recv: echo:PID settings:
Recv: echo:  M301 P7.00 I0.50 D45.00 C0.01
Recv: echo:  M304 P120.00 I1.50 D600.00
Recv: echo:Z-Probe Offset (mm):
Recv: echo:  M851 X-29.00 Y-3.00 Z0.00
Recv: echo:Stepper driver current:
Recv: echo:  M906 X350 Y350 Z350
Recv: echo:  M906 T0 E400
Recv: 
Handshake attempt #3 with timeout 2.0s
Send: N0 M110 N0*125
Recv: echo:Driver stepping mode:
Recv: echo:  M569 S1 X Y Z
Recv: echo:Linear Advance:
Recv: echo:  M900 K0.00
Recv: echo:Filament load/unload lengths:
Recv: echo:  M603 L320.00 U420.00
Recv: //action:prompt_end
Recv: Testing X connection... OK
Recv: Testing Y connection... OK
Recv: Testing Z connection... OK
Recv: Testing E connection... OK
Recv: echo:Unknown command: "start"
Changing monitoring state from "Detecting serial connection" to "Operational"
Send: N0 M110 N0*125
Recv: ok
Send: N1 M115*39
Communication timeout while idle, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
Send: N2 M92 E415*79
Communication timeout while idle, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
[...]
No response from printer after 3 consecutive communication timeouts, considering it dead. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
Changing monitoring state from "Operational" to "Offline after error"
Connection closed, closing down monitor