I'm still seeing a lot of garbled communication even in the handshake. Something is up either with your USB cable or the controller itself if this persists even across firmware flashes.
Just for comparison, this is what's going over serial should look like when connecting:
Changing monitoring state from "Offline" to "Opening serial connection"
Connecting to port /dev/ttyACM0, baudrate 115200
Changing monitoring state from "Opening serial connection" to "Connecting"
Connected to: Serial<id=0x72810430, open=True>(port='/dev/ttyACM0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
Send: N0 M110 N0*125
Recv: ok
Send: N0 M110 N0*125
Changing monitoring state from "Connecting" to "Operational"
Recv: ok
Send: N0 M110 N0*125
Recv: ok
Send: N1 M115*39
Recv: FIRMWARE_NAME:Marlin 2.0.5.4 (GitHub) SOURCE_CODE_URL:https://github.com/MarlinFirmware/Marlin PROTOCOL_VERSION:1.0 MACHINE_TYPE:Ender-3-Pro EXTRUDER_COUNT:1 UUID:cede2a2f-41a2-4748-9b12-c55c62f367ff
Recv: Cap:SERIAL_XON_XOFF:0
Recv: Cap:BINARY_FILE_TRANSFER:0
Recv: Cap:EEPROM:1
Recv: Cap:VOLUMETRIC:1
Recv: Cap:AUTOREPORT_TEMP:1
Recv: Cap:PROGRESS:0
Recv: Cap:PRINT_JOB:1
Recv: Cap:AUTOLEVEL:1
Recv: Cap:Z_PROBE:1
Recv: Cap:LEVELING_DATA:1
Recv: Cap:BUILD_PERCENT:0
Recv: Cap:SOFTWARE_POWER:0
Recv: Cap:TOGGLE_LIGHTS:0
Recv: Cap:CASE_LIGHT_BRIGHTNESS:0
Recv: Cap:EMERGENCY_PARSER:0
Recv: Cap:PROMPT_SUPPORT:0
Recv: Cap:AUTOREPORT_SD_STATUS:0
Recv: Cap:THERMAL_PROTECTION:1
Recv: Cap:MOTION_MODES:0
Recv: Cap:CHAMBER_TEMPERATURE:0
Recv: ok
Send: M21
Recv: echo:SD card ok
Recv: ok
Send: M155 S2
Recv: ok
Send: M20
Recv: Begin file list
Recv: SKR-MI~1.GCO 176
Recv: End file list
Recv: ok
Recv: T:22.19 /0.00 B:23.44 /0.00 @:0 B@:0
Recv: T:22.81 /0.00 B:21.87 /0.00 @:0 B@:0
Your serial.log on the other hand has once again weirdly merged many of these lines, not even with missing EOFs but overwrites in the middle. And comparing two connect attempts it also looks like only a subset of lines is event being transmitted each time that varies. Something's broken here:
Changing monitoring state from "Offline" to "Opening serial connection"
Connecting to port /dev/ttyUSB0, baudrate 115200
Changing monitoring state from "Opening serial connection" to "Connecting"
Connected to: Serial<id=0xaf131ed0, open=True>(port='/dev/ttyUSB0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
Recv: start
Recv: echo:Marlin 1.1.9.1
Recv:
Send: N0 M110 N0*125
Recv: echo:start <-- printer boots twice?!
Recv: echo:Marlin 1.1.9.1
Recv:
Recv: echo: Last Updated: 2020-06-20 | Auths: 1232 <-- garbled
Recv: echo:V56 stored settings retrieves; crc 51462) <-- garbled
Recv: echo: G21 ; (mm)
Recv: echo: M149 C ; Units in Cel
Recv: echo: M203 X500.00 Y500.00 Z10.00 E50.00
Recv: echo:Maximum Acceleraanced: Q<min_segment_time_us> S<min_feedrate> T<min_travel_feedr:Material heatup parameters:
^-- garbled
Recv: echo: M145 S0 H185 B45 F255
Recv: echo: echo:SD init fail
There was a timeout while trying to connect to the printer <-- OctoPrint gives up since no ok was ever received
Changing monitoring state from "Offline" to "Detecting serial connection"
Performing autodetection with 6 port/baudrate candidates: /dev/ttyUSB0@115200, /dev/ttyS4@115200, /dev/ttyS3@115200, /dev/ttyS1@115200, /dev/ttyS0@115200, /dev/ttyS2@115200
Trying port /dev/ttyUSB0, baudrate 115200
Connecting to port /dev/ttyUSB0, baudrate 115200
Handshake attempt #1 with timeout 2.0s
Connected to: Serial<id=0xa50b0230, open=True>(port='/dev/ttyUSB0', 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: start
Changing monitoring state from "Detecting serial connection" to "Operational"
Recv: echo:Marlin 1.1.9.1
Recv:
Send: N0 M110 N0*125
Recv: echo:start <-- printer boots twice?!
Recv: echo:Marlin 1.1.9.1
Recv:
Recv: echo: Last Updated: 2020-06-20 | Author: (thisiskeithb, Ender-3)
Recv: echoecho:V56 stored settings retrieved (656 bytes; crc 51462)
^-- garbled
Recv: echo: echo: M200 D0 <-- garbled
Recv: echo:Steps per unit:
Recv: echo: M92 X80.00 Y80.00 Z40ration (units/s2): P<print_accel> R<retract_accel> T<travel_acce
^-- garbled
Recv: echo: M205 Q20000 S0.00 T0.00 X20.00 Y20.00 Z0.30 E5.00
Recv: echo:H1.54 D76.55
Recv: echo:SD init fail
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: N1 M115*39
Recv: FIRMWARE_NAME:Marlin 1.1.9.1 (Github) SOURCE_CODE_URL:https://gi:0
^-- garbled
Recv: Cap:EEPROM:1
Recv: Cap:VOLUMETRIC:1
Recv: Cap:AUTOREPORT_TEMP:1
Recv: Cap:PROGRCY_PARSER:0
Recv: Cap:AUTOREPORT_SD_STATUS:0
Recv: Cap:THERMAL_PROTECTION:1
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 ok from M115
Send: M21
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.
^-- M21 takes WAY too long, eject printer's SD?
Send: M105
Recv: echo:SD init fail <-- M21 fails, printer's SD either not there or broken
Recv: ok
Send: M155 S2
Recv: ok T:24.02 /0.00 B:25.00 /0.00 @:0 B@:0
One thing I noticed is that the M21 command ("init SD") seems to take very long. If you have an SD card in your printer, try ejecting it. If not, try putting one in (DOS formatted, known to be good and not faulty). We've had weird printer controller freakouts due to wonky SD cards before here.
