STM32MP257F-DK: Issue in Getting the USART6 up on this MPU board

[mayank_7117]

Hello ST Community,

I'm using the STM32MP257F-DK MPU board and wanted to enable the USART6 interface. We can access it from the 40-Pin GPIO expansion header of the board.

For this, I have enabled the 'status' node settings of the usart6 from the device tree (dts) file as mentioned below.

serial@40220000 {
compatible = "st,stm32h7-uart";
reg = <0x40220000 0x400>;
interrupts-extended = <0x1e 0x1d 0x04>;
clocks = <0x16 0x116>;
dmas = <0x1c 0x13 0x20 0x10012 0x1c 0x14 0x20 0x3021>;
dma-names = "rx\0tx";
access-controllers = <0x1b 0x24>;
power-domains = <0x0c>;
wakeup-source;
status = "okay";
pinctrl-names = "default\0idle\0sleep";
pinctrl-0 = <0x34>;
pinctrl-1 = <0x35>;
pinctrl-2 = <0x36>;
uart-has-rtscts;
phandle = <0xe5>;
};
After setting 'status = okay' in the dts, I'm able to see the '/dev/ttySTM1' device entry on my board on bootup. Now, just to check the uart is enabled or not, I have looped back Tx-Rx pins of the GPIO expansion header and tried to write to the usart (echo "hello" > /dev/ttySTM1") but I see nothing on the console.

I tried to see the clock_summary and found that somehow, the clock status for the usart6 is not enabled. I'm not sure how to enable the clock or what the correct clock_source and clock_id are for this particular usart. [DTS uses clocks = <0x16 0x116>; node for the clock].

root@stm32mp2:~# cat /sys/kernel/debug/clk/clk_summary | grep usart6
ck_icn_p_usart6 0 0 0 200000000 0 0 50000 N deviceless no_connection_id
ck_ker_usart6 0 0 0 64000000 0 0 50000 N serial@40220000 no_connection_id

Tried to enable clock at runtime (Using 'echo on > /sys/class/tty/ttySTM1/device/power/control') for usart6 but it doesn't work. Any thought on how I can enable the usart and get the Tx-Rx loopback working?

Thanks,
Mayank

[GatienC]

Hello Mayank,

What do you see when typing :

ls /sys/class/tty/ttySTM0/device/driver/

 ?

You should see the base address of the USART6.

Regarding the RIF configuration of the platform. Are the pins of the USART6 (GPIOF13/F14) and the USART6 itself assigned to the Linux kernel? FYI there is a debug entry to check the firewall configuration of the non RIF-aware peripherals (/sys/kernel/debug/stm32_firewall/rifsc).

If all of this is OK, can you make sure that the driver is probed?

Regards,

Gatien

[GatienC]

Please have a look at https://community.st.com/t5/stm32-mpus-embedded-software-and/stm32mp257-usart-and-serc-exception/td-p/794150 as well.

[mayank_7117]

Hello @GatienC ,

Please refer to the following command responses from the development board.

-------------------------------------------------------------------------------------------------------------------

root@stm32mp2:~# ls /sys/class/tty/ttySTM1/device/driver/
400e0000.serial 40220000.serial 40330000.serial bind uevent unbind

root@stm32mp2:~# cat /sys/class/tty/ttySTM1/device/driver/40220000.serial/supplier:platform:44200000.clock-controller/status
active

--> Here, the clock status shows as 'active'.

-------------------------------------------------------------------------------------------------------------------

root@stm32mp2:~# cat /sys/kernel/debug/clk/stm32_clk_summary | grep usart6
ck_ker_usart6 64000000 N
ck_icn_p_usart6 200000000 N

--> Here, It says that the clock is not enabled for usart6.

-------------------------------------------------------------------------------------------------------------------

As you suggested, I have checked if the USART6 is assigned to the Linux kernel or not. From the below command output firewall is disabled so Linux should have access of it.

root@stm32mp2:~# cat /sys/kernel/debug/stm32_firewall/rifsc | grep USART
| USART1 || 31 || NSEC || NPRIV || disabled || disabled || 0 || 0x0 |
| USART2 || 32 || NSEC || NPRIV || disabled || disabled || 0 || 0x0 |
| USART3 || 33 || NSEC || NPRIV || disabled || disabled || 0 || 0x0 |
| USART6 || 36 || NSEC || NPRIV || disabled || disabled || 0 || 0x0 |

-------------------------------------------------------------------------------------------------------------------

You mentioned a similar ticket/thread on the ST forum, Sometime, we are also getting the same exception (Logs below) when trying to access the USART6 (ttySTM1). Stopping the 'st-m33firmware-load.service' helps in this

case.root@stm32mp2:~# echo "test" > /dev/ttySTM1
E/TC:0 stm32_serc_handle_ilac:133 SERC exceptions [63:32]: 0x10
E/TC:0 stm32_serc_handle_ilac:139 SERC exception ID: 36

-------------------------------------------------------------------------------------------------------------------

From our end, We are just shorting Tx-Rx pins (loopback) available on the GPIO header pins and writing (echo  "test" > /dev/ttySTM1) to the USART. But we can't see anything coming on the ttySTM1 device.

[GatienC]

Hello Mayank,

When you disable the M33 firmware, you still get the SERC and nothing on the ttySTM1 device or the SERC occurrences disappear? Can you try to disable the service instead of stopping it? So that the kernel does not launch the M33 Firmware at all.

Cheers,
Gatien

[mayank_7117]

Hello @GatienC ,

• After stopping the M33 firmware services, the SERC disappears when I try to open /dev/ttySTM1, But my main observation is this:

• When /dev/ttySTM1 appears in the tty device list, the hardware clock for USART6 is not active by default.  
• However, if I open minicom from another SSH session of the board on the same port (/dev/ttySTM1), the hardware clock for USART6 becomes active.
• Once the minicom of port /dev/ttySTM1 connection is closed, the clock gets disabled again — why does this happen?
• Due to this behavior, I’m unable to establish a stable Bluetooth connection through USART6 (I'm using the external WiFi+BT module and connecting it to the board over USART6 to access the Bluetooth). I get a timeout error unless I manually open the port with minicom, which triggers the clock to turn on, allowing communication with the BT device.
• Is there a way to keep the hardware clock for USART6 enabled by default when the tty port is created?

[GatienC]

Hi

I don't have a straightforward answer as I'm not an expert of this domain. Maybe someone else from ST or the community is able to answer?

A workaround could be making the USART6 clock critical (CLK_IS_CRITICAL flag to set on this clock) to add to test your functionality.

Cheers,

Gatien