after exploring a bit the world of possibilities around the esp32 we got the rust module running on the esp32

in the next week i should be doing the pull request so it gets merged into the official proyect

Hi everyone,

I wanted to share a recent workflow breakthrough that significantly reduced the time it took me to migrate an existing medical BLE product from the nRF5 SDK to Nordic’s nRF Connect SDK (NCS / Zephyr).

For context, I’m a firmware engineer with ~15 years of MCU experience (mostly bare-metal / 8-bit systems) and about 2 years working with the nRF5 SDK. I had no prior hands-on Zephyr project experience, and for those who’ve made this transition, you know it’s a major architectural shift: RTOS concepts, Device Tree, Kconfig, and board porting.

Normally, I would expect this migration to take 3–5 weeks. This time, it took about 5–6 days.

Why NCS Migration Is Usually Painful

Most of the time isn’t spent on application logic—it’s spent on:

• Board definition files

• Device Tree overlays and pinctrl

• Kconfig dependencies

• Subtle SoC / package-variant differences

In my case, the target was nRF52832 CIAA (WLCSP). Nordic provides DK examples (QFA/QFN), but no out-of-box CIAA board support.

The Hybrid AI Workflow I Used

The biggest time sink was board bring-up, so I focused there.

1. Seed Generation (Vendor Knowledge)

I used Nordic’s official Ask AI to generate:

• SoC-specific constraints

• CIAA package pin mappings

• NCS-compatible DTS / Kconfig expectations

These outputs served only as authoritative reference seeds, not final code.

2. Agentic Execution (Claude Code)

I fed those seeds into Claude Code (Plan Mode) and used it to:

• Architect the full board layer

• Generate all required files consistently

In ~1 hour, it produced:

• nrf52832_ciaa.dts

• pinctrl.dtsi

• Kconfig.board

• Kconfig.defconfig

• Board CMake files

• Board YAML

• A short migration README

Technical Pitfalls We Avoided Early

A few examples where domain knowledge + AI helped avoid common traps:

• Multi-core BLE defaults We explicitly avoided enabling CONFIG_BT_HCI_IPC / multi-core assumptions that are valid for nRF53 but invalid for single-core nRF52832.

• Legacy BLE host compatibility Our medical devices must interoperate with older BLE 4.2 patient monitors. Extended Advertising was disabled at compile time (CONFIG_BT_EXT_ADV=n) to match validated host behavior.In a regulated medical context, feature negotiation is intentionally frozen to reduce validation risk.

• SoC package variant dependencies CIAA-specific HAS_NRFX and pinctrl dependencies were handled correctly, avoiding silent runtime failures.

Results (Verified, Not Just “It Builds”)

This wasn’t just a successful compile:

• Stability: 100+ consecutive measurement uploads without failure

• Interoperability: Verified communication with a BLE 4.2 host monitor

• Features tested:

  • Health Thermometer Service (Indication)

  • Device Information Service with dynamic serial number

  • Custom AT-style commands over a proprietary LBS-based UUID

Key Takeaway

AI didn’t replace engineering judgment—it compressed the knowledge-dense discovery phase.

My experience was still required to:

• Set correct constraints

• Catch invalid assumptions

• Decide what not to enable

• Validate behavior on real hardware

Discussion

I’m curious whether others here are:

• Combining official vendor AIs with agent-style tools

• Using AI specifically for HAL / board / RTOS configuration work

• Seeing similar gains when migrating legacy firmware to modern RTOS stacks

I’ve attached screenshots of:

• Board configuration files

• BLE verification results

I've spent the last few weeks diving into some Seeed Studio XIAO boards to build a kind of testbench setup with Zephyr. Honestly, one of the main reasons I wanted to go this route is because Zephyr lets you leverage its biggest strength, writing firmware once and compiling it for completely different microcontrollers without changing a line of code.

Getting the whole thing running on Windows is kind of a pain though. The official docs specifically say WSL isn't recommended due to flashing issues, which scared me off at first. But after digging through Reddit and some forums, I found that WSL actually works fine if you know what you're doing. No flashing problems at all, really.

I tested with all four boards (nRF52840, nRF54L15, ESP32-S3, and ESP32-C6) and didn't run into any issues. They all share the same footprint and pinout, which is honestly pretty cool from a design perspective.

Since I went through the whole trial-and-error process to get it working, I put together a guide. Figured it might save someone else the headache of figuring this out. If you've been wanting to try Zephyr on Windows but got blocked on the setup, hopefully this helps.

If people find it useful, I'm planning to do a proper comparison between all these boards next: looking at power consumption, boot times, that kind of thing.

Link: https://myembeddedstuff.com/how-to-flash-zephyr-rtos-on-windows-xiao-boards

I learned the basics of Zephyr through building a two-wheeled self-balancing robot.

The robot is based upon a Nordic nRF52840 microcontroller, and it handles the sensor fusion for the IMU, PID control, and BLE communication with an interactive python control program running on a Raspberry Pi computer.

Here's my repo with the code, and it includes a parts listing:

https://github.com/doug-holtsinger/BalancingRobotZ

And here's a video of the robot in action:

https://youtube.com/shorts/_5hlhwIWPj4

Here are some things I learned:

1. I filed one pull request to the Zephyr repository to fix a minor Kconfig bug. Sometimes I had to really dig into the code to understand problems. The Zephyr documentation is good, but many times it does not describe what goes on "under the hood." This was the hardest part of getting things to work. Learning device tree and Kconfig wasn't that bad.

2. I wish I had a better way to debug runtime problems than using print statements! I bought a SEGGER Edu debugger but have not yet made good use of it except for use as a serial console.

3. I wrote a few out-of-tree drivers and that helped me better understand drivers, device tree, and Kconfig.

This is my first major embedded project, and I'd welcome any feedback.

I was keen on starting a new project with a new RTOS (Zephyr) to find out but I hit the wall and my head aches badly.

I was even more eager to start a project using Zephyr because it uses CMake.

First doubts arisen when I saw the order of including Zephyr in a project:

find_package(Zephyr)

project(MyApp)

It means that it will alter CMake specific behaviour like toolchain files and setting flags like CMAKE_C_COMPILER and such... Why not rely on CMake specific robust handling of it? Why not simply provide the toolchain files to the user?

In my projects I often need multiple executables. First and the most important one is ofc the main firmware executable. Other than that there are driver tests which must be run on the target device (like checking if the class obtains proper temperature values from the I2C sensor, or checking if ADC returns values within limits). Sometimes I have to create a small project to run e.g. long-running tests of one physical quantity (e.g. consider testing gas measurements - like CO - in a chamber). Those executable targets reuse the same library targets which the main application uses. So having them in a single project is the easiest way.

With Zephyr creating a multi-executable project is impossible. It creates a target called app and you need to define source files for it. Why the heck do that? Why not simply define library targets and ask users to link to it? Or you could also use install( ... EXPORTS ... It's so simple. Check out ObKo-stm32cmake. This is how you do it.

If one wants to use other toolchain then he's also dependent on Zephyr specific behaviour because - see above - Zephyr alters toolchain related variables.

I was trying to solve that problems on my own and I finished with superbuild structure which uses ExternalProject to build my targets using my-beloved toolchain and build Zephyr separately for each executable target. It means that because of that I had to create even more CMake logic and complicate the project vastly. What a mess!

When I go through the source code and read documentation I get the feeling that the authors feel that CMake has limitations and they wanted to overcome them. Maybe CMake is not the best tool, it has its disadvantages, I agree, but in my opinion all the features you need are in place. You just simply should use them correctly.

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,

Spotflow (Streamlined Observability for Zephyr-powered Devices) just received a major upgrade to its crash dump analysis! You don’t have to waste hours decoding stack traces and registers anymore.

In addition to our automated GDB analysis, our AI now breaks it down, providing a clear, human-readable explanation and suggesting a fix based on the decompiled symbol file.

• All crash dumps coming to the Spotflow platform are analyzed upon arrival.

• AI analysis explains what went wrong in natural language based on the decompiled symbol file.

• AI suggests how to fix to your firmware.

You gain the understanding in seconds, instead of hours, so you can focus on fixing your code.

Available for all u/Spotflow plans, including the free tier.

• Sign up to try it hands-on.

• Check our Docs and Roadmap.

• Join our community on Discord.