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

Hi Helge, Looking into it quickly, there has been no change in the init priorities on gpio or pinmux. board pinmux init: PRE_KERNEL_1 gpio init: POST_KERNEL So, what seems strange also is that it had

Additionally to Carles's answer, let me point you to an on going PR that aims at implementing lp modes on stm32: https://github.com/zephyrproject-rtos/zephyr/pull/19026 It only supports L4/WB series f

Hi, Can you check https://github.com/zephyrproject-rtos/hal_stm32#use-stm32cube-in-your-application and see if solving your issue ? Cheers Erwan

Hi Trevor, What is the error reported ? Erwan

You might just miss a "west update".

#stm32

Hi David, I'm not a SWO user myself but I'm suspecting a clock set up issue. On FreeRTOS, what was the clock configuration you were using ? Cheers

#debugging

Hi Zephyr users, In order to benefit from a wider range of user options [1], I'm proposing in PR 21791 to upgrade requirement for pyocd to version 0.24.0. Change should not have impact for most users,