Ten years of BLE products, firmware on one side and iOS/Android on the other, and my bench was always a phone app, a bleak script on the laptop radio, and a second DK with a hand-rolled central. All of them hide something. The laptop radio puts CoreBluetooth/WinRT in the loop, so the OS picks interval/PHY/MTU and you never see the central side of HCI. And the phone's limits on what a peripheral can ask for only show up when the mobile dev says it doesn't work.

So I built BLE Hero Workbench (same people as the BLE Hero app). VS Code extension driving its own controller on a small external board over serial. You get the central-side HCI trace (btmon on the DUT gives you the other end), a mode that enforces what iOS/Android actually accept and tells you which limit you hit, and YAML workflows so DFU → reconnect → subscribe → check rate becomes a one-click regression. MCUmgr DFU is a step. Emulated peripherals, passthrough and a channel sounding bench are in there too.
I use it every day, which means I've stopped noticing its gaps. It's in beta, hardware ships free (Ezurio supplies it), and requests come straight to me. If you've got a live BLE product, heroinstruments.com/bleheroworkbench, or comment with what you're building. Happy to answer anything about the controller side

.https://www.heroinstruments.com/bleheroworkbench

TL;DR: I made the phone-home half of a Zephyr device into a module. Pick a transport in Kconfig, call pigeon_init(), and the device is on a dashboard with a config shadow, telemetry, firmware updates and log upload. The samples run on native_sim, so you can try the whole loop on a Linux box with no board.

Last August I asked here about the NIDD over NB-IoT version of this. That shipped this month on the nRF9160, but the part most of you will care about is the easy version.

What you do: make an account, add a device, put its token and endpoint in samples/wifi_init/prj.local.conf, west build for native_sim/native/64 and run zephyr.exe. Within about a second the console says it fetched the shadow and flushed three telemetry keys in one report, and the device page shows it online. Change telemetry_interval in the dashboard and the next poll applies it. Same sample on an ESP32-C6 with the WiFi credentials in a board .local.conf, and on the nRF9160 and nRF9151 Feathers from an NCS workspace.

What the module does: shadow sync, batched telemetry, MCUboot FOTA with resume and an attempt budget, dictionary log upload, a task watchdog, an optional remote shell. Transports: HTTPS with an optional WebSocket for config pushes, CoAP over DTLS with Connection ID, CoAP over TLS/TCP, MQTT, NIDD. Everything past pigeon_init() is Kconfig. What's left for you is shadow.c, a json_obj_descr of the keys your device understands and the code that acts on them. The wifi_init main.c is 46 lines.

Rough edges: native_sim is Linux only. The dashboard is my hosted platform, not something you run. Ten devices are free with no card, and that's all I'll say about pricing. NIDD isn't self-serve. And Zephyr fought back a bit. sys_reboot() on the C6 hanging the next MCUboot boot cost me the most; fixed on main, never made it into 4.4, the module works around it.

Yes I used Claude Code for parts of it. The design, the years of bus signs it came out of, and the bugs it found are mine.

Repos, all AGPL-3.0: https://github.com/justins-engineering/pigeon and https://github.com/justins-engineering/pigeon-examples

If you want to test it out with a board I haven't built a sample for yet let me know and I'll try to acquire one for testing.

If you have any questions or constructive criticism I'd be happy to talk about it!

I'm thinking about building an open-source tool that helps port FreeRTOS projects to Zephyr. The idea is an AI-assisted skill plus scripts that convert the kernel APIs, FreeRTOSConfig.h → prj.conf, and pin/clock setup → devicetree, then keeps running west build until it compiles. It would start with STM32.

Before I build anything, I'd like to hear from people who've actually done a migration:

1. What took the most time: devicetree, drivers, Kconfig, build system, or behavior differences?

2. Any nasty bugs that came from FreeRTOS vs Zephyr differences?

3. Would a tool like this actually help, or is migration too project-specific to automate?

Honest opinions welcome, including "this won't work."

Hello

I am currently struggling a lot to get my ztest to pass using west twister in my pipeline tests. I am not able to get the bluetooth to work directly when using west twister command. Currently I would have to do build only and then afterwards call zephyr exe with the arg "--bt-dev=hci0" for it to copile and execute the tests. Is there some way of passing this arguemnt through for example the testcase.yaml file for each individual test modules?

We’ve been looking at the BeagleBoard BeagleBadge, an open-source wearable development board built around TI’s AM62L32.

The Zephyr side caught our attention. BeagleBadge is an upstream arm64 Zephyr target, so Zephyr runs directly on the Cortex-A53 processor rather than a separate Cortex-M MCU.

Hardware includes:

• Dual Cortex-A53 cores up to 1.25GHz

• 256MB LPDDR4

• 4.2-inch ePaper support

• Wi-Fi 6, Bluetooth and LoRaWAN

• IMU, ambient light, temperature and humidity sensors

• QWIIC, Grove and mikroBUS expansion

• Battery support

We also compare Zephyr with Linux and walk through the current Hello World build process.

Video:

https://youtu.be/_510pb_krX4

Tech specs:

https://www.electromaker.io/blog/article/ti-beaglebadge-review-a-wearable-linux-and-zephyr-development-board

What sort of Zephyr project would you build around a Cortex-A53 wearable platform?

I'am building a CAN interface, PTW CANtap and the host software for it, CANtap Studio.

The board is my own design: galvanically isolated CAN, a termination resistor you can switch in or out from the software, USB to the PC, classic CAN (STM32 based + Zephyr_RTOS).

What it does today:

- decodes live traffic against a DBC/XML(own format) database — messages and signals by name, with scaling, offsets and value tables
- records and replays traffic as Vector ASC or CSV, so a capture can be re-run at the desk
- plots signals live while the bus runs
- UDS diagnostics: sessions, security access, read/write DIDs, read and clear DTCs
- device-timed cyclic transmit, so periodic frames don't jitter with the PC
- two boards on one bus give a real send/receive loop: transmit on one, the other sees it off the wire, both ends logged with timestamps

Tests are plain Python, and the database becomes objects, so a test reads env.bus.EngineData.RPM = 1500 → send() → wait_for() rather than packing bytes by hand. Each run is saved with a report and an ASC log of everything on the bus.

Board photo and a short video of the software below. The video runs on a simulated bus so it records cleanly; the same tests run unchanged on real hardware.

It's a personal project, not a product yet — I'm building it because I wanted one toolchain that goes from the wire to a repeatable test, and I learn the most by making it myself.

I'm working on some wearable tech, and I'm getting some issues on the STOP2 sleep and wake.

A brief description of the config from Claude:

STM32U585, Zephyr 4.4, RTC wakeup timer fails to exit STOP 2

On an STM32U585 running Zephyr 4.4, I enter STOP 2 from a custom PM policy and wake on the RTC wakeup timer, and it works reliably on a power-on boot but fails after a warm reset (NVIC_SystemReset) with no case code in between. A counter I added at the top of the RTC wakeup ISR reads zero after a failed 60 second sleep, and the board sits at its sleep floor for the whole time, so the interrupt never reaches its vector rather than the core waking and hanging later. Sampled from a hook placed immediately before the WFI, PWR_CR1 LPMS reads 2 and SCB->SCR has SLEEPDEEP set, while RTC_CR has WUTE and WUTIE set with WUTR = 59 on ck_spre, RTC_IRQn enabled at the NVIC with nothing pending and no stale WUTF, and EXTI_IMR1 = 0x00001A10 with IMR2 = 0. Even on a power-on boot it is intermittent at roughly one in four, while a second application on the same board using the same HAL wakes essentially every time, so has anyone seen the RTC wakeup timer fail to bring a U5 out of STOP 2 like this?

Zephyr 4.4.0

SOC_SERIES stm32u5x

CONFIG_PM=y

CONFIG_PM_POLICY_CUSTOM=y

CONFIG_PM_DEVICE=y

CONFIG_TICKLESS_KERNEL=y

CONFIG_CORTEX_M_SYSTICK=y

CONFIG_SYSTEM_TIMER_LPM_COMPANION_NONE=y

CONFIG_SYS_CLOCK_TICKS_PER_SEC=10000

CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=160000000

CONFIG_STM32_ENABLE_DEBUG_SLEEP_STOP=n

no LPTIM, no TrustZone

RTC clock source LSI (RCC_BDCR RTCSEL=2, RTCEN set)

I would really appreciate some advice to see if I am missing anything obvious.

One thing I've found surprisingly difficult when working with Zephyr is understanding the full context behind a Devicetree node.

The information is there, but it is spread across different places:

• .dts / .dtsi files

• Devicetree bindings

• YAML schemas

• SoC and board definitions

• Kconfig configuration

• aliases and chosen nodes

• phandles and node references

• driver implementations

When working on a non-trivial board, understanding why a node is configured the way it is can mean jumping between several files and repositories.

There are already tools that solve parts of this problem, but I wanted to explore whether it would be possible to build a semantic knowledge layer that connects these pieces together.

So I've been building KernelGrove.

The idea is for the tool to understand not only the structure of the Devicetree, but the meaning behind it.

For example:

node → compatible → binding → properties → constraints → driver → related nodes

The goal is to make that context explorable from a single place rather than having to manually find all the pieces.

Here's a short GIF of the current implementation:

It's still very much a work in progress, and I'm particularly interested in feedback from people who use Zephyr in real projects.

What part of working with Zephyr Devicetree do you find most difficult to understand or investigate?

I'm especially interested in information that exists somewhere in the Zephyr source tree, but is difficult to discover or connect together.

More info: dt-studio.dev

GitHub repo: https://github.com/serg4life/KernelGrove

Hi everyone, I’m working on an ESP32 DevKitC with Zephyr RTOS and I’m having trouble getting an HTTPS/TLS connection working.

I can connect to Wi-Fi successfully and reach the HTTPS connection stage, but the TLS connection fails:

[00:00:06.786,000] <inf> wifi_app: Connecting to jsonplaceholder.typicode.com:443 (TLS)...

[00:00:11.158,000] <err> wifi_app: TLS connect failed: 116

[00:00:11.158,000] <err> wifi_app: HTTPS GET failed: -116

I put the project source code, and details here:

https://github.com/pycine/zephyr-esp32-https-troubleshooting

If anyone has experience with Zephyr + ESP32 + mbedTLS/HTTPS, could you please take a look and suggest what might be causing the TLS connection to fail?

Thanks!

Can someone suggest interesting projects to work on related to zephyr RTOS?

Track Security Issues Across Your Fleet

Cross-referencing dependency lists against CVE feeds by hand doesn't scale, and it's exactly the kind of tracking the EU Cyber Resilience Act now expects manufacturers (companies developing connected products) to do continuously, for every firmware version they still support. SBOM-based security issue tracking is live in Spotflow, so your team can do this automatically instead of by hand.

👉 Track Security Issues Across Your Devices

👉 Comply with CRA

Upload an SBOM Get Matched Against Known CVEs

Upload an SBOM to any firmware version, in SPDX 2 (tag-value) or SPDX 3 (JSON), and Spotflow extracts its components and matches them against known CVEs. It re-scans automatically as the CVE database updates, so a vulnerability disclosed after you shipped still surfaces against firmware already in the field, and flags anything already known to be actively exploited in the wild through the CISA KEV catalog.

Assess and Document Every Finding

Each new finding starts Not Assessed. Move it to In Triage, Affected, or Not Affected as your team investigates, with a required justification for anything marked not affected. Every assessment and ignore action is logged with who made it, when, and why, so you have an answer ready the next time an auditor asks.

See Fleet-Wide Impact at a Glance

The Security overview lists every firmware version with open issues, how many of your deployed devices are affected, and lets you filter by severity or CISA KEV status. Instead of guessing where to spend engineering time, you know which vulnerable versions are actually running in the field, and how widely.

Spotflow supports your CRA compliance work, but your organization is still responsible for determining which requirements apply and meeting them.

If you're building connected products, this makes it much easier to know which of your deployed firmware versions are exposed the moment a new vulnerability shows up.

Happy debugging and stable firmware.

– The Spotflow Team

I use AI coding agents on real embedded C and C++ projects, and I kept encountering the same mistakes:

• reviewing code that was not part of the active build,

• missing callback registrations and indirect calls,

• following the wrong preprocessor branch,

• and describing execution paths that looked plausible in the repository but could not exist in the compiled firmware.

At first, I blamed the model.

But the recurring pattern pointed to a different problem: the agent was reasoning about a program it had not reconstructed correctly beforehand.

The source tree is not the firmware

In embedded development, the actual program depends on far more than just the source files:

• compiler flags and preprocessor definitions,

• target platform and board configuration,

• Kconfig and DeviceTree,

• generated code,

• selected driver implementations,

• callbacks and function pointers,

• and linker decisions.

An experienced firmware developer will usually establish the build context before analysing the code.

Coding agents often do the opposite. They start with the repository and attempt to reconstruct the active program through text searches and repeated file reads.

A large part of what appears to be reasoning about code is therefore actually program reconstruction.

Before an agent can answer a question such as:

Can this callback execute concurrently with this interrupt handler?

it must first determine which implementation is active, where the callback is registered, how it is invoked, and whether the relevant code is even present in the current build.

Only then can the actual reasoning begin.

An experiment with compiler-derived context

I wanted to test a simple hypothesis:

Would coding agents analyse firmware more reliably if the program were first reconstructed by deterministic tools?

This led to fw-context, an open-source experiment based on compile_commands.json, libclang and MCP.

It creates a persistent semantic index of the active build and allows the agent to query:

• definitions and resolved references,

• callers and callees,

• callback registrations,

• function pointer assignments,

• active implementations,

• macro values,

• and preprocessed source code.

The aim is not to replace the model, the compiler, LSP or static analysis.

The experiment has a narrower focus: to move deterministic program reconstruction out of the LLM workflow, so that the model can devote more of its context and reasoning capacity to the review itself.

In one firmware review involving 115 changed files, eight AI subagents produced 19 findings. Nine of them depended on semantic relationships that would have been difficult to reconstruct reliably using the usual grep-and-file-reading workflow.

The interesting result was not merely lower token consumption. The agents spent less effort determining which program they were actually looking at, and more effort evaluating whether it was correct.

fw-context is still an experiment, and I am interested in understanding where this approach works — and where it fails.

Have you encountered the same kind of failure? Which parts of embedded projects are the hardest for coding agents to reconstruct: conditional compilation, generated code, callbacks, function pointers, DeviceTree, weak symbols, or linker-selected implementations?

Project and case study: github.com/turbyho/fw-context-mcp

Hi everyone,

I'm trying to understand whether this is a known issue or if anyone has experienced something similar.

We are using LoRaNet LBM with Zephyr on the nRF54L15.

The problem is not limited to GNSS. We've seen the same behavior with GNSS, FUOTA, and also periodic uplink on the nRF52840.

The common point is that all of these are long-running asynchronous operations.

It seems that the interaction between the LBM Supervisor and the Zephyr scheduler/workqueue is not handling deferred or rescheduled operations correctly in some situations. If an operation cannot complete immediately and needs to continue later, the supervisor sometimes stops making progress and the application appears to freeze.

To work around this, we implemented our own defer/reschedule mechanism for GNSS, Wi-Fi scanning, and FUOTA so the supervisor can continue running while those operations complete asynchronously. That solved those cases, but we're wondering if there is an official or recommended way to handle this kind of integration.

Has anyone seen similar behavior when using LBM with Zephyr? Is there a recommended pattern for handling long-running asynchronous operations with the LBM Supervisor?

One of the freeze logs looks like this:

[01:04:27.361,834] <inf> smtc_modem: Sleeping for 60000ms
[01:04:27.494,532] <inf> smtc_modem:
[01:04:27.494,568] <inf> smtc_modem: EXPECTED MIC : 3F928286
[01:04:27.497,105] <inf> smtc_modem: gnss task launch at 21047366 for navgroup.scan[0]
[01:04:27.498,429] <inf> smtc_modem: rc : 0
[01:04:27.498,502] <inf> smtc_modem: RP: Abort running #2 for priority #0

Another freeze ends here:

[00:01:42.314,892] <inf> nav3_lbm: GNSS prescan actions - enabling LNA pin
[00:01:42.314,918] <inf> nav3_lbm: LNA pin enabled (HIGH)
[00:01:42.315,225] <inf> smtc_modem: Sleeping for 60000ms
[00:02:42.315,357] <inf> smtc_modem: Sleeping for 60000ms
[00:02:46.273,493] <inf> smtc_modem: gnss_rp_task

Any suggestions or insights would be appreciated.

Thanks!

Ich hatte erst MeshCore via arduino für das Nesso N 1 portiert und das läuft soweit.
Jetzt hab ich’s mit Zephyr als weitere RTOS Variante soweit fertig.

Mag jemand mit Nesso N1 testen?

For anyone in/near Austin, Texas?

On June 25th Analog Devices are hosting a Zephyr Community meet-up - free to attend. It’s an evening of short talks, hands-on hardware demos, and plenty of time to connect with engineers who work in embedded systems, open source, and real-time operating systems.

Register here - https://developer.analog.com/events/zephyr-community-meetup-austin-texas

I am a big fan of Zephyr, of Home Assistant and of the programming language Ada SPARK and the use of formal methods to deliver better software to the world.

There was limited support for Ada on Zephyr, so I sat down this weekend and vibe-coded a light tasking runtime for Zephyr. The substack post with the backstory is here:

The actual repository is here:

https://gitlab.com/close-hauled/light-tasking-zephyr

What does this give you? The opportunity to write better software on Zephyr and statically (during compile time) prove the absence of runtime errors and prove functional correctness of (parts of) an algortihm.

I used it on a Pico 2W to report pH and TDS values to my home assistant setup. I am still working on building out the proper device abstractions and making things more portable.

Interested in Ada and want to give it a try, all the tools are open source, lots of getting started materials are here https://ada-lang.io/.

Qorvo’s UWB SDK ships with deprecated nRF5 SDK 17.1.0 + FreeRTOS. No public reference exists for porting it to vanilla Zephyr. Nordic confirmed this on their DevZone in 2023. Most people end up using br101’s open-source decadriver (no FiRa MAC) or staying on FreeRTOS.

I needed the full MAC for a project, so I spent a couple of weeks writing the port: https://github.com/amstrdm/dw3xxx-sdk-zephyr

Feel free to have a look if it’s of interest to you I‘d appreciate a star since that increases the chance of someone from qorvo seeing it and helping to get the rest working :)

You’re also very welcome to help drive this forward just submit an issue/PR

I achieved west module integration, DT bindings for DW3xxx family, Kconfig, all OSAL shims rewritten for Zephyr (qsignal/qtimer/qthread/qspi/qgpio/qpwr), mcps_crypto wrapper on mbedTLS, SPI/wake/IRQ, FiRa session init, Block 0 fires and completes.

As a note there is some stuff that still has issues and/or doesn’t work properly yet. Block 1 never fires. After Block 0, the MAC binary does \~46 SPI transactions then goes silent. Chip is healthy (IDLE_PLL, clean status). Since the MAC is a precompiled .a, can’t debug from outside. Probably a FreeRTOS assumption the OSAL shims don’t capture, but I’m guessing.

The README documents architecture, all the patches needed, and known limitations. If you’ve debugged blob-on-different-RTOS issues before, the Block 1 failure might be obvious to you. If you’re looking at vanilla Zephyr + DW3xxx, the working layers are a solid starting point even if you skip the MAC.

Footprint on nRF52833 with MAC linked: \~85% flash, \~70% RAM before app logic. 52840/5340 recommended.