Serial connection fails after first use

What is the problem?

I have octoprint on a pi 4B (and previously a 3B+) connected to a custom built printer using an SKR 2 mainboard, via UART serial (not USB).
I noticed that when the pi is initially turned on and octoprint starts, it automatically connects to the printer OK. If I select 'Disconnect' and then attempt to reconnect, it would get stuck on "opening serial connection" and nothing would happen.

Attempting to diagnose the problem I booted octoprint into safe mode. It now fails to connect every time (even when starting octoprint) and I get this error:

Unexpected error while connecting to serial port /dev/ttyS0, 
baudrate 115200 from hook default: 
error: '(22, 'Invalid argument')' @ comm.py:_open_serial:3836

I found now that even restarting octoprint back into normal mode would now generate the same above error. I would have to completely power the pi down and reboot it (restart system) in order to get it to initially connect, and then hang on "opening serial connection" on the 2nd attempt again.

This pi is on a printer that I haven't finished building or started using yet. I initially noticed this problem (but didn't try and fix it) maybe a month or 2 ago using a pi 3B+ (that I already had laying around), that used a fresh SD card flash of octopi with octoprint 1.8.1.
When attempting to connect some accessories to my pi I accidently shorted and damaged a GPIO pin. I then recently swapped out the 3B+ with a brand new pi 4B, and reflashed the new SD card with the same octopi image. I restored an octoprint backup I had created from the 3B+ and reconfigured the rest manually (such as enabling serial using raspi-config). And updated octoprint to 1.8.5 via the notification when it boots up.
It appears the same problem has followed me, so possibly a problem that's created by 1.8.1 and not fixed in the updates?
I believe its the same as this unresolved problem: Octoprint not connecting via /dev/ttyS0 after upgrade to 1.8.1

What did you already try to solve it?

I have an oscilloscope and confirmed that the pi's TX line has data on it when it connects. However when I press disconnect and then reconnect, there is NOTHING transmitted when I hit reconnect.

I've confirmed powering down the mainboard after disconnecting (but leaving octoprint running), and then powering it back up before attempting to reconnect makes no difference.

I've logged in via SSH and installed minicom on the pi. Bridging the Pi's TX/RX pins, I can see all the letters I type echoed back at me using both /dev/tty0 and /dev/serial0. This is after octoprint wont connect (the problem has started). It seems minicom works with the serial pins fine but octoprint wont.

I added /dev/serial0 to the list in octoprint and attempted to connect with that instead, but it made no difference.

Have you tried running in safe mode?

Yes, the terminal then shows the above error. And it continues to show that error even after restarting octoprint back to normal mode. It only stops showing that error after rebooting the entire system.

Did running in safe mode solve the problem?

No, it made it worse (wouldn't even connect the first time).

Systeminfo Bundle

Norman mode (hangs on "opening serial connection"):
octoprint-systeminfo-20221018093325_normal mode.zip (72.1 KB)
When in safe mode:
octoprint-systeminfo-20221018093911_safemode.zip (74.0 KB)

Additional information about your setup

OctoPrint version 1.8.5
OctoPi version 0.18.0
Printer: Custom built cartesian
Firmware: Marlin
Browser: Chrome/Brave
Operating system: Windows

I guess my next option was to download a complete new image of octopi 0.18.0/octoprint 1.8.5 and start from scratch without restoring a backup.
However I'm not 100% sure it will fix it and would like to avoid that if possible.

Thanks in advance

Please try if setting Settings > Serial Connection > General > Connection > Apply parity double open workaround to "never" helps:

Also, /dev/ttyS0 rang some alarm bells in my head, so I did a quick google and that unearthed this:

1 Like

Parity double open workaround to "never" made no difference.

I tried adding /dev/ttyAMA0 to the list and using it, and it seems to get further than before. It now changes from "opening serial connection" to "connecting" and I get the following output:

Changing monitoring state from "Offline" to "Opening serial connection"
Connecting to port /dev/ttyAMA0, baudrate 115200
Changing monitoring state from "Opening serial connection" to "Connecting"
Connected to: Serial<id=0xb0668c70, open=True>(port='/dev/ttyAMA0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
Send: N0 M110 N0*125
No answer from the printer within the connection timeout, trying another hello
Send: N0 M110 N0*125
There was a timeout while trying to connect to the printer
Changing monitoring state from "Connecting" to "Offline"
Connection closed, closing down monitor

However as you can see it doesn't actually connect.

I found it doesn't connect at all using AMA0 (even on initial power up). And setting parity double open workaround back to "if potentially needed" doesn't help either.

I have included dtoverlay=disable-bt in /boot/config.txt as well

For now I have switched to using a USB cable. Using the UART pins would of been nice to keep the wiring neat and tidy but it seems its going to be more work than its worth. I've still got the UART wiring in place and can easily test any other potential fixes if anyone has any, but I'm out of ideas (other than starting from scratch with a new octopi flash, which I'm worried wont fix the problem anyway and be a massive waste of time).

Thanks

I'm going to ask the stupid question... You are connecting TX to RX and RX to TX?

Yes definitely. As described above it does connect sometimes (on initial boot only). If the pins were backwards it wouldn't connect at all.

I've bene using the USB cable for a couple of weeks now with no issue, so will continue with USB at this stage.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.