Skip to content

app: Implement AT+IFC command handling #210

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
mgolu wants to merge 1 commit into from
Closed

app: Implement AT+IFC command handling #210

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion app/src/sm_at_commands.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -271,11 +271,13 @@ STATIC int handle_at_clac(enum at_parser_cmd_type cmd_type, struct at_parser *,
* * AT+IPR
* * AT+CMUX
* * AT+CGDATA
* * AT+IFC
*/
if ((strncasecmp(cmd, "AT+", strlen("AT+")) == 0 &&
strncasecmp(cmd, "AT+IPR", strlen("AT+IPR")) != 0 &&
strncasecmp(cmd, "AT+CMUX", strlen("AT+CMUX")) != 0 &&
strncasecmp(cmd, "AT+CGDATA", strlen("AT+CGDATA")) != 0) ||
strncasecmp(cmd, "AT+CGDATA", strlen("AT+CGDATA")) != 0 &&
strncasecmp(cmd, "AT+IFC", strlen("AT+IFC")) != 0) ||
strncasecmp(cmd, "AT%%", strlen("AT%%")) == 0) {
continue;
}
Expand Down
68 changes: 68 additions & 0 deletions app/src/sm_uart_handler.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -653,3 +653,71 @@ static int handle_at_ipr(enum at_parser_cmd_type cmd_type, struct at_parser *par

return -SILENT_AT_COMMAND_RET;
}
SM_AT_CMD_CUSTOM(ifc, "AT+IFC", handle_at_ifc);
Copy link
Copy Markdown
Contributor

@MarkusLassila MarkusLassila Mar 16, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hardware flow control is on by default, and it requires RTS and CTS pins to be used. Similarly, the buffer sizing for RX buffers is static and the sizing is not sufficient to operate without hardware flow control in all scenarios.

Can you elaborate what is the benefit of having this configurable in runtime?

Copy link
Copy Markdown
Contributor Author

@mgolu mgolu Mar 16, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is in case a customer wants to use only RX/TX hardware lines and not connect RTS/CTS.

Also this request: https://devzone.nordicsemi.com/f/nordic-q-a/127290/at-command-to-enable-disable-hw-flow-control-on-nrf9151

Copy link
Copy Markdown
Contributor

@MarkusLassila MarkusLassila Mar 16, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would leave RTS and CTS pins in place. CTS would have a pull-up, so not too damaging. But the buffer sizes would be an issue.

For production purposes, it would be way better to provide an overlays which would set sufficient buffer sizes. As for having such a command for testing purposes, perhaps.

@SeppoTakalo opinion?

Copy link
Copy Markdown
Contributor

@SeppoTakalo SeppoTakalo Mar 16, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As we are using statically defined pin maps in the build-time, I really don't see the benefit or run-time configuring the CTS/RTS as compared to having them floating.

Not having flow-control pins on the UART have been a source of lots of issues in the past.
Hello-world applications work, but any serious data traffic causes random byte drops that are hard to find as they usually look like a data corruption.

Copy link
Copy Markdown
Collaborator

@trantanen trantanen Mar 17, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is in case a customer wants to use only RX/TX hardware lines and not connect RTS/CTS.

Customers should be discouraged to not connect RTS/CTS lines. We cannot prevent them from doing so but it should be made clear that they are searching for random problems where any AT command or response, or PPP data can corrupt due to UART transmission issues.

According to our knowledge, AT+IFC doesn't change those issues in any way. We are checking that the Serial Modem would still work as well as possible when RTS/CTS were not connected, i.e., they would have pull-ups etc. correctly so that RX/TX would transfer data.

Copy link
Copy Markdown
Contributor

@MarkusLassila MarkusLassila Mar 18, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are checking that the Serial Modem would still work as well as possible when RTS/CTS were not connected, i.e., they would have pull-ups etc. correctly so that RX/TX would transfer data.

#219 allows the use of basic serial modem build without RTS and CTS lines being connected.

static int handle_at_ifc(enum at_parser_cmd_type cmd_type, struct at_parser *parser,
uint32_t param_count)
{
int err;
struct uart_config cfg;
uint16_t flow_ctrl;

err = uart_config_get(sm_uart_dev, &cfg);
if (err) {
LOG_ERR("uart_config_get: %d", err);
return err;
}

if (cmd_type == AT_PARSER_CMD_TYPE_READ) {
rsp_send("\r\n+IFC: %u\r\n", cfg.flow_ctrl & UART_CFG_FLOW_CTRL_RTS_CTS ? 2 : 0);
return 0;
}

if (cmd_type == AT_PARSER_CMD_TYPE_TEST) {
rsp_send("\r\n+IFC: (0,2)\r\n");
return 0;
}

if (cmd_type != AT_PARSER_CMD_TYPE_SET || param_count != 2) {
return -EINVAL;
}

if (sm_cmux_is_started()) {
LOG_ERR("Cannot change flow control while CMUX is active.");
return -EBUSY;
}

err = at_parser_num_get(parser, 1, &flow_ctrl);
if (err) {
return err;
}

/* Convert standard AT values of 0 and 2 to the right definition */
if (flow_ctrl == 0) {
cfg.flow_ctrl = UART_CFG_FLOW_CTRL_NONE;
} else if (flow_ctrl == 2) {
cfg.flow_ctrl = UART_CFG_FLOW_CTRL_RTS_CTS;
} else {
LOG_ERR("Unsupported flow control: %u", flow_ctrl);
return -EINVAL;
}

rsp_send_ok();

err = modem_pipe_close(&sm_pipe.pipe, K_SECONDS(1));
if (err) {
LOG_ERR("modem_pipe_close: %d", err);
return err;
}
err = uart_configure(sm_uart_dev, &cfg);
if (err) {
LOG_ERR("uart_configure: %d", err);
return err;
}
err = modem_pipe_open(&sm_pipe.pipe, K_SECONDS(1));
if (err) {
LOG_ERR("modem_pipe_open: %d", err);
return err;
}

return -SILENT_AT_COMMAND_RET;
}
101 changes: 101 additions & 0 deletions doc/app/at_generic.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -101,6 +101,107 @@ Example
+IPR: (),(115200,230400,460800,921600,1000000)
OK

|SM| UART flow control AT+IFC
=============================

The ``AT+IFC`` command sets the UART flow control.

Set command
-----------

The set command sets the UART flow control.

Syntax
~~~~~~

::

AT+IFC=<flow_control>

The ``<flow_control>`` parameter is an integer value specifying the desired flow control:

- 0: Disable flow control
- 2: Enable RTS/CTS flow control

.. note::

The flow control change takes effect after the modem responds with ``OK``.
The host must switch to the new flow control settings to continue communication.

Example
~~~~~~~

Disable flow control.

::

AT+IFC=0
OK

Enable RTS/CTS flow control.

::

AT+IFC=2
OK

Read command
------------

The read command reads the current UART flow control.

Syntax
~~~~~~

::

AT+IFC?

Response syntax
~~~~~~~~~~~~~~~

::

+IFC: <flow_control>

Example
~~~~~~~

::

AT+IFC?
+IFC: 0
OK

Test command
------------

The test command lists the supported flow control modes.

Syntax
~~~~~~

::

AT+IFC=?

Response syntax
~~~~~~~~~~~~~~~

::

+IFC: (list of supported flow control modes)

Example
~~~~~~~

::

AT+IFC=?
+IFC: (0,2)
OK


|SM| echo E0/E1
===============

Expand Down
Loading