Multicontainer UART logging program keeps RPi from booting up

I have a multi container project, where one of the containers is a UART datalogger that is going to log data from an external UART device. If the UART device, right now it is a PC with a USB-serial connection, is connected then the RaspberryPi3 will not boot up.

However, if I disconnect the UART TX and RX and cycle the power on the RaspberryPi3 it will boot up and all the containers will work correctly. Then if I connect the UART TX and RX lines it will log the data as programmed.

This same set of programs works fine if I build it directly on a SD card with just Raspbian on it it will boot up and work fine with the UART RX and TX connected.

Does anyone have any idea why having the UART RX and TX lines connected during boot up will cause it to fail to boot?

Hey,

Is it possible that the PC is sending some data when the Pi boots and somehow interupting the bootloader process?

The PC isn’t, but the device I want to connect will be sending data from the start.

Since this works on when I do it on a basic Raspbian install, how can I make it work with Balena?

I can send the code if needed. It is just a simple serial to file logger application.

Hi, on what OS version do you have this problem?

balenaOS 2.43.0+rev1

Hi Matt

So we think this might be a regression on our side, we are investigating and tracking it with https://github.com/balena-os/balena-raspberrypi/issues/438

In the meantime, we have 2 options:

  1. you might want to use the production version of balenaOS, rather than the development version: in the production version, uboot delay time is set to zero, so that only by sending the equivalent of CTRL+C uboot will be halted. Maybe this is enough to keep you moving forward with your project.
  2. you can try using a previous version of balenaOS, like v2.38: this would help us confirm it’s a regression

Best regards

federico

@mdcraver you could also take a look at this thread: Pi3 wont boot 2.43.0 (Dev) with a Adafruit hat installed

There is confirmation in this thread that if you try v2.44 from production the issue is resolved.

Switching to the production version of the os and enabling the UART in the device configuration worked.

Thanks,
Matt

Hi, this is now released to production in 2.46.1+rev1