cancel
Showing results for 
Search instead for 
Did you mean: 

RTS keeps high

allard
Senior

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?

1 ACCEPTED SOLUTION

Accepted Solutions
allard
Senior

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

View solution in original post

10 REPLIES 10
PatrickF
ST Employee

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.

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
allard
Senior

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.

PatrickF
ST Employee

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.

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
allard
Senior

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?

PatrickF
ST Employee

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.

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
allard
Senior

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.

PatrickF
ST Employee

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,

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
allard
Senior

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'.

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.

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.