Hi Kevin, Thanks for reporting this. Would you mind creating a github issue ? We'll investigate the point BR Erwan

#ble #bluetooth #stm32

Hi Philippe, There could be multiple reasons, but we'd need reported errors to be able to help. Also, maybe you can open a github discussion and provide details (errors, build environment, ...) for fo

Hi all, I'd like to inform STM32 PWM users that I'm pushing a change [1] to harmonize the default value of property "st,prescaler" to 0 for all pwm nodes on all (STM32) SoCs. Benefit is to solve the c

Hi Chuck, Thanks for reporting this, this behavior seems indeed unusual. Can you raise a dedicated issue in github ? Cheers Erwan

Hi, We've started to transition STM32 clock system configuration from Kconfig to dts. The main change (that introduces the whole mechanism) has been merged earlier this week, making it available to L4

Awesome, thanks for sharing Artie!

Hi Gunnar, Unfortunately, we miss code for PLL2 configuration as PLL input. Though, I'm adding Attie who investigated that point and may have code to get it working. BR Erwan

First it depends what you intend to do with LPTIM. There is a LPTIM driver which is meant to be used as a low power kernel ticker instead of the Cortex systick. You can enable it in any sample using C

Hi Thomas, There is no STM32F101 port indeed. Though there are others variants of STM32F1 series available. So I don't expect too much trouble when adding STM32F101 support. You could find below a rec

#stm32

Hi Naro, Have you tried to revert the faulty commit and see if this fixes the issue in your case ? (To make it work, you might have to remove #ifdefery around `SOC_STM32F10X_DENSITY_DEVICE`. Cheers Er

Hi Raz, Did you checked that the clocks are correctly enabled? In any case, I'd suggest to minimize the use of Cube functions to the timer related functions. Zephyr provides most of things you need fo

Hi Ron, First question: do you have the matching FRAM that is described on the sample ? If yes, I'd suggest adding "spi_1 = &spi1;" in your board aliases, and hopefully this should work. BR Erwan

Hi Michael, When available, peripheral drivers of one SoC series should work with all boards using SoC of this series. Peripheral configuration is not done systematically on all the boards, as it requ

#can #ethernet

Hi Uwe, Looking at the board device tree description, USB is actually supported on this board: &usb { status = "okay"; pinctrl-0 = <&usb_dm_pa11 &usb_dp_pa12>; }; I'll update the doc to reflect this s

Hi Matthias, Indeed this dynamic behavior is not implemented. As you can see in vl53lx driver, vl53l0x_init make use of DT_INST_FOO(0, bar) macros. Which means only the information from instance 0 are

Thanks for feedback. I don't see a particular reason why some channels would not work. For pins, there's alway a possibility of pin conflicts (as I can see that pa8 is also used on i2c2). So please ta

Hi Florian, You also need to configure a pin, something like: &timers2 { status = "okay"; pwm2: pwm { status = "okay"; + pinctrl-0 = <&tim2_ch1_pwm_pa5>; }; }; Please let us know if this was helpful.

Hi Sarvg, To configure a pin in a gpio mode, please have a look to the gpio API (you'll find exemples under tests/drivers/gpio) Chevets Erwan

TL;DR: - Upcoming device tree based pin configuration for STM32 based boards - Script generated, SoC package specific *-pinctrl.dtsi files are available in hal_stm32 modules - Each *.pcintrl.dtsi file

Thanks Brix. Helge, FYI, you might be interested in https://github.com/zephyrproject-rtos/zephyr/issues/27985 that will work around the issue for V2.4.0. BR Erwan