UART Hardware handshaking controlling RTS/CTS over run

[venerley]

After experiencing UART problems without handshaking I opted to enable hardware handshaking.

Where RTS & CTS are pins 5 & 7 respectively.

I was experiencing overrun (insufficient memory) issues without hardware handshaking, however I see the same with RTS/CTS enabled.

I can see RTS being asserted (taken low) and then de-asserted, however I am still experiencing p_event->data.error_communication = 4

There is a period of time after reset where I need to configure the device connected to the UART and halt data sent data from it to prevent the 4 error.

Is there a call I can make to control the state of RTS ? I cannot find anything documented.

[hmolesworth]

I am also interested in the RTS/CTS operation. As far as I am aware, it is actually a hardware implementation on the UART and so can be enabled or disabled but otherwise not affected by software. In my tests it does not work well with terminal programs like Termite, since the mode of operation seems inverted. There are two interpretations of RTS/CTS operation, traditional modem style and more recent embedded systems. These are my notes:

/ * Traditional Modem Flow Control
 * If flow control is enabled, a transmission will be automatically suspended when CTS is deactivated and
 * resumed when CTS is activated again.
 * A byte that is in transmission when CTS is deactivated will be fully transmitted before the transmission is
 * suspended.
 * nRF52 DTE Output pin to DCE - asserts to request transmit
 * nRF52 DTE Input pin from DCE - asserts to allow transmit
 *
 * Hardware Flow Control
 * "RTS/CTS handshaking" the DTE asserts RTS whenever it is ready to receive data from the DCE, and the DCE
 * asserts CTS whenever it is ready to receive data from the DTE. Unlike the original use of RTS and CTS with
 * half-duplex modems, these two signals operate independently from one another.
 * nRF52 DTE Output pin to DCE - asserts to allow DCE to transmit
 * nRF52 DTE Input pin from DCE - asserts to allow nRF52 DTE transmit
 */

One assumes that the latter is used on the nRF52832, but being active low it doesn't seem to work in the way Termite expects. Traditional modem operation I think was active low, but embedded system mode I thought was active high. "Assert" in the case of nRF52832 is active low.

In your particular case you might just use the RTS/CTS as io ports and manually control them, since it looks like only occasionally they need to be inactive.

[venerley]

Thanks for your input. I must admit sadly I am reaching similar conclusion for my scenario, I just cannot get the level of control I appear to need from the SDK. I am thinking I might end up creating a simple diode OR combining my custom line with the Nordic RTS. You may be interested in this from Laird and also the bottom of page 335 in the nRF52832 product spec