SARA-R4/N4 series - AT Commands Manual
UBX-17003787 - R09
10 V24 control and V25ter
Page 97 of 307
• Set the <value> parameter of AT&K command to 0 (flow control disabled) or 4, 5 or 6 (software flow
control) when the RTS and CTS lines are not physically connected.
• The software flow control (XON/XOFF) setting is not allowed on the USB interfaces, on the SPI interface
and on a multiplexer channel. See the
Multiple AT command interfaces
for all the behavior differences in
respect to the supported interfaces.
• The SW flow control (XON/XOFF) activation is only allowed in case of the text transmission: the binary
data cannot be transmitted because it may contain the special flow control characters (XON/XOFF).
• When the software flow control (XON/XOFF) is used, the DC1 (XON, 0x11) and DC3 (XOFF, 0x13) characters
are reserved and therefore filtered (e.g. in SMS text mode these two characters can not be input).
Since the DTE-DCE communication relies on the correct reception of DC1/DC3 characters, the UART
power saving should be disabled on the module when the SW flow control is used. If the UART power
saving is active, the DC1/DC3 characters could be used to wake up the module's UART, and therefore lost.
In case a DC3 character (XOFF) is correctly received by module's UART and some data is waiting to be
transmitted, the module is forced to stay awake until a subsequent DC1 character (XON) is received.
10.5.5 SW flow control enhancement for PSD data transfer with PPP L2
protocol
The software flow control enhancement is only supported on the UART interface.
The standard implementation of the UART XON/XOFF flow control is limited to DTE-DCE communications
where the ASCII non-printable control characters are not transferred. This is an important limitation, since it is
not possible to use it in case of the generic binary data transfer. An extension to a PPP L2 protocol data transfer
has been done by exploiting the PPP octet stuffing procedure.
PPP Octet-stuffed framing and transparency
The PPP protocol implements an escape mechanism specified to allow control data such as XON/XOFF to be
transparently transmitted over the link, and to remove spurious control data which may be injected into the
link by intervening hardware and software.
The control escape octet is defined as binary 01111101 (hexadecimal 0x7d), most significant bit first. As a
minimum, sending implementations must escape the flag sequence and control escape octets.
After Frame Check Sequence (FCS) computation, the transmitter examines the entire frame between the
two flag sequences. Each flag sequence, control escape octet, and any octet which is flagged in the sending
Async-Control - Character-Map (ACCM), is replaced by a two octet sequence consisting of the control escape
octet followed by the original octet exclusive-or'd with hexadecimal 0x20.
The receiving implementations must correctly process all the control escape sequences. On the reception, prior
to FCS computation, each octet with value less than hexadecimal 0x20 is checked. If it is flagged in the receiving
ACCM, it is simply removed (it may have been inserted by intervening data communications equipment). Each
control escape octet is also removed, and the following octet is exclusive-or'd with hexadecimal 0x20, unless
it is the flag sequence (which aborts a frame).
ACCM negotiation for XON/XOFF chars during PPP LCP negotiation
The ACCM is negotiated in a LCP (Link Control Protocol, part of PPP protocol) configuration request. In
particular the LCP Option 02 is used.
This option is described in the RFC 1662 and has the following format.
| 02 | 06 | Async Control Character Map |
This configuration option provides a method to negotiate the use of control character transparency on
asynchronous links.
The module by default would start in any case requesting an ACCM sets to 0x00000000, which is incompatible
with XON/XOFF flow control.
To overcome this situation, the ACCM negotiation handler should combine the value received in a
Configure-Nak via a logical bitwise OR operation with the last configure-request value it sent. This result should
then be sent in the next Configure-Request message. If a configure-request is received whose bit mask includes
cleared bits for characters that the local implementation knows to be problematic (perhaps by way of an
administrative option or some kind of hardware information), then it should send a Configure-Nak with the
prior value modified to have these bits set.
