cancel
Showing results for 
Search instead for 
Did you mean: 

USART probe error

MElha.1
Associate II

Hello,

I am using stm32mp157c-dk2 board and working on "How to exchange large data buffers with the coprocessor - example" from the wiki:

https://wiki.st.com/stm32mpu/wiki/How_to_exchange_large_data_buffers_with_the_coprocessor_-_example

I need to do some modifications on the example to be able to use a UART interface in the user application, usually I modify the device tree to enable the UART by adding the following lines to the .dts file (USART3 as an example):

&pinctrl {

...

usart3_pins_mx: usart3_mx-0 {

pins1 {

pinmux = <STM32_PINMUX('B', 10, AF7)>; /* USART3_TX */

bias-disable;

drive-push-pull;

slew-rate = <0>;

};

pins2 {

pinmux = <STM32_PINMUX('B', 12, AF8)>; /* USART3_RX */

bias-disable;

};

};

usart3_sleep_pins_mx: usart3_sleep_mx-0 {

pins {

pinmux = <STM32_PINMUX('B', 10, ANALOG)>, /* USART3_TX */

<STM32_PINMUX('B', 12, ANALOG)>; /* USART3_RX */

};

};

};

&usart3 {

pinctrl-names = "default", "sleep";

pinctrl-0 = <&usart3_pins_mx>;

pinctrl-1 = <&usart3_sleep_pins_mx>;

status = "okay";

};

this way works when I do it with the starter package but doesn't work with the example image. I followed the "Trace and debug scenario - UART issue" topic from the wiki and I get an "okay" status for USART3:

Board $> cat /proc/device-tree/soc/serial\@4000f000/status

okay

but I am also getting a probe error -22 for USART3:

[  0.530340] stm32-usart: probe of 4000f000.serial failed with error -22 

what is wrong and how to solve this problem?

thank in advance.

Mo elhawy

2 REPLIES 2
Christophe Guibout
ST Employee

Hi @MElha.1​ ,

Your device tree looks good.

The "okay" from DT status only means that UART3 driver is probed (and it's the case).

On my side, I tried to enable UART3 on my disco board (MMDV-2.1.0):

diff --git a/arch/arm/boot/dts/stm32mp15xx-dkx.dtsi b/arch/arm/boot/dts/stm32mp15xx-dkx.dtsi
index 685a82161cc8..f377ef774de1 100644
--- a/arch/arm/boot/dts/stm32mp15xx-dkx.dtsi
+++ b/arch/arm/boot/dts/stm32mp15xx-dkx.dtsi
@@ -727,7 +727,7 @@
 	pinctrl-1 = <&usart3_sleep_pins_b>;
 	pinctrl-2 = <&usart3_idle_pins_b>;
 	uart-has-rtscts;
-	status = "disabled";
+	status = "okay";
 };

And then, UART3 is well initialized:

[    1.433403] 4000e000.serial: ttySTM3 at MMIO 0x4000e000 (irq = 53, base_baud = 4000000) is a stm32-usart
[    1.433701] serial serial0: tty port ttySTM3 registered

I have several questions :

  • on which MMDV version you are ? (1.x.x or 2.x.x)
  • it would be great to attach the full dmesg trace to check if there is another error above.
  • could you please tell me the link between "How to exchange large data buffers with the coprocessor - example" use case and USART3 ?

BR,

Christophe

MElha.1
Associate II

Thanks Christophe for your reply,

I am using "How to exchange large data buffers with the coprocessor" example as a guide to build another project, it is similar to the example in many points but it will run on a board that doesn't have an LCD and the user will have control over the application through UART interface. That is why I am enabling USART3.

The solution for the probe problem "[  0.530340] stm32-usart: probe of 4000f000.serial failed with error -22 " is to modify the tf-a device tree and not only the kernel device tree, the tf-a device tree contains the setting for the clock input multiplexers for the peripherals, so if the kernel is going to use USART3, then we must confirm that USART3 clock is not disabled and is set to one of its available input clocks (ex. HSI) as follows:

&rcc {

...

st,pkcs = <

...

CLK_UART1_DISABLED

CLK_UART24_HSI

CLK_UART35_HSI

CLK_UART6_DISABLED

CLK_UART78_DISABLED

>;

...

};

USART3 is working properly after making this modification to tf-a device tree.

one final note about your dmesg regarding ttySTM3: ttySTM3 with the address 0x4000e000 is not USART3 that you tried to enable but it is USART2 which is refered to ttySTM3 by the alias: serial3 = &usart2; (USART3 address is 0x4000f000).

please correct if the solution I proposed is not the best solution or completely wrong.

BR,

Elhawy