Changing Default Debug UART on STM32MP257F-EV1

[Bar01]

Hi everyone,

I’m currently working with the STM32MP257F-EV1 evaluation board and would like to change the default UART used for debug output. By default, the EV1 board uses USART2 via the STLINK USB port for debug. However, for testing purposes, I’d like to reroute the debug console to USART6 so I can read debug messages from the header pins on the board. I’ve tried editing the device tree by modifying the chosen node and changing the parameter:

stdout-path = "serial0:115200n8";

to:

stdout-path = "serial1:115200n8";

According to my aliases, serial1 should correspond to USART6. However, after making this change, I encounter a watchdog panic very early during boot:

m32_serc_handle_ilac:133 SERC exceptions [63:32]: 0x10  
E/TC:0   stm32_serc_handle_ilac:139 SERC exception ID: 36  
E/TC:0   Panic 'Watchdog' at /usr/src/debug/optee-os-stm32mp/4.0.0-stm32mp-r1/core/drivers/stm32_iwdg.c:228 <stm32_iwdg_it_handler>

Based on this post I tried masking the st-m33firmware-load.service and applied it to a clean, freshly built image to ensure it executed properly, but I’m still getting the same error.

My questions are:

• Is it actually possible to switch the default debug UART on the STM32MP257F-EV1 board?
• If so, what other device tree or configuration steps might be necessary to get the debug console working on USART6?

Any insights would be greatly appreciated.

Thanks!

[Bar01 · Accepted solution]

I wanted to share an update — I managed to find a solution to the issue I mentioned earlier, and I’d be happy to share it in case it helps others.

The SERC exception (ID 36) was due to a mismatch between the early initialization of pins and the U-Boot configuration. According to the reference manual, certain UART peripherals (like USART6) are protected by the SERC (Secure Error Recovery Controller), which is responsible for managing secure access to peripherals during early boot.

This exception happened because the UART peripheral was either in reset state or not properly enabled at the time the debug output was requested. When the kernel or OP-TEE attempted to use the UART pins before the peripheral was fully initialized (or before proper device tree flags were set), the SERC detected an unauthorized or invalid access attempt and raised an exception.

To fix this, as described in this link I added the bootph-all; flag to the relevant pin configurations in the U-Boot device tree. The bootph-all; directive ensures that the relevant pins are initialized early enough during the U-Boot phase so that the kernel (or OP-TEE) does not try to access a peripheral that’s still locked by the SERC. Here’s a step-by-step outline of what I did:

• Initialized a devtool workspace:

devtool modify u-boot-stm32mp  ​

• Edited the file ...workspace/sources/u-boot-stm32mp/arch/arm/dts/stm32mp257f-ev1-u-boot.dtsi by adding 

...
&usart6 {
 bootph-all;
};

&usart6_pins_a {  
    bootph-all;  
    pins1 {  
        bootph-all;  
    };  
    pins2 {  
        bootph-all;  
    };  
};  

• I also updated the stdout-path and relevant aliases in workspace/sources/u-boot-stm32mp/arch/arm/dts/stm32mp257f-ev1.dts
  

After rebuilding and flashing the image onto the board, I needed to adjust the U-Boot console variable. I did this by booting into U-Boot on the board, then mounting the partition on my VM using

STM32MP> ums 0 mmc 0  

and editing .../boot/mmc0_extlinux/stm32mp257f-ev1_extlinux.conf. Instead of using ${console}, I hardcoded ttySTM1 — I know that’s not the cleanest solution, but it worked as a quick test.

I hope this guide is helpful for anyone facing the same issue.