Serial comms fail on UNO Q

Official Hardware UNO Family UNO Q
1

Hi everyone,

I'm having trouble establishing basic serial communication between an Arduino Uno Q and a 3.3V GSM AT modem. It seems the RX (Pin 0) line is being held low, which is preventing proper UART signaling.

To better illustrate the issue, here are the results of two very simple test sketches:

TEST 1 – TX Pin Behavior

void setup() {
  Serial.begin(9600);
}

void loop() {
  Serial.write(0x55);
  delay(1000);
}

With this code, Pin 1 (TX) behaves as expected: it sits at 3.3V idle, and an oscilloscope shows a valid UART waveform during transmission.

TEST 2 – RX Pin Behavior

void setup() {
  Serial.begin(9600);
}

void loop() {
  delay(1000);
}

In this case, I only have a voltmeter connected to Pin 0 (RX). When the MCU is idle (empty loop), the pin measures ~0.2V, whereas I would expect it to idle HIGH (~3.3V) for UART.

Questions:

  • Is the low idle voltage on Pin 0 intentional, perhaps due to some internal connection with the onboard Linux MPU or the Monitor object?

  • What is the recommended approach for using the RX pin with external UART peripherals on the Uno Q?

  • Could this indicate a problem with my board, or is this expected behavior?

Any guidance or clarification would be greatly appreciated!

Thanks in advance.

2

Subject: Issue Report: Floating RX (Pin 0) Causes Serial Instability and MCU Crashes on Arduino UNO Q

Dear Arduino Support Team,

Further to my last post - I think I have encountered an issue with the Arduino UNO Q that appears to affect the stability of serial communication on pin 0 (RX) and occasionally causes the microcontroller (MCU) to crash during boot.

Summary of Issue

  • The RX pin (pin 0) on the UNO Q is observed to float at around 0.2 V on power-up.

  • This appears to cause false data input or undefined behavior during early boot stages – occasionally leading the MCU to crash or the sketch to behave unexpectedly (while the MPU/Linux side continues running normally).

  • Adding the following line as the first instruction in setup() prevents the MCU crash:

    pinMode(0, INPUT_PULLUP);

    However, enabling this pull-up prevents successful communication with a GSM modem connected to the hardware UART (Serial).

  • Curiously, after deploying a sketch with the pull-up enabled, I can then remove the pull-up, redeploy, and serial communication with the GSM modem works as expected — until the entire system (including MCU and MPU) is fully powered down and rebooted.

Hardware Observations

  • Measured voltage:

    • Pin 0 (RX) floats at ~0.2 V on idle unless pull-up is applied.

    • Pin 1 (TX) idles correctly at 3.3 V.

  • On a standard UNO R3, both pins idle at expected Vcc level (5 V on traditional boards, 3.3 V on 3.3 V variants).

  • Resistance measurement between RX/TX and GND is approximately 1.9 MΩ when idle.

Steps to Reproduce

  1. Deploy a sketch that uses Serial.begin() and communicates with an external GSM modem via UART.

  2. Observe that on a cold boot (Linux system power-cycled), pin 0 idles at ~0.2 V, and the MCU fails to boot or crashes.

  3. Adding pinMode(0, INPUT_PULLUP) at the first line of setup() prevents the MCU crash, but breaks GSM communication.

  4. If the pull-up is subsequently removed and the sketch redeployed without power cycling, the UART communication with the GSM modem works reliably.

Expected Behavior

  • RX (pin 0) should idle high (3.3 V) by default.

  • The MCU should not require manual intervention on RX configuration to avoid boot issues.

  • Serial communication via Serial should operate reliably with external peripherals such as GSM modems.

Request for Clarification / Fix

  • Is the floating RX pin an oversight in the hardware design?

  • Is there a bootloader or firmware configuration that should initialize this pin to a known state?

  • Is there an official solution or recommended workaround for this issue?

3

Hey @johnnyw66, thanks for the detailed analysis!

Indeed, a missing pull-up on an input line can cause random noise to be picked up as edges; in particular the serial RX line may detect random characters - enough of them may then ultimately confuse the console.

Thanks for spotting this - it is definitely an oversight in the bootloader configuration which will be fixed with an update in the next few days. Enabling the pull-up with pinMode does unfortunately prevent further comms; we know the cause and are working to solve this as a separate issue.

The missing pull-up does NOT prevent the UART from working properly though, as it is the sender’s responsibility to drive pins HIGH in UART communication (they are push-pull, not open drain). So, when you connect a proper TX line, that will forcibly drive the pin HIGH when idle - it should definitely not be "held low" in that case.

Stay tuned for the next update! :hammer_and_wrench:

4

What you observed is intentional and does not prevent the Serial object from working. Our developers are preparing a patch to optimise the UART pins. The serial object is fully functional as long as you connect with a proper cable (like FTDI).

5

My experience with unrelated MCU boards is that if one has two MCUs communicating via UART one often cannot rely on the Tx to pull the line high fast enough because on power up these lines are generally always configured as inputs and there is a race condition between the two MCUs as to if the line would be pulled high before the Rx notices it is low. As a result my simple solution was to use a passive weak pullup that was not controlled by code. An actual large resistor pulling to the positive rail. This has negligible effect once the Tx line is actually configured but in the mean time keeps noise off the line. It is easy enough for a person to add this if/when it appears to be needed and it does not have to be part of the board design.