DTR signal needs to be activated from terminal program

[MrGreensWorkshop]

Problem:

tud_cdc_connected is using DTR bit which is used in cdc_uart.c If DTR is not set by host (PC terminal or other device), we can't send anything to host.

same issue with #906, #921, #932

I don't think its necessary to check DTR as discussed in here -> hathach/tinyusb

Until user open the serial port, data buffer will be overridden.

src/class/cdc/cdc_device.h

static inline bool tud_cdc_connected (void)
{
  return tud_cdc_n_connected(0);
}

src/class/cdc/cdc_device.h

bool tud_cdc_n_connected(uint8_t itf)
{
  // DTR (bit 0) active  is considered as connected
  return tud_ready() && tu_bit_test(_cdcd_itf[itf].line_state, 0);
}

how to fix

change tud_cdc_connected() with tud_ready()

[P33M]

Do you have an example of a serial terminal program that does not customarily set DTR by default, and does not expose this option to the user?

[lurch]

See also https://github.com/raspberrypi/pico-sdk/pull/932

[MrGreensWorkshop]

Yes there actually is, check the screenshot in this issue. I think you can find more. https://github.com/raspberrypi/pico-sdk/issues/906

Btw, conflict resolved at PR #33.

[P33M]

All of the screenshots there offer the user a DTR toggle.

The International Telecommunications Union document ITU-T Rec V.24 has this to say about DTE behaviour in section 3.11:

3.11 Circuit 108/2 – Data terminal ready Direction: To DCE Signals on this circuit indicate the status of the DTE. The ON condition, indicating that the DTE is ready to operate, prepares the DCE to connect the signal-converter or similar equipment to the line. The DCE may be connected to the line by a supplementary condition. Examples of such supplementary conditions include, but are not restricted to, the following: – depression of a push button at the DCE; – an incoming call in the case of automatic answering; – a call request command from the DTE in the case of automatic calling. The DCE maintains the connection so long as the ON condition persists, except that the ON condition shall not prevent the operation of disconnection functions optionally implemented in the DCE. Examples of such disconnection functions are noted in the definition of circuit 108/1. The DTE is permitted to present the ON condition on circuit 108/2 whenever it is ready to transmit or receive data. The OFF condition on this circuit causes the DCE to remove the signal-converter or similar equipment from the line when the transmission to the line of all data previously transferred on circuit 103 and/or circuit 118 has been completed. In the case where an intermediate function is implemented in the DCE, the DCE may delay the removal of the signal converter from the line until the protocol requirements of the intermediate function have been satisfied (e.g. outstanding data has been acknowledged or a timeout has occurred). The OFF condition of this circuit may also be used to direct the DCE to abort or to clear a serial automatic calling operation (see Recommendation V.25 bis).

Which all but states that a DCE may not transmit data to the host without DTR being asserted.

[MrGreensWorkshop]

When hardware flow control / handshaking is been used you are right. When handshaking is off, those doesn't apply. You can check that handshaking is off on those screenshots. I want to add that USB serial converters behaves same. When handshaking is off, DTR / CTS etc. is ignored.

[P33M]

DTR is/should be orthogonal to flow control. It controls the state of the overall communication channel, not the temporary line conditions requiring pauses (FIFO fill levels) for which RTS/CTS are most often used. See ITU-T rec V.43 section 4.1: Methods for flow control of transmitted data

Circuit 108/2 (DTR) is not included in the associated diagram and not mentioned anywhere in the document. Do you have a source for your assertion?

[MrGreensWorkshop]

What I'm saying is the implementation of DTR creates a flow control, which stops sending data to host like RTS/CTS. That's not how it should be when flow control is off.

These are related to DTR/DSR hardware flow control.

• RTS/CTS, DTR, and DTR/DSR Flow Control from redhat-6.2-docs
• DTR/DSR hardware flow from IBM AIX docs

I should add that, if we are using 3rd party software which is using serial port, we don't have any control of DTR, like Android app, we can't expect programmers to turn on DTR in every software nor softwares already exist.

I remember when making Windows apps in VS .NET, DTR is OFF by default unless you enable it. It's the same in Linux and Android apps.

[sanjay900]

I've encountered this exact problem while trying to use picoprobe as a UART to program a Ox64 microcontroller. The tooling for this uses the DTR and RTS for triggering resets, and so i ended up needing to make this change myself in order to be able to program my devices

[P33M]

The picoprobe uart doesn't expose flow-control pins at all. Even if it did, you won't get a DTR pin as it's not a hardware mux option. The proposal above is to gate the transmission of UART characters over USB with DTR.

[sanjay900]

I see that makes sense. I was just providing a very odd example where the microcontroller i was programming didn't actually require those pins to function, but the tooling was clearing DTR and RTS anyways, i presume for other variants of that chip, causing me issues when I attempted to program. The fix above was something i was actually trying to find for a while.