Arduino IDE 1.6.8, Arduino Due, Mac OS 10.11.3

I am seeing eight mysterious pulses on the RX line when I connect to the serial port using multiple client libraries (Python, JavaScript as well as the built-in Serial Monitor in the IDE). About 78-79us apiece, sampled at 1MS/s with a Logic Pro 16.

Mystery pulses

These eight pulses when interpreted at 57600 baud will jam the Firmata firmware. And they happen on every connection.

This is using a new install of the Arduino 1.6.8 IDE and with multiple sketches (the normal "Blink" sketch will reproduce this also).

Repro steps on my machine:

  1. Install any sketch
  2. Start a logic analyzer if you want to catch it
  3. Go to Serial Monitor. I have mine configured for 57600 baud, Newline line ending, but it doesn't matter
  4. If you want, close and repeat step 3
  5. Note pulses each time you connect to the serial port

Any suggestions for diagnosing this? It sounds like it's serial driver-level in some way.

  • 1
    Regardless of where it is coming from, consider that it has done you a favor by indicating a critical bug in the firmware you are running - this should not be able to put it in an unrecoverable state. Is it a program logic bug, or does the UART handling code not deal appropriately with an error flag? Mar 15, 2016 at 17:58
  • 1
    In terms of tracking down the source, it would be helpful to try another serial client program, another computer/operating system, another USB-serial device, etc... Mar 15, 2016 at 18:00
  • 1
    As for trying other serial programs, there are multiple libraries that interact with the Firmata protocol and use different underlying serial implementations (Python, JavaScript and the built in Arduino IDE Serial Monitor) that exhibit the same behavior. My next plan is to try this on a Linux machine and see if I see the same behavior, which will hopefully isolate if this is OS X-specific. Mar 16, 2016 at 3:24
  • 2
    You also get one when you disconnect. The connection baud rate has no effect on the length of the pulse. My suspicion is that it's the ATMega16U2's firmware that is doing it (or whatever chip it is on whatever version).
    – Majenko
    Mar 20, 2016 at 0:45
  • 1
    When you start the serial monitor, software resets the arduino module. If arduino module has bootloader in it, i think these are the STK500 protocol signals. May 10, 2017 at 11:22

1 Answer 1



Looking at the ATMEGA16U2 firmware (https://github.com/arduino/ArduinoCore-sam/blob/master/firmwares/atmega16u2/arduino-usbserial/Arduino-usbserial.c) I find that, when you configure/change settings of the USB emulated serial port, the USART is resetted. This happens even when you open the Arduino Serial Monitor (it must configure the serial speed, etc.). This causes your spike.


Look at function:

void EVENT_CDC_Device_LineEncodingChanged(USB_ClassInfo_CDC_Device_t* const CDCInterfaceInfo)

There you'll see that after some lines, it resets the USART, by zeroing its registers:

/* Must turn off USART before reconfiguring it, otherwise incorrect operation may occur */
    UCSR1B = 0;
    UCSR1A = 0;
    UCSR1C = 0;

At page 168, of the current ATMEGA16U2 datasheet, you'll find that, by setting UCSR1B's bit 3 (TXEN1), you enable the transmitter, overriding the normal port operation (i.e. it becomes output). Quoting the datasheet:

Writing this bit to one enables the USART Transmitter. The Transmitter will override normal port operation for the TxDn pin when enabled. The disabling of the Transmitter (writing TXENn to zero) will not become effective until ongoing and pending transmissions are completed, i.e., when the Transmit Shift Register and Transmit Buffer Register do not contain data to be transmitted. When disabled, the Transmitter will no longer override the TxDn port.

Therefore, by writing UCSR1B = 0; you no longer override the TXD1 pin, which will act as input.

The ATMEGA16U2 TXD is connected to the ATSAM3X8E's RX line. In normal operation, with the UART enabled, that line stays high if no data is being transmitted. If you disable the UART, that particular line is no more driver to 1. Since the initialization code does not set the pull-up on that pin (and neither it's configured as output), the pin becomes a floating input, and any leakage to GND or even the input impedance of your probe (which is between your pin and GND), will slowly bring the logic level to 0.

To override this, problem, you should either: 1) Modify ATMEGA16U2 firmware, by setting that PIN as OUTPUT, with value 1. 2) Modify ATMEGA16U2 firmware, by enabling the pull-up on that pin. 3) (suggested) Enable the pull-up on the RX line on the ATSAM3X8E.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.