Hi Ivo, Not sure what could be the issue. Dont hesitate to raise an issue in github and we'll have a look. Thanks Erwan

#bluetooth

If you look at code under BT_SPI_BLUENRG, you'll see that it proposes some specific code that was required to add on top of bare hci_spi driver to get the module working. I haven't add a look to other

Hello Daniele, You're globally in the right direction, but please note that stm32l562_dk actually uses a SPBTLE-RFTR module, based on BlueNRG-MS (BLE v4.1). SensorTile board use, depending on version:

Hi Per-Erik, There's an on-going change in mcuboot to support extended write sizes: https://github.com/mcu-tools/mcuboot/pull/1217 This should help in the support of H7 and I guess you should start fr

Hi, There's actually a PR proposed to solve this: https://github.com/zephyrproject-rtos/zephyr/pull/38561 Please have a test

#stm32 #jlink

Hi Garret, Unfortunately no, BT is not enabled on this platform. Actually the bluetooth application processor (BlueNRG-M2) is not ported in Zephyr yet. This might not be a major work as it would consi

#bluetooth #stm32 #hci

Adding Armando as codeowner of this driver.

Hi Mithun, Seeing this: File "C:\Users\username\zephyrproject\zephyr\scripts/west_commands\runners\openocd.py", line 114, in do_run self.require(self.openocd_cmd[0]) It seems that west is attempting t

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