stm32u0: interrupt vectors for lpuart1 and lpuart2 are wrong in device tree

[AUtech-dev]

Describe the bug

https://github.com/zephyrproject-rtos/zephyr/blob/main/dts/arm/st/u0/stm32u0.dtsi#L250-L266 defines the lpuart instances 1 and 2 as followed:

		lpuart1: serial@40008000 {
			compatible = "st,stm32-lpuart", "st,stm32-uart";
			reg = <0x40008000 0x400>;
			clocks = <&rcc STM32_CLOCK(APB1, 20U)>;
			resets = <&rctl STM32_RESET(APB1L, 20U)>;
			interrupts = <28 0>;
			status = "disabled";
		};

		lpuart2: serial@40008400 {
			compatible = "st,stm32-lpuart", "st,stm32-uart";
			reg = <0x40008400 0x400>;
			clocks = <&rcc STM32_CLOCK(APB1, 7U)>;
			resets = <&rctl STM32_RESET(APB1L, 7U)>;
			interrupts = <29 0>;
			status = "disabled";
		};

Meaning that lpuart1 uses interrupt vector 28 and lpuart2 uses vector 29.

However, the reference manual RM0503 show the following interrupt vectors in table 54 (yellow highlight by me):

This means that lpuart1 uses interrupt vector 29 and lpuart2 uses vector 28.

---

The lpuart works with the polling uart API. Using the Interrupt-driven API no interrupt callback is performed.

This can be fixed with the following device tree overlay:

&lpuart1 {
	interrupts = <29 0>;
};

&lpuart2 {
	interrupts = <28 0>;
};

Regression

• This is a regression.

Steps to reproduce

• use either lpuart1 or lpuart2 on a STM32U0 based device (mine is stm32u073Xc and lpuart1)
• observe that receiving data from this lpuart works with the polling API (uart_poll_in() outputs data as expected)
• use the interrupt driven API and enable the RX interrupt with uart_irq_rx_enable()
• observe that the interrupt callback is not called
• apply the above device tree overlay
• observe the interrupt callback being called as expected

Relevant log output

Impact

Functional Limitation – Some features not working as expected, but system usable.

Environment

zephyr/dts/arm/st/u0/stm32u0.dtsi

Lines 250 to 266 in e22ca6b

	lpuart1: serial@40008000 {
	compatible = "st,stm32-lpuart", "st,stm32-uart";
	reg = <0x40008000 0x400>;
	clocks = <&rcc STM32_CLOCK(APB1, 20U)>;
	resets = <&rctl STM32_RESET(APB1L, 20U)>;
	interrupts = <28 0>;
	status = "disabled";
	};
	lpuart2: serial@40008400 {
	compatible = "st,stm32-lpuart", "st,stm32-uart";
	reg = <0x40008400 0x400>;
	clocks = <&rcc STM32_CLOCK(APB1, 7U)>;
	resets = <&rctl STM32_RESET(APB1L, 7U)>;
	interrupts = <29 0>;
	status = "disabled";
	};

Bug was seen on a custom hardware using a stm32u073Xc and lpuart1 with Zephyr v4.2.0-rc1.

Additional Context

No response