2021-07-22 05:53 AM
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?
Solved! Go to Solution.
2021-08-16 12:08 AM
This is resolved, it was a hardware issue, a bi-directional level shifter made it somewhat difficult to debug.
2021-07-22 07:06 AM
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.
2021-07-22 07:25 AM
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.
2021-07-22 11:31 PM
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.
2021-07-23 12:15 AM
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?
2021-07-23 02:52 AM
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):
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.
2021-07-23 03:25 AM
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.
2021-07-23 05:10 AM
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.
on my tests, verified :
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,
2021-07-23 06:39 AM
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'.
2021-07-23 07:21 AM
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.