STM32MP257, USART and SERC exception

[altsir_sga]

Hi,

I am trying to use USART6 on STM32MP257F-DK development board. I have enabled it in the device tree, recompiled it and I now can see the /dev/ttySTM1 node. The problem is, that sometimes, after reboot, any access to the USART (even changing its baudrate using stty -F /dev/ttySTM1 command) causes SERC exception (with ID 36 which corresponds to USART6) to happen.

This does not happen all the time, but most of the time. Once and it doesn't happen after boot it won't happen again until next reboot and the UART works just fine.

here my device tree change:

&usart6 {
pinctrl-names = "default", "idle", "sleep";
pinctrl-0 = <&usart6_pins_a>;
pinctrl-1 = <&usart6_idle_pins_a>;
pinctrl-2 = <&usart6_sleep_pins_a>;
/delete-property/dmas;
/delete-property/dma-names;
status = "okay";
};

 

it seemed first that disabling the DMA helps, but I am not so sure now

usart6_pins_a: usart6-0 {

pins1 {

pinmux = <STM32_PINMUX('F', 13, AF3)>; /* USART6_TX */

bias-disable;

drive-push-pull;

slew-rate = <0>;

};

pins2 {

pinmux = <STM32_PINMUX('F', 14, AF3)>; /* USART6_RX */

bias-pull-up;

};

};

 

usart6_idle_pins_a: usart6-idle-0 {

pins1 {

pinmux = <STM32_PINMUX('F', 13, ANALOG)>; /* USART6_TX */

};

pins3 {

pinmux = <STM32_PINMUX('F', 14, AF3)>; /* USART6_RX */

bias-pull-up;

};

};

 

usart6_sleep_pins_a: usart6-sleep-0 {

pins {

pinmux = <STM32_PINMUX('F', 13, ANALOG)>, /* USART6_TX */

<STM32_PINMUX('F', 14, ANALOG)>; /* USART6_RX */

};

};

 

Thanks!

Alexey.

[GatienC]

Hello Alexey,

I've seen several posts on the use of the USART6 and after discussion with team members, the USART6 is used by the UCSI firmware running on the cortex M33. Therefore, I think you have concurrent access (A35 + M33) to the same USART + its clock. If you do not need USB type-C on this board, you either try to stop or disable the service that handles the M33 firmware:

systemctl stop st-m33firmware-load.service

or

systemctl disable st-m33firmware-load.service

 

If you need the type-C, you'll have to recompile the UCSI Cube project (https://github.com/STMicroelectronics/STM32CubeMP2/tree/main/Projects/STM32MP257F-DK/Demonstrations ) and remove the trace. It should be the "_TRACE" switch

(looking at USBPD_DRP_UCSI/CM33/NonSecure/USBPD/App/usbpd_ucsi_if.c)

But I haven't tested it :)

I hope this helps,

Gatien

 

[sanjaysb]

Hi @GatienC

Earlier i was getting this error (FYR attached below), I disabled st-m33firmware-load.service and able to set the baudrate, but unable to debug the usart6 now using the below command, im using UART to USB Convertor for debugging im getting no output

root@stm32mp25-eval-e3-e4-6a:~# stty -F /dev/ttySTM1 115200
root@stm32mp25-eval-e3-e4-6a:~# echo "test" > /dev/ttySTM1 
root@stm32mp25-eval-e3-e4-6a:~# echo "test" > /dev/ttySTM1 
root@stm32mp25-eval-e3-e4-6a:~# echo "test" > /dev/ttySTM1 

$ stty -F /dev/ttySTM1 115200
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
[ 39.106314] SError Interrupt on CPU0, code 0x00000000bf000002 -- SError
[ 39.106336] CPU: 0 PID: 1618 Comm: stty Tainted: G O 6.6.78 #1
[ 39.106344] Hardware name: STMicroelectronics STM32MP257F-EV1 Evaluation Board (DT)
[ 39.106348] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 39.106357] pc : stm32_usart_rx_dma_start_or_resume+0x80/0x234
[ 39.106375] lr : stm32_usart_startup+0x8c/0x130
[ 39.106383] sp : ffff80008352b950
[ 39.106385] x29: ffff80008352b950 x28: ffff000093789080 x27: 0000000000020800
[ 39.106399] x26: ffff800081037828 x25: ffff800081037468 x24: 0000000000000000
[ 39.106409] x23: 0000000000000000 x22: ffff00008c5b5c00 x21: ffff8000819fd088
[ 39.106419] x20: 0000000000000000 x19: ffff800081b19210 x18: 0000000000000001
[ 39.106428] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
[ 39.106437] x14: 0000000000000000 x13: 006c61697265732e x12: 3030303032323034
[ 39.106447] x11: 0000000000000037 x10: ffff80008112e9b8 x9 : 0000000000000000
[ 39.106457] x8 : ffff00008c52d0c0 x7 : 0000000000000000 x6 : ffff8000819a3ce8
[ 39.106466] x5 : ffff00008246ce08 x4 : ffff00008246cec8 x3 : 0000000000000000
[ 39.106476] x2 : ffff800081e05000 x1 : 0000000000000000 x0 : ffff0000818b2080
[ 39.106488] Kernel panic - not syncing: Asynchronous SError Interrupt
[ 39.106491] CPU: 0 PID: 1618 Comm: stty Tainted: G O 6.6.78 #1
[ 39.106497] Hardware name: STMicroelectronics STM32MP257F-EV1 Evaluation Board (DT)
[ 39.106501] Call trace:
[ 39.106505] dump_backtrace+0x94/0x114
[ 39.106517] show_stack+0x18/0x24
[ 39.106526] dump_stack_lvl+0x48/0x60
[ 39.106535] dump_stack+0x18/0x24
[ 39.106542] panic+0x324/0x380
[ 39.106550] nmi_panic+0x8c/0x90
[ 39.106557] arm64_serror_panic+0x6c/0x78
[ 39.106563] do_serror+0x3c/0x70
[ 39.106569] el1h_64_error_handler+0x30/0x48
[ 39.106578] el1h_64_error+0x64/0x68
[ 39.106584] stm32_usart_rx_dma_start_or_resume+0x80/0x234
[ 39.106592] stm32_usart_startup+0x8c/0x130
[ 39.106600] uart_startup+0x13c/0x2fc
[ 39.106609] uart_port_activate+0x34/0x9c
[ 39.106616] tty_port_open+0x8c/0x13c
[ 39.106625] uart_open+0x1c/0x30
[ 39.106632] tty_open+0x138/0x6dc
[ 39.106639] chrdev_open+0xbc/0x208
[ 39.106649] do_dentry_open+0x1b0/0x524
[ 39.106660] vfs_open+0x2c/0x38
[ 39.106666] path_openat+0xb14/0xdf0
[ 39.106676] do_filp_open+0x9c/0x14c
[ 39.106684] do_sys_openat2+0xc4/0x104
[ 39.106691] __arm64_sys_openat+0x64/0xac
[ 39.106697] invoke_syscall+0x48/0x114
[ 39.106706] el0_svc_common.constprop.0+0x40/0xe0
[ 39.106715] do_el0_svc+0x1c/0x28
[ 39.106723] el0_svc+0x38/0xc8
[ 39.106731] el0t_64_sync_handler+0x120/0x12c
[ 39.106738] el0t_64_sync+0x190/0x194
[ 39.106746] SMP: stopping secondary CPUs
[ 39.106761] Kernel Offset: disabled
[ 39.106763] CPU features: 0x0,00000000,00020000,0000421b
[ 39.106769] Memory Limit: none
[ 39.367284] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]---

CTRL-A Z for help | 115200 8N1 | NOR | Minicom 2.9 | VT102 | Offline | ttyACM0 

 

[altsir_sga]

Hi,

I believe the baudrate set command should be: stty -F /dev/ttySTM1 ispeed 115200.

 

Regards,

Alexey.

[altsir_sga]

Hi Gatien,

I have disabled the M33 firmware (don't need USBC), and looks like it helped. Although I cannot fully understand why as M33 firmware uses UART5, not USART6. Is there any relation between those or maybe something else is going on?

 

Thanks!

Alexey.

[jumman_JHINGA]

 

Hi @altsir_sga,

After you disabled the M33 firmware and retried accessing UART6, did you encounter any runtime errors such as:

sh: write error: Device or resource busy

I'm asking because this error typically appears when another subsystem still holds the UART resource, even if it’s not the exact UART instance you’re using. I’m trying to understand whether you observed the same behavior on your side.

[altsir_sga]

Hi,

After disabling the M33 firmware I didn't have any further problems with UART6.

 

BR,

Alexey.

[GatienC]

Hi Alexey,

From my understanding, this M33 firmware uses 2 UARTs, one for its console and the other for USB debug traces. I haven't manipulated this firmware so I cannot be 100% sure but that's the information I got from discussions.

Good to know it "solves" the issue!

Best regards,

Gatien

[ArnaudP]

Hello Alexey,

The USBPD firmware allows to manage the USB power delivery protocol USB type C.
- UART5 is the default application console for the CortexM33 
- USART6 is used to output USBPD traces in a specific format.

 

Regards,
Arnaud

[ArnaudP]

Hello,

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

Means that you are trying to access to the peripheral ID 36 while it is not clocked.
Referring to the reference manual Table 1002. SERF resources mapping, The ID 36 corresponds to the USART6.
Did you enable the USART6 clocks?

As described in https://wiki.st.com/stm32mpu/wiki/UCSI_overview#Tracing_Linux_UCSI_core_with_ftrace

You can also try to remove the _TRACE compilation symbol to disable the UCSI traces on USART6

BR,
Arnaud

[GatienC]

Hello,

By that, I mean that the UCSI firmware running on the CortexM33 default uses the USART6. So if USART6 is not isolated to a compartment and that both Cortex A35s and M33 access it, then you'll get an erratic behavior because 2 independent entities use the same peripheral (concurrent clock and registers accesses). There is nothing preventing you from using the USART6 on Cortex A35s, but do not use the UCSI firmware then... Or change the USART it uses.

Best regards,

Gatien