Ok, can you raise an issue in github? We'll get it fixed.

Hi Dmitry, Could you try something like: static int uart_stm32_irq_is_pending(struct device *dev) { USART_TypeDef *UartInstance = UART_STRUCT(dev); return ((LL_USART_IsActiveFlag_RXNE(UartInstance) &&

Hi Dmitri, Can you explicit the functional issue, before we do any change? About TXE: TXE is "TX ready", hence indeed likely to be often 1 indeed. Then, this code is located in isr callback, hence it

Hi Pushpal, For now, I don't see good reason why it would not fit in stm32l4xx series. So let put it there. Cheers Erwan

Hi, I don't have time to test this yet, but looking into STM32F303 reference manual, it seems that I2C on F3 is clock independent and hence, we should sepcify clock before using it. It seems this case

Hi Pushpal, Regarding the blinky issue. It's happening since CONFIG_GPIO_STM32_PORTD is not activated. You should add it in board defconfig. Then, regarding the debug issue. Have you tried make BOARD=

Hi Aaron, BlueNRG chip are actually already supported (even if deeper testing would be welcome). To activate it, you could have a look to Disco L475 IoT board configuration. Cheers Erwan

Quick status about device tree: *Pinmux is not yet generated thanks to dts files. Only pinmux.c matters *Today, on STM32 dts files, only UART pinctrl is taken into account So related to FSMC, you just

As said earlier, you can directly access HAL code in your application, no problem with that. Point is CONFIG_ flags and Kconfig files are designed to enable "typical" use of Zephyr (through Zephyr API

Hi, This is the correct understanding, you need to modify Makefile/Kbuild to access HAL drivers. Then, if you need to use some driver in an application, you'd theoretically use zephyr HW API and drive

Hi Max, I was planning to do an update in the coming week (following V1.9.0 release). You can do it for F4, I'll take care oth the others. Cheers

You're right PA15 (usart2_pins_b) could not be connected to USART2. This is a real issue, and this is true for whole F4 series, not only F412. I'll correct it. Thanks

Hi, According to stm32f412zg datasheet, usart2_pin_c is actually supported on stm32f412zg, so I don't see issue to populate it in stm32f4-pinctrl.dtsi. Besides, as mentioned by Andy, it's not a proble

And if connected to HW, should it be enabled and clocked? Linux uses mix of Kconfig/dt. Kconfig for compilation/dt for activation. Do we want the same in Zephyr and keep these 2 levels of configuratio

Hi Felix, From what I'm aware of, there is no such plan. Though, I know Neil as some L0 port working on his own (though on SoC STM32L053). I'm not sure what are his plans on that, but maybe you could

Hi Yannis, Thanks for this proposition. We are indeed missing I2C driver for STM32F4 family. What would be really nice is to get a generic STM32 I2C driver, working on all series (based on LL STM32Cub

No problem, I understand it is not easy to jump in. And agreed we might miss some material to make all this clear. Great! We look forward to see it upstreamed Seems right!

Hi Erwin, LL based version was initiated without knowing Neil had a HAL based driver, and from what I am aware of (unless I missed this information), Neil never proposed to upstream it. I let him comm

Hi Erwin, As mentioned by Neil, CONTAINER_OF is a good solution that is used in other projects using STM32Cube. About your last point: There won't be any branching from STM32Cube for Zephyr. Generic b

Hi Erwin, Thanks for proposing this driver, I think it will interest a lot of people. About your last point, let me mention ST view on this: This is a question of trade-off. Using HAL has some drawbac