14

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.

Ricardo
  • 3,390
  • 2
  • 26
  • 55
Blake Ramsdell
  • 241
  • 1
  • 2

1 Answers1

1

Short:

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.

Long:

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.

next-hack
  • 411
  • 3
  • 10