Skip to main content
Visitor II
July 22, 2021
Solved

RTS keeps high

  • July 22, 2021
  • 9 replies
  • 3883 views

I'm using a SoM with a STM32MP157C. I've connected a LTE modem to uart7, its connected with a 4-wire uart, going trough a level shifter. The device tree contains the following:

uart7_pins_mx: uart7_mx-0 {
		pins1 {
			pinmux = <STM32_PINMUX('E', 7, AF7)>, /* UART7_RX */
					 <STM32_PINMUX('E', 10, AF7)>; /* UART7_CTS */
			bias-disable;
		};
		pins2 {
			pinmux = <STM32_PINMUX('E', 8, AF7)>, /* UART7_TX */
					 <STM32_PINMUX('E', 9, AF7)>; /* UART7_RTS */
			bias-disable;
			drive-push-pull;
			slew-rate = <0>;
		};
	};
 
	uart7_sleep_pins_mx: uart7_sleep_mx-0 {
		pins {
			pinmux = <STM32_PINMUX('E', 7, ANALOG)>, /* UART7_RX */
					 <STM32_PINMUX('E', 8, ANALOG)>, /* UART7_TX */
					 <STM32_PINMUX('E', 9, ANALOG)>, /* UART7_RTS */
					 <STM32_PINMUX('E', 10, ANALOG)>; /* UART7_CTS */
		};
	};

and

&uart7{
	pinctrl-names = "default", "sleep";
	pinctrl-0 = <&uart7_pins_mx>;
	pinctrl-1 = <&uart7_sleep_pins_mx>;
	status = "okay";
 
	/* USER CODE BEGIN uart7 */
	uart-has-rtscts;
	/* USER CODE END uart7 */
};

When I boot the device the RTS pin is high and it stays high. Reading the device buffer with "cat /dev/ttySTM1" does not cause the pin to go low. When i send a message with "echo "AT" > /dev/ttySTM1" the message "transmission complete is not set" is shown. The CTS pin coming from the modem is low, as expected. Running "cat /proc/tty/driver/stm32-usart" gives the following:

1: uart:stm32-usart mmio:0x40018000 irq:41 tx:12 rx:0 CTS|DSR|CD

I expect the RTS pin to be low, and only to go high when the device buffer is full, any ideas what is going wrong?

    This topic has been closed for replies.
    Best answer by allard

    This is resolved, it was a hardware issue, a bi-directional level shifter made it somewhat difficult to debug.

    9 replies

    Technical Moderator
    July 22, 2021

    Hi, please precise which OpenSTLinux version are you using.

    Seems "uart-has-rtscts;" is not supported on Ecosystem V1.2 (Kernel 4.19), "st,hw-flow-ctrl;" should be used instead.

    RTS/CTS are used on DK2 board together with USART2 connect to BlueTooth.

    Regards.

    allardAuthor
    Visitor II
    July 22, 2021

    I'm using Ecosystem V2.0.0, openstlinux 5.4, the distribution package. My goal is to use the UART with pppd, I got this working on earlier revisions of the board, but those had the RTS/CTS pins disconnected.

    Technical Moderator
    July 23, 2021

    Not tested on my side, but Device Tree "uart-has-rtscts;" is probably not sufficient to enable RTS/CTS behavior.

    Under console, with "cat /dev/ttySTM1", you might need to issue a "stty -F /dev/ttySTM1 crtscts" before.

    Regards.

    allardAuthor
    Visitor II
    July 23, 2021

    Hi Patrick,

    I've already tried this, without result. This is the output of "stty -F /dev/ttySTM1 -a" :

    speed 9600 baud; rows 0; columns 0; line = 0;
    intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>;
    start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
    -parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal crtscts
    -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel
    -iutf8
    opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
    isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho
    -extproc

    After this command "cat /proc/tty/driver/stm32-usart" still reports no RTS flag.. Is there a way to check if the "uart-has-rtscts" flag is correctly interpreted?

    Technical Moderator
    July 23, 2021

    Hi,

    some useful stuff in https://wiki.st.com/stm32mpu/wiki/Trace_and_debug_scenario_-_UART_issue

    Some checks I have done on my side (with serial1 = usart3 @0x4000f000):

    • "ls /proc/device-tree/soc/serial\@4000f000" show that "uart-has-rtscts" has been defined
    • "stty -F /dev/ttySTM1 crtscts" will correctly sets UART2_CR2 bits RTSE and CTSE (shown using "devmem2 0x4000F008 w")
    • "cat /sys/kernel/debug/pinctrl/soc\:pin-controller\@50002000/pinmux-pins | grep 4000f000" shows the pins are correctly muxed

    Checks done on Ecosystem v3.0.0 with kernel 5.10

    Note that I have not really checked RTS/CTS board level nor tried real transmit/receive on USART3 with RTS/CTS.

    Regards.

    allardAuthor
    Visitor II
    July 23, 2021

    Did the checks:

    ls /proc/device-tree/soc/serial\@40018000
    clocks dmas pinctrl-0 power-domains status
    compatible interrupts-extended pinctrl-1 reg uart-has-rtscts
    dma-names name pinctrl-names resets wakeup-source
    stty -F /dev/ttySTM1 crtscts
    devmem2 0x40018000 w
    -sh: devmem2: not found

    I think devmem2 is not included in my image.

    cat /sys/kernel/debug/pinctrl/soc\:pin-controller\@50002000/pinmux-pins | grep 40018000
    pin 71 (PE7): device 40018000.serial function af7 group PE7
    pin 72 (PE8): device 40018000.serial function af7 group PE8
    pin 73 (PE9): device 40018000.serial function af7 group PE9
    pin 74 (PE10): device 40018000.serial function af7 group PE10
     
    dmesg | grep 40018000
    [ 3.006285] 40018000.serial: ttySTM1 at MMIO 0x40018000 (irq = 41, base_baud = 6250000) is a stm32-usart
     
    cat /sys/kernel/debug/pinctrl/soc\:pin-controller\@50002000/pinconf-pins | grep -E "PE7|PE
    8|PE9|PE10"
    pin 71 (PE7): alternate 7 (UART7_RX) - push pull - floating - low speed
    pin 72 (PE8): alternate 7 (UART7_TX) - push pull - floating - low speed
    pin 73 (PE9): alternate 7 (UART7_RTS UART7_DE) - push pull - floating - low speed
    pin 74 (PE10): alternate 7 (UART7_CTS) - push pull - floating - low speed

    So it seems the "uart-has-rtscts" flag works, and the I/O is correctly set(?). I will look into adding devmem2 to my debugging image.

    Technical Moderator
    July 23, 2021

    for devmem2 install (need network connection):

    apt-get update
    apt-get install devmem2

    possible to check directly the pin levels by reading GPIOx_IDR to check RTS and CTS outside any SW.

    • first enable all GPIOA-K clocks "devmem2 0x50000a28 w 0x7ff" (don't take care of readback or if some bits are not set)
    • then read directly the GPIOE_IDR "devmem2 0x50006010 w"

    on my tests, verified :

    • RTS is going to low level after "stty -F /dev/ttySTM1 crtscts" (RTS/CTS control enabled)
    • RTS back to high level with "stty -F /dev/ttySTM1 -crtscts" (RTS/CTS control disabled)

    Minor comment: in case CTS and RX pins are not always driven externally or having external pull-up, maybe worth to add "bias-pull-up;" on those pins.

    Regards,

    allardAuthor
    Visitor II
    July 23, 2021

    Made a new image containing devmem2, did the tests:

    With RTS/CTS control disabled:

    devmem2 0x40018008 w
     
    /dev/mem opened.
    Memory mapped at address 0xb6f8a000.
    Read at address 0x40018008 (0xb6f8a008): 0x44202001

    RTS/CTS control enabled:

     devmem2 0x40018008 w
     
    /dev/mem opened.
    Memory mapped at address 0xb6f5c000.
    Read at address 0x40018008 (0xb6f5c008): 0x44202301

    It seems bit 8 and 9 are correctly set.

    I/O test:

     devmem2 0x50000a28 w 0x7ff
     
    /dev/mem opened.
    Memory mapped at address 0xb6f60000.
    Read at address 0x50000A28 (0xb6f60a28): 0x00000000
    Write at address 0x50000A28 (0xb6f60a28): 0x000007FF, readback 0x000007FF
     
     devmem2 0x50006010 w
     
    /dev/mem opened.
    Memory mapped at address 0xb6f3c000.
    Read at address 0x50006010 (0xb6f3c010): 0x00000000
     
    stty -F /dev/ttySTM1 crtscts
    devmem2 0x50006010 w
     
    /dev/mem opened.
    Memory mapped at address 0xb6f97000.
    Read at address 0x50006010 (0xb6f97010): 0x00000000
     
    stty -F /dev/ttySTM1 -crtscts
    devmem2 0x50006010 w
     
    /dev/mem opened.
    Memory mapped at address 0xb6f8a000.
    Read at address 0x50006010 (0xb6f8a010): 0x00000000

    It looks like the whole GPIOE is kept at zero, looks like some clock issue? I measured TX and RX (and the RTS) to be high while testing, so these pins should have reported as '1'.

    Technical Moderator
    July 23, 2021

    Probably a GPIO clock enable issue (usually linked security aspects) which avoid to read the IDR.

    Reading clock enable back using "devmem2 0x50000a28 w" should highlight this,

    You might forget to use this 'hack read with GPIO' and rely on measuring on the pins with external device (multimeter, scope, etc...).

    Sound like your setup is ok. Note that all my trials are on ecosystem V3.

    Don't know how to help more.

    allardAuthorAnswer
    Visitor II
    August 16, 2021

    This is resolved, it was a hardware issue, a bi-directional level shifter made it somewhat difficult to debug.