After pulling latest commit(7c290b053df8e9b973f6436198f3a89902a1e977), the startup hangs when printing chars to the UART.
Call stack trace:
uart_stm32_poll_out() at uart_stm32.c:59 0x8007dd2
_impl_uart_poll_out() at uart.h:257 0x8006024
uart_poll_out() at uart.h:17 0x8006024
console_out() at uart_console.c:110 0x8006024
char_out() at printk.c:265 0x8002a72
_vprintk() at printk.c:103 0x8002e2e
vprintk() at printk.c:290 0x8002e54
printk() at printk.c:340 0x8002e6e
bg_thread_main() at init.c:215 0x8008252
_thread_entry() at thread_entry.c:29 0x80025c0
_Cstart() at init.c:485 0x80082b8
__config_i2c_stm32_1() at 0x8009780
hang at uart_stm32.c in
static unsigned char uart_stm32_poll_out(struct device *dev,
unsigned char c)
{
USART_TypeDef *UartInstance = UART_STRUCT(dev);
/* Wait for TXE flag to be raised */
>>> while (!LL_USART_IsActiveFlag_TXE(UartInstance))
;
LL_USART_ClearFlag_TC(UartInstance);
this function is called from init.c:
static void bg_thread_main(void *unused1, void *unused2, void *unused3)
{
...
PRINT_BOOT_BANNER();
...
I am using the a slightly different version of the
with following dts changes:
chosen {
zephyr,console = &usart1;
zephyr,sram = &sram0;
zephyr,flash = &flash0;
};
soc {
pinctrl: pin-controller@40020000 {
usart1_pins_d: usart1_3 {
rx_tx {
rx = <STM32_PIN_PA10 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUPDR_NO_PULL)>;
tx = <STM32_PIN_PA15 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUSHPULL_PULLUP)>;
};
};
...
&usart1 {
current-speed = <115200>;
pinctrl-0 = <&usart1_pins_d>;
pinctrl-names = "default";
status = "ok";
};
@StefJar
What was your previous sha1?
What board are you using?
Do you mean that banner does not print correctly in eg hello_world?
@sha1 sorry I don't know the exactly one. Guess the last form Friday(09-11-2018).
@board: a custom board. It's comparable to the nucleo_f412zg BUT I redirected the console form uart3 to uart1. these uart1 has a different pin use. That's why I added the usart1_pins_d node to the pin control
@PRINT_BOOT_BANNER(): this prints the boot message of zephyr os like version & hash
Maybe commit : 6d1a31b3fca9bd879c07467e4743b275bb76701f
or bd7387947e5ffc5f9bdc02064a4ad66cdde263f5 breaks the power up sequence
To make it clear. The PRINT_BOOT_BANNER function is called at the starting of the main thread/kernel. It loops now infinite in the uart_stm32_poll_out function
ok, I think I got the issue.
Looks like a clock configuration issue in dts.
In dts/arm/st/f4/stm32f4.dtsi, can you try the following change:
usart1: serial@40011000 {
compatible = "st,stm32-usart", "st,stm32-uart";
reg = <0x40011000 0x400>;
- clocks = <&rcc STM32_CLOCK_BUS_APB2 0x00004000>;
+ clocks = <&rcc STM32_CLOCK_BUS_APB2 0x00000010>;
interrupts = <37 0>;
status = "disabled";
label = "UART_1";
};
I can confirm that the clock change to
clocks = <&rcc STM32_CLOCK_BUS_APB2 0x00000010>;
solves that issue
Verified the proposed fix also on ArgonKey board.
Thx!
Most helpful comment
ok, I think I got the issue.
Looks like a clock configuration issue in dts.
In dts/arm/st/f4/stm32f4.dtsi, can you try the following change: