Raspberry Pi 4 uart link fails after approx 5s

The RPi 4 uart port (BCM14_TXD, BCM15_RXD) is connected to another device that is streaming uart chars at 115200 baud.
The following python script is manually launched from an ssh terminal, and it prints any chars that are available at uart RX:

import serial
serPort = serial.Serial(args["port"], args["baudRate"], timeout=100, parity='N', stopbits=1)

  while True:
    resp = serPort.readline()
    print(resp, flush=True)

The script is able to get a connection to the uart and print chars, but after some variable time (approx 5s) the connection is lost:

Traceback (most recent call last):
  File "./commRead.py", line 56, in <module>
    resp = serPort.readline()
  File "/usr/local/lib/python3.6/site-packages/serial/serialposix.py", line 596, in read
    'device reports readiness to read but returned no data '
serial.serialutil.SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?)

My config and symptoms are very similar to:

Update:
I switched from the development OS to the production OS, enabled the UART in the Device Config, and now the uart link appears to work perfectly.
This is great, but how do I get the uart working without dropouts when using the development image?

Hi

This is most likely because the development image uses serial for getty logs - please see the differences in prod vs dev images here

If you want to disable this feature of development images, take a look at our advances OS customization page. You should be able to edit the config.txt to make the required changes - for dev or prod images.

Thanks for the info.
I took a look at at Development vs. Production images, and it states that “Raspberry Pi devices don’t have Getty atached to serial”. Is this true?


I have tried modifying enable UART in the the device variables, and this did not make any difference.
Is this what you were referring to?

I really want to solve this problem, otherwise we will not be able to use Balena in our product.
I really like the concept of the product, but this is a serious sticking point.
The use of the serial port is central to updating firmware on attached devices. We have already built the first round of prototype hardware, so we would like to stick with using the ttyS0 serial port, but would life be easier if we used a different serial port?

Hi,

We’re using the ttyS0 successfully for serial communication on a Raspberry Pi 4.
The production image doesn’t use serial port for getty, so we can use it for the serial communication. However, the development images have getty attached to the serial as stated in the docs. So what we’re seeing is that on development images, there’s action on the ttyS0 because of getty.

What you’re doing is right, you’ve to enable UART on the dashboard, but for every development image device, I run the following commands using SSH:

mount -o remount,rw /
systemctl mask serial-getty@ttyAMA0.service
systemctl mask serial-getty@serial0.service
systemctl mask serial-getty@serial1.service
reboot

After the reboot, the getty isn’t attached anymore.
Hopefully this will fix the issue for you as well!

2 Likes

Yes, the uart port now works in development os. Thank you!
I had to issue the systemctl commands from the web interface Host_OS terminal. I did try ssh’ing into the app but sytemctl was not available. Should I have ssh’d into the Host_OS?

The Host OS terminal in the web interface is essentially the same as SSH’ing into the device into the Host OS. So doesn’t really matter if you did it via the web interface or just plain SSH.

Via the app doesn’t work, because that’s a container running on top of the Host OS.

You only have to do this once on the development image, on production images isn’t necessary because getty is attached to the serial there.

But glad that it worked!

1 Like

Glad that this got sorted!

Thanks for chiming in with the useful feedback @bversluijs!

Another possible approach is to disable the console directly from the container at runtime using dbus. Posted my findings here: