Purpose of 1k resistor labelled RN2D on the Uno schematic

[lemon14899]

Looking through the schematic for the Rev.3 Uno, I see a 1k pulldown resistor labelled RN2D connected to the HWB/CTS pin of the 16u2, namely pin 13.

However, this does not make sense, as pin 13 is labelled active-LOW(high=disabled, low=enabled). Wouldn't this pulldown resistor make DTR(Data Terminal Ready) TRUE in absence of a control signal, even if only the recipient MCU is active?
As this is connected to a 100nF capacitor, and to the recipient's RESET pin(MCU being programmed), wouldn't this also trigger a constant reset for the recipient MCU?

I feel like this may be a dumb question, but just had to make sure.

[J-M-L]

I'm not a hardware guy so don't take this for an absolute truth but that's my understanding of what happens:

➜ Pin 13 on the ATmega16U2 is labeled CTS/HWB, but these features are not used by the Arduino/IDE.

➜ the DFU mode of the ATmega16U2 is set if pin13 is HIGH at boot which is not desirable.

➜ The pull-down resistor RN2D ensures that the HWB feature is not accidentally triggered by a floating pin state.

➜ Meanwhile, the pull-up resistor RN1D keeps capacitor C5 charged (through the pullup RN1D), resulting in the reset pin seeing 5V by default.

➜ When the Arduino IDE initiates a sketch upload, it sends a DTR signal to the USB-to-serial converter chip (ATmega16U2). The firmware on the ATmega16U2 toggles pin 13 HIGH momentarily, causing capacitor C5 to discharge and recharge. This discharge creates a falling edge on the reset line, triggering a reset of the Arduino board.

➜ Upon reset, the Arduino enters bootloader mode, where it awaits new program data to be uploaded via the serial connection.

[sterretje]

The HWB functionality is only active when the 16U2 goes through a reset cycle.

[J-M-L]

@sterretje

The HWB functionality is only active when the 16U2 goes through a reset cycle

pin 13 being pulled low, it should not happen. You would need to force it HIGH during a reset cycle by an external mean. isn't it?

[sterretje]

I don't have the datasheet at hand; if not mistaken it describes (the sequence) how HWB can affect the boot process.

[J-M-L]

OK - from the top of my head the 16U2 would enter DFU mode if PD7 was pulled HIGH when booting but I might be mistaken

[westfw]

@J-M-L

When the Arduino IDE initiates a sketch upload, it sends a DTR signal to the USB-to-serial converter chip (ATmega16U2). The firmware on the ATmega16U2 toggles pin 13 HIGH momentarily, causing capacitor C5 to discharge and recharge.

Your explanation was fine up till here. DTR is normally an "active low" signal, which means that the idle state is HIGH. When the connection is opened, DTR goes low, and THAT causes RESET to go low momentarily.
(This is how standard "rs232 serial" works; the 16u2 firmware authors COULD have made it work differently, customized for Arduino's needs, but apparently decided to keep "typical" behavior instead.)

[J-M-L]

DTR is a signal that goes over the usb cable to the chip.

My assumption is that the firmware catches the DTR signal and momentarily pulses HIGH pin 13 which discharges the C5 capacitor and creates the reset pulse.

a LOW front on pin 13 would be useless as OP correctly indicated that there is a always ON pulldown resistor attached to that pin and if pin 13 was always HIGH then C5 wouldn’t charge.

But again you might be right as I’m definitely not a hardware expert

[LarryD]

• At power up time C5 is discharged.
• C5 charge path, from 5v thru 10k, C5, 1k, GND.
• The 328 rest pin is low while C5 charges. i.e. 328 is reset at power on time.
• Once sufficient charge builds up across C5 the reset pin reaches a HIGH level, the 328 is no longer reset.
• When DTR is toggled, C5 discharges then charges, we once again have a reset on the 328 reset pin as mentioned above . . .

[J-M-L]

@LarryD

When DTR is toggled

so do you concur that when DTR is toggled (sent from the PC to the ATmega16U2) the ATmega16U2 pulses pin 13 HIGH - LOW which indeed discharges C5?

[sterretje]

@J-M-L

My assumption is that the firmware catches the DTR signal and momentarily pulses HIGH pin 13

This is from the source code for the 16U2.

void EVENT_CDC_Device_ControLineStateChanged(USB_ClassInfo_CDC_Device_t* const CDCInterfaceInfo)
{
	bool CurrentDTRState = (CDCInterfaceInfo->State.ControlLineStates.HostToDevice & CDC_CONTROL_LINE_OUT_DTR);

	if (CurrentDTRState)
	  AVR_RESET_LINE_PORT &= ~AVR_RESET_LINE_MASK;
	else
	  AVR_RESET_LINE_PORT |= AVR_RESET_LINE_MASK;
}

It does not seem to be momentarily. So my understanding is that it purely reacts on the DTR state that is transmitted over USB and that determines that state of the pin on the 16U2.

[LarryD]

• The ATmega16U2 will be similar to the 328 in that at power up time, the GPIOs would be HIGH impedance, hence the need for the 1k in the C5 charge path.
• To be sure, there is no DTR line in the USB cable.
• The PC will send USB serial data to the ATmega16U2 where code basically creates a serial port, lets call this a virtual serial port (similar as the old hardware serial ports we use to have with a DB09 connector).
• The ATmega16U2 generates the DTR Pin 13 signal resulting from decoding USB serial data from the PC.

[J-M-L]

Thanks for the source code - makes it clear

---

@LarryD

• To be sure, there is no DTR line in the USB cable.

yes indeed - just a "signal"

[J-M-L]

looking at the source code again:

CurrentDTRState is true if the CDC_CONTROL_LINE_OUT_DTR is HIGH which is the default state when DTR is not 'sent' (the name of that bool could have been better chosen)

the &= is to force a 0 when DTR is not sent
the |= is to force a 1 when DTR is sent

so it confirms that when DTR is not asserted, pin13 is LOW and when DTR is asserted pin13 is HIGH (assuming a 1 bit in the AVR_RESET_LINE_PORT means HIGH)

[GolamMostafa]

Figure-1:

1. Referring to the above schematic of a functioning clone UNO (Fig-2), it is observed that --

Figure-2:

(1) During normal operation of the MCU, the logic level of DTR-pin (it works just as an outout line) of U1 (USB/TTL Converter) is HIGH (5V).

(2) At the beginning of sketch uploading, the DTR-pin goes LOW (0V) (in response to the command coming from IDE) and remains LOW until uploading is complete. At the end of uploading, the DTR-pin again goes to HIGH state to make the next uploading possible.

Role of LOW/HIGH signal asserted on DTR-pin:
2. Before uploading, the potentials of both plates of C6 are equal (HIGH). At the time of uploading, left-side plate (connected with DTR-pin of USB/TTL Converter, U1) goes LOW.

As the capacitor (C6) has the tendency (property) to maintain equal potentials across its plates to stop current passing through it, the right-side plate (connected with RST-pin of MCU) momentarilly goes to LOW state to maintain the plates' potentials equal. (Similar but opposite to inductor which opposes sudden change in current flowing through it.)

As a result, the MCU enters into RESET state and its PC (Program Counter) is loaded with the base address of the Boot Section.

After a while C6 starts charging up via resisitor R4 and at 0.310 ms point (0.66 x R4 x C6) of the time line, the MCU comes out of RESET state and begins to execute the Boot Loader Program to communicate with the IDE for getting the sketch codes and store them into the flash memory of the MCU.

Once uploading is complete, the IDE sends command to assert HIGH on the DTR-pin.

3. Referring to schematic of Fig-3 of the Orginal UNO --

Figure-3:

The inclusion of resistor RN2D with the PD7-pin of U3 (the USB/TTL Converter) ensures the stability of the logic level of PD7-pin. The clone version of Fig-2 lacks this circuit quality!