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 · Accepted solution]

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

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

[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