From ed34306611a2b3dca3c8ac6bbb09c77811fc2964 Mon Sep 17 00:00:00 2001 From: Markus Lassila Date: Wed, 18 Mar 2026 15:07:05 +0200 Subject: [PATCH] app: Change CTS pull-down to pull-up Previously CTS was pulled up, this prevented hosts without hardware flow control from using the default Serial Modem build. Changing CTS to pull-down allows Serial Modem to send even when the CTS and RTS pins float. This relies in DTR as main mechanism for UART control. The host must first enable its own UART before it enables Serial Modem UART with DTR. - With hardware flow control, this means that host drives it's RTS pin, so there is no difference in operation. Host should also have a pull-up for it's CTS pin, so when SM starts driving it's RTS, the host knows that SM is ready to receive. - Without hardware flow control, the Serial Modem is able to send (TX) to host. However, the timing with DTR and when SM is able to receive needs to be taken into account as host cannot observe it's CTS. Instead host must monitor the RI signal, which is de-asserted when SM UART is ready. Or alternatively, have a sufficient timeout between host asserting DTR and host's first TX operation. Important: It is highly recommended to use hardware flow control with Serial Modem. Signed-off-by: Markus Lassila Co-authored-by: Divya S Pillai <91891495+divipillai@users.noreply.github.com> --- app/boards/nrf9151dk_nrf9151_ns.overlay | 32 +++++++++++++++++ app/overlay-external-mcu.overlay | 7 ++-- doc/uart_configuration.rst | 47 +++++++++++++++++++++---- 3 files changed, 77 insertions(+), 9 deletions(-) diff --git a/app/boards/nrf9151dk_nrf9151_ns.overlay b/app/boards/nrf9151dk_nrf9151_ns.overlay index a1392f73..836623ce 100644 --- a/app/boards/nrf9151dk_nrf9151_ns.overlay +++ b/app/boards/nrf9151dk_nrf9151_ns.overlay @@ -22,6 +22,10 @@ ri-gpios = <&gpio0 0 GPIO_ACTIVE_LOW>; status = "okay"; }; + pinctrl-0 = <&uart0_default_alt>; + pinctrl-1 = <&uart0_sleep_alt>; + pinctrl-names = "default", "sleep"; + }; &gpio0 { @@ -30,6 +34,34 @@ sense-edge-mask = <0x00000100>; }; + +&pinctrl { + uart0_default_alt: uart0_default_alt { + group1 { + psels = ; + bias-pull-up; + }; + group2 { + psels = ; + bias-pull-down; + }; + group3 { + psels = , + ; + }; + }; + + uart0_sleep_alt: uart0_sleep_alt { + group1 { + psels = , + , + , + ; + low-power-enable; + }; + }; +}; + /* Disable I2C2. * - Enabling IO expander causes ~20uA to be consumed while DTR is deasserted. * - We use P0.31 and P0.30 pins for DTR and RI signals with external MCU. diff --git a/app/overlay-external-mcu.overlay b/app/overlay-external-mcu.overlay index b88cf4df..c636bcb9 100644 --- a/app/overlay-external-mcu.overlay +++ b/app/overlay-external-mcu.overlay @@ -45,11 +45,14 @@ &pinctrl { uart2_default_alt: uart2_default_alt { group1 { - psels = , - ; + psels = ; bias-pull-up; }; group2 { + psels = ; + bias-pull-down; + }; + group3 { psels = , ; }; diff --git a/doc/uart_configuration.rst b/doc/uart_configuration.rst index 3eb3081b..6ec017d1 100644 --- a/doc/uart_configuration.rst +++ b/doc/uart_configuration.rst @@ -44,6 +44,9 @@ The following UART signals are used: The Data Terminal Ready (DTR) and Ring Indicator (RI) signals are the **control signals** used for UART power management, while TX/RX/RTS/CTS are the standard UART signals. +.. important:: + The use of |SM| without hardware flow control (RTS/CTS) is `experimental `_ and strongly not recommended. + See :ref:`uart_without_flow_control` for more information. Board-specific pin mapping ************************** @@ -71,11 +74,11 @@ The following tables shows how to connect the UART pins to the corresponding pin * - TX - P0.27 * - RX - - P0.26 + - P0.26 (pull-up) * - RTS - P0.14 * - CTS - - P0.15 + - P0.15 (pull-down) * - DTR - P0.08 (Button 1, pull-up, active high) * - RI @@ -103,11 +106,11 @@ The following tables shows how to connect the UART pins to the corresponding pin * - TX - P0.02 * - RX - - P0.03 + - P0.03 (pull-up) * - RTS - P0.06 * - CTS - - P0.07 + - P0.07 (pull-down) * - DTR - P0.31 (active low, pull-up) * - RI @@ -184,7 +187,7 @@ Host application .. group-tab:: nRF54L15DK - The nRF54L15DK host applications use UART30 for Serial Modem communication: + The nRF54L15DK host applications use UART30 for |SM| communication: .. list-table:: :header-rows: 1 @@ -249,7 +252,7 @@ When DTR is asserted by the host, the UART is enabled and ready for communicatio When DTR is deasserted, the UART is powered down to save power. When the UART is powered down, it releases its high-speed clocks, which are then automatically stopped by the system's power management. -This achieves the lowest possible power consumption, as the UART is one of the primary power consumers in serial modem configurations. +This achieves the lowest possible power consumption, as the UART is one of the primary power consumers in |SM| configurations. Power consumption can be reduced from hundreds of microamps to just a few microamps when the UART is powered down. UART power management is completely independent of the modem power management (CFUN, PSM, eDRX, and so on). @@ -278,6 +281,13 @@ Once the host UART is ready and DTR is asserted, the nRF91 enables its UART inte The RI signal remains active throughout this process and only returns to inactive once the nRF91 UART is active. This coordinated wake-up ensures both ends of the communication link are ready before data transmission begins. +**With hardware flow control -** The host can observe its CTS pin (connected to |SM|'s RTS) to know when |SM| is ready to receive data. +When |SM| starts driving its RTS pin, the host knows that |SM| is ready to receive. +The host must also have a pull-up on its CTS pin. + +**Without hardware flow control-** The host must monitor the RI signal, which is de-asserted when the |SM| UART becomes ready to receive data. +Alternatively, the host can implement a sufficient timeout between asserting DTR and initiating its first TX operation. + Host-initiated wake-up ====================== @@ -289,10 +299,33 @@ The modem detects the DTR assertion and powers up its UART interface, allowing c Sequence diagram showing host-initiated wake-up of the modem +.. _uart_without_flow_control: + +Operating without hardware flow control +======================================== + +.. important:: + The use of |SM| without hardware flow control (RTS/CTS) is `experimental `_ and strongly not recommended.. + Hardware flow control ensures reliable communication and prevents timing-related issues. + Without hardware flow control, there is a risk of data loss in UART communication, especially in high-throughput scenarios. + +|SM|'s CTS pin is configured with pull-down, allowing |SM| to transmit when CTS and RTS pins are left floating. +The host can operate without connecting the hardware flow control signals (CTS/RTS). + +**Key requirements:** + +* The host must enable its own UART before asserting DTR. +* To detect when |SM| is ready to receive, monitor the RI signal (de-asserted when ready) or use a sufficient timeout after DTR assertion. +* See `Incoming data wake-up`_ for detailed timing information. + +**Buffer configuration:** + +Increase ``CONFIG_SM_UART_RX_BUF_SIZE`` and possibly ``CONFIG_SM_UART_RX_BUF_COUNT`` to provide sufficient buffer space for your use case. + Automatic UART power management using Zephyr's Cellular Modem driver ==================================================================== -As the Serial Modem's UART interface power state is controlled by the DTR signal from the host, it is possible to automate the power management using Zephyr's cellular modem driver with Zephyr's CMUX (3GPP TS 27.010) module. +As the |SM|'s UART interface power state is controlled by the DTR signal from the host, it is possible to automate the power management using Zephyr's cellular modem driver with Zephyr's CMUX (3GPP TS 27.010) module. This allows host applications to manage the UART power state automatically. See the `Zephyr CMUX Power Saving`_ documentation for more information. This configuration is completely done in the host.