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,

Hi Pauli, If you are able to do what you want with Cube HAL then, to interface with zephyr, you just need to redefine the HAL callback (defined as weak in HAL drivr) in your zephyr application. You ca

#stm32

Hi Neo I'd advise you to have a look to STM32 clock control driver. It provides MCO support. It might not provide exactly the requested configuration, but at least it would be a working point that you

#stm32

Hi all, Optional property 'erase-block-size' is used to describe the minimum size of flash sector on which an erase operation could be applied. It is generated as a device tree generic define DT_FLASH

Hi Murad, Seems Cmake somehow convert you build path to a reserved Cmake string that trigger the issue. I'm not familiar with build on windows, but I'd suggest to work around your build path. Erwan

Hi Gustavo, Sorry, I'm not familiar with Dragino, nor J-Link, maybe Endre would know better, as he did the board port. Erwan