DEV Community: Errata Hunter

Embedded Firmware Development with Claude Code — Devicetree, Kconfig, and Debugging

Errata Hunter — Wed, 25 Mar 2026 21:34:06 +0000

TL;DR

75% of Zephyr firmware development time goes to Kconfig/devicetree configuration and build error interpretation, not writing code — Claude Code can intervene in that 75% directly from the terminal.

Kconfig hallucination (AI inventing nonexistent symbols) is structurally preventable by combining a shell script that greps build/zephyr/.config and Kconfig source files with Claude Code's skill and hook system.

Feeding all three files (.dts, .dtsi, binding YAML) as context via the @ syntax prevents compatible string hallucination in devicetree overlays.

AI coding tools still feel distant for embedded firmware developers. "Can AI even understand devicetree?" "What if it invents Kconfig symbols?" — reasonable doubts. I had them too.

I deployed Claude Code on production Zephyr/NCS firmware projects at my day job. Kconfig hallucination broke builds. I built safeguards using Claude Code's skill and hook system to fix it. This post covers the methodology I developed. I can't share proprietary code, but I can explain where things break when you hand devicetree and Kconfig to AI, and how to structurally prevent it.

Why I Left the GUI IDE for the Terminal

A typical day for a Zephyr firmware developer breaks down like this:

Run west build → interpret CMake/Kconfig/devicetree errors
Edit prj.conf → dig through menuconfig to find the right CONFIG_* symbols
Write devicetree overlays → cross-reference .dts, .dtsi, and binding YAML simultaneously
Flash and check serial logs → track down bugs

Actual C code writing accounts for roughly 25% of the day. The remaining 75% is spent fighting configuration files and error logs.

GUI IDE AI features focus on code autocompletion — predicting function signatures, suggesting next lines. They help with the 25%. Claude Code runs in the terminal, so it can execute west build directly, read the entire build log, interpret errors, and suggest next actions. It greps .config files and traces Kconfig dependencies back to source. It can intervene in the other 75% — and that's why a terminal-based AI agent has an edge in embedded.

Dedicated embedded AI tools are emerging. Embedder (YC S25) generates driver code from uploaded PDF datasheets and is preparing serial console and GDB integration. If you work within supported chipsets (STM32, ESP32) using standard workflows, these packaged tools deliver real productivity gains.

I chose Claude Code instead. The reason comes down to what software engineering calls the double-edged sword of opinionated design. Packaged tools are productive within the Golden Path their creators designed, but friction increases the moment you step outside it. When the tool's assumed build pipeline doesn't match your project structure, you end up contorting your workflow to fit the tool. When the tool's baked-in "best practices" conflict with your hardware's nonstandard constraints, AI suggestions derail rather than help. Embedded development — where hardware configuration, SDK structure, and build pipelines vary project to project — makes this especially pronounced.

It's a tradeoff between convenience and control. I deal with Zephyr/NCS west workspace structures and per-project build configurations, so I chose to tune a general-purpose tool to fit my pipeline directly.

Devicetree: Teaching Hardware to AI

Zephyr's devicetree system has three layers. SoC .dtsi files define base hardware. Board .dts files declare pin mappings. Binding YAML files specify valid properties for each node. Developers must cross-reference all three layers when writing overlays.

To get accurate overlays from AI, you need to feed all three files as context

No Context Means Hallucination

Tell Claude Code "add SPI flash to this board" without context and you'll get a plausible but wrong overlay. The compatible string won't match any actual binding, or it'll reference a nonexistent node label.

For accurate results, feed all three files explicitly:

"Read @boards/arm/nrf52840dk_nrf52840.dts and
@zephyr/dts/arm/nordic/nrf52840.dtsi, then reference
@zephyr/dts/bindings/spi/spi-device.yaml to write
an overlay adding W25Q128 flash to SPI1."

With the @ syntax pointing to specific files, Claude Code correctly references existing SPI node labels from the board and doesn't miss required properties (reg, spi-max-frequency) defined in the binding YAML.

Three Patterns Where AI Gets Devicetree Wrong

compatible string hallucination — invents a compatible that doesn't exist in any binding. Feeding the binding YAML as context prevents this.
Node address collision — @0 must match reg = <0>, but AI assigns addresses that duplicate existing nodes. Feeding the board .dts lets it check existing assignments.
Ignoring overlay detection rules — Zephyr's build system auto-detects overlays in this order when DTC_OVERLAY_FILE is unset: socs/<SOC>.overlay → boards/<BOARD>.overlay → <BOARD>.overlay → app.overlay. If AI creates an overlay with an arbitrary filename, the build system ignores it.

The third problem is solved by adding one line to CLAUDE.md:

## Devicetree
- Overlay files must be named `app.overlay` or `boards/<BOARD>.overlay`

AI's role in devicetree work isn't "writing overlays for you." It's reducing the overhead of cross-referencing three files — checking available nodes in .dtsi, pulling required properties from binding YAML, and combining settings that don't conflict with existing .dts. The question is whether you do this manually by switching between three files, or hand all three to AI and get it in one pass.

Kconfig: Building a Skill to Prevent AI Hallucination

Zephyr's Kconfig system has thousands of symbols in a tree structure. Enabling CONFIG_BT auto-activates NET_BUF. Choosing CONFIG_BT_HCI under BT_STACK_SELECTION triggers another dependency chain. Symbols forced on by select, conditionally enabled by depends on, and suggested by imply are intertwined. The Zephyr project itself acknowledges excessive select usage and is migrating to depends on — that's how complex the dependency structure is.

Ask AI to "create a minimal prj.conf for BLE Central scan only" and you get a plausible result. But it might invent nonexistent symbols or miss required dependencies.

When I hit this problem at work, I solved it by making incremental requests to Claude Code. I didn't start with "build me a Kconfig hallucination prevention skill." I asked questions one at a time, and automation emerged naturally.

The Conversation Flow

"Where does the final Kconfig output go after west build?"

build/zephyr/.config contains the fully resolved symbol list — thousands of CONFIG_*=y/n lines. You can also check via menuconfig/guiconfig, but this file is the ground truth the build system actually uses.

"Find the .config file in this project's build output."

Claude Code locates build/zephyr/.config and shows its contents. A follow-up question:

"Does this project have a separate kernel source? Is there a separate kernel .config like in Linux?"

Unlike the Linux kernel, Zephyr builds the app and RTOS kernel into a single binary. build/zephyr/.config is the entire system's configuration. There's no separate kernel .config.

"Find all the Kconfig source files in the west workspace."

zephyr/Kconfig, zephyr/subsys/bluetooth/Kconfig, Kconfig files in each driver directory — organized into a tree. These source files contain each symbol's depends on, select, and help text. If AI references these when modifying prj.conf, it can't fabricate nonexistent symbols.

Here's where a problem arises. The .config file is thousands of lines. Kconfig source files are scattered across the entire west workspace. Reading everything every time wastes tokens.

"I want to reference these files when modifying .conf, but minimize token usage. How can I query only the relevant symbols?"

Claude Code proposes a shell script + skill combination. A script that greps for relevant symbols, called by a skill.

"Build that skill."

A Kconfig reference skill appears under .claude/skills/. When a .conf modification is requested:

Grep the built .config for the current state of relevant symbols
Extract the depends on, select, help text from Kconfig source
Use this as context when modifying .conf

Instead of reading thousands of lines, it extracts only the needed symbols and their dependencies.

"I want this skill to trigger only when modifying .conf files. Check what needs to change in .claude/."

Claude Code's hook system handles this. Set PostToolUse with matcher: "Write|Edit" in .claude/settings.json, extract the file path from stdin JSON, and conditionally trigger only for .conf files:

FILE_PATH=$(jq -r '.tool_input.file_path' < /dev/stdin)
if [[ ! "$FILE_PATH" =~ \.conf$ ]]; then
  exit 0  # ignore non-.conf files
fi
## Run Kconfig reference logic

CLAUDE.md instructions are advisory — AI can ignore them. Hooks are deterministic. They execute without exception. Making Kconfig source reference automatic on every .conf edit structurally prevents AI from inventing nonexistent symbols.

What This Flow Reveals

Six conversations produced a hallucination prevention skill. Asking "build me a Kconfig hallucination prevention skill" upfront wouldn't have worked — you can't design the solution without knowing .config exists.

The pattern here is discovering AI's limitation, then using the same AI to build a tool that fills the gap. Don't try to turn Claude Code into an embedded engineer. Instead, as the engineer, identify AI's weak spots and co-build compensating tools. That approach works.

Build Error Debugging — Where AI Delivers the Highest ROI

When west build fails, the terminal floods with errors from CMake, Kconfig, devicetree, the C compiler, and the linker all mixed together. Even experienced engineers spend time just figuring out whether an error is a devicetree problem or a Kconfig problem.

Feed the entire build log to Claude Code and it classifies errors by category, then traces root causes. Embedded build errors fall into three categories, each with different AI utility.

Devicetree Binding Mismatch

When a compatible string doesn't match any binding YAML, the build system throws an error. The error message is clear enough to solve without AI, but Claude Code finds the correct binding YAML across hundreds of directories under zephyr/dts/bindings/ and proposes a fix in one step. Manually searching takes time.

Kconfig Dependency Failure — "Silent Failure"

This one is trickier. Set CONFIG_X=y in prj.conf, but if CONFIG_X has depends on CONFIG_Y and CONFIG_Y=n, the Kconfig system silently ignores CONFIG_X. The build succeeds, but the intended feature doesn't work.

Have Claude Code compare prj.conf against build/zephyr/.config and it finds symbols present in prj.conf but missing from .config. Tracing the unmet dependency requires Kconfig source — and the Kconfig reference skill from earlier connects here too.

Linker Errors

Embedded linker errors are typically RAM/Flash overflow or duplicate symbol definitions. Claude Code reads the linker script (.ld) and build.map to identify which object files conflict. For memory overflow, it extracts each section's size from build.map and suggests reduction priorities.

Build error debugging is where Claude Code's ROI is highest. Error messages are text, root-cause tracing requires cross-referencing multiple files, and resolution patterns are relatively well-defined.

Runtime Debugging: Log Analysis and GDB

After a successful build and flash, a different kind of debugging begins.

Serial Log Pattern Analysis

Capture printk or Zephyr LOG_MODULE output over serial and feed it to Claude Code. It identifies timestamp intervals, repeating error code patterns, and state changes preceding specific events. Faster than scrolling through hundreds of lines manually.

Automating the copy-paste step is possible too. serial-mcp-server is a Rust-based MCP server that exposes UART communication as Claude Code tools — list_ports, open, read, write, close. It supports STM32, ESP32, and USB-serial converters like CH340 and FTDI. With MCP configured, you can say "open the serial port and read the log" mid-conversation.

HardFault Analysis

When a HardFault occurs during J-Link + GDB debugging, feed the call stack and register dump to Claude Code. It interprets Cortex-M CFSR (Configurable Fault Status Register) bits and traces the faulting function to build a cause hypothesis.

Stack overflows, null pointer dereferences, and unaligned memory access — common patterns — are caught accurately. Nondeterministic bugs like timing issues between DMA completion interrupts and the main loop are harder, since logs alone can't reproduce them. AI help has limits there.

Limitations and Workarounds

Areas where Claude Code struggles in embedded:

Binary protocol parsing — for byte-packed data like BLE custom profiles or proprietary sensor protocols, AI makes frequent errors in bit shifting and endianness handling. Packed struct field offset calculations vary by compiler and target architecture, and AI overlooks these differences.

Timing-critical interrupt logic — when ISR execution time is constrained to microseconds, AI generates functionally correct code but doesn't optimize for execution time. volatile access ordering, cache line alignment, and compiler barrier insertion remain the engineer's domain.

Hardware register maps — don't expect AI to know your SoC's register map accurately. It gets the general structure right, but hallucinates on specific bit reset values and reserved bit handling.

Mitigation Strategies

Keep hardware specs in CLAUDE.md, but keep it short. Claude Code's official best practices call this "Progressive Disclosure" — don't dump all information, tell AI how to find it. Instead of pasting the entire register map, write "refer to nrf52840.svd for nRF52840 register details." Long CLAUDE.md files cause AI to ignore instructions.

## Hardware
- SoC: [nRF52840](https://www.nordicsemi.com/Products/nRF52840) (Cortex-M4F, 256KB RAM, 1MB Flash)
- Board: nRF52840-DK (PCA10056)
- NCS SDK: v2.9.0
- Register reference: nrf52840.svd

Always provide verification. Have AI write code, then run west build and check the result — it catches its own mistakes. According to Claude Code's official docs, "run tests after every change — this alone increases output quality 2–3x." Unit testing is often impractical in embedded, but west build pass/fail serves as a first-order verification.

Claude Code Configuration Strategy for Embedded Projects

Effective Claude Code configuration for embedded requires separating the roles of CLAUDE.md, skills, and hooks.

Component

Purpose

Execution

CLAUDE.md

Per-session context (board, SDK, build commands)

Auto-loaded (advisory)

Skills

Domain knowledge, workflows (Kconfig reference, etc.)

On-demand

Hooks

Non-negotiable rules (.conf validation, etc.)

Auto-executed (deterministic)

CLAUDE.md: Minimal Context Only

CLAUDE.md loads every session. Exclude what AI can infer from code; include only what it can't. Board pin maps, SoC specs, NCS SDK version, and build commands are typical entries.

## Build


west build -b nrf52840dk/nrf52840 -- -DOVERLAY_CONFIG=overlay-debug.conf
west flash --runner jlink


  
  
  Conventions



Overlay filenames: app.overlay or boards/<BOARD>.overlay
Kconfig: prj.conf (shared), boards/<BOARD>.conf (board-specific)
After .conf edits, verify against build/zephyr/.config

Skills: Isolate Domain Knowledge

Knowledge needed only in specific workflows — like the Kconfig reference skill — belongs in .claude/skills/. Putting everything in CLAUDE.md wastes the context window, and as it grows longer, AI starts ignoring instructions.

Hooks: Advisory vs. Deterministic

Writing "always reference .config when editing .conf" in CLAUDE.md doesn't guarantee compliance — AI can skip it. If a rule must execute without exception, implement it as a hook. Hooks run shell scripts before or after Claude Code's tool usage, independent of AI judgment.

Build-Debug Cycle

When these components combine, the embedded build-debug cycle looks like this:

Three feedback loops converge on a single edit point — Claude Code intervenes at the red and navy nodes

Hooks auto-validate Kconfig on .conf edits. AI classifies and traces build errors. AI analyzes serial log patterns. The 75% outside of code writing — that's where AI intervenes.

Wrapping Up

Applying AI to embedded development isn't about how well AI writes code. It's about reducing friction in the other 75% — build configuration, error interpretation, log analysis.

Claude Code can intervene in that 75%. But embedded's domain specifics (Kconfig hallucination, inaccurate hardware register maps) mean you can't use it out of the box. You need skills and hooks as compensating mechanisms. After building and deploying these at my day job, the loop of using AI to compensate for AI's own limitations works.

I wrote this post methodology-first because I can't share proprietary code. When I start a personal side project, I plan to apply the same approach and share devicetree overlay sessions, the Kconfig skill in action, and build error debugging logs — with actual code.

NCS Project Management Guide: Ditching Global Install to Reclaim Control

Errata Hunter — Sun, 15 Mar 2026 21:37:25 +0000

TL;DR

Patching SDK internals in an NCS global install silently breaks every other project on your machine.

Freestanding (manual ZEPHYR_BASE binding) → T2 (app owns west.yml manifest) → T3 (separate manifest repo managing multiple apps and SDK) gives you progressive isolation.

Start with Freestanding. Move to T2 or T3 only when reproducibility or multi-product needs demand it.

When you first pick up the nRF Connect SDK (NCS), the natural move is to follow Nordic's Toolchain Manager or VS Code Extension wizard. When I set up my Zephyr dev environment with Antigravity IDE, I did exactly that. A few button clicks and the Zephyr RTOS core, libraries, and compiler land neatly under C:\ncs\toolchains or a v2.x.x folder.

The problem: this convenient global install becomes an unmanageable swamp as projects multiply.

Zephyr's ecosystem is well designed. Need to remap board pins? Use an app.overlay (Devicetree Overlay). Want to tweak system configuration? Edit prj.conf (Kconfig) and override without touching the original source.

But production firmware development never follows the textbook. Sometimes you have to reach deep into the HAL (Hardware Abstraction Layer) to dodge a chipset errata. Sometimes the only way forward is a monkey patch inside Nordic's nrfxlib.

In a global install, that single hack silently breaks every other NCS project on your machine. On top of that, every new SDK release meant downloading gigabytes onto the main drive all over again.

Under the banner of convenience, I had lost control of my build environment.

Deep Dive: True Isolation and the Essence of Freestanding

Breaking this cycle required flipping the NCS paradigm. Instead of "the Toolchain Manager owns my SDK," the goal was "my code picks and isolates its own SDK."

The first concept I ran into was the Freestanding Application.

In the Zephyr ecosystem, a manifest (west.yml) is a dependency recipe file that declares "this project needs Zephyr version X, nRF module version Y." Think of it as the equivalent of Node.js's package.json or Python's requirements.txt. One west update command pulls every source at the exact pinned version.

Freestanding skips the manifest and any complex topology. It is the most intuitive way to isolate an SDK on a local dev machine. My app lives at D:\Workspace\my_app\, the SDK sits in a completely separate location, and I bind ZEPHYR_BASE via an environment variable only in the terminal session where I build.

This is like mounting just the volumes you need into a Docker container — clean and minimal. It is the lightest starting point for physically separating your project from the SDK.

But as projects grow, Freestanding hits its limits. That is where Zephyr's official West Workspace Topology comes in. Zephyr defines three topologies based on who owns the manifest repository:

T1 (Zephyr-centric Star): Zephyr itself is the manifest. This is what you get from a default west init.
T2 (App-centric Star): Your app is the manifest. The cleanest layout for a single product.
T3 (Forest): A dedicated manifest repo manages multiple apps and the SDK as siblings. Built for multi-product teams.

This post walks through the progression from Freestanding to T2, then T3.

Step-by-step progression from global install to Freestanding, T2, and T3

Implementation: Building a Controlled Environment from Scratch

Here is the step-by-step journey from the simplest Freestanding setup, through T2, to T3 Topology.

Step 1: Pure Freestanding — The Lightest Isolation

First, I stepped out of the Toolchain Manager's shadow and installed the toolchain and West (Zephyr's meta-tool) directly inside a Python virtual environment (venv).

Open a terminal at the app directory and manually bind the SDK dependency. On Windows, a single script call does it:

:: Temporarily bind the system NCS (Zephyr) directory to this session only
> C:\ncs\v2.x.x\zephyr\zephyr-env.cmd

:: Now the build command targets the SDK on the C drive
> west build -b nrf52840dk_nrf52840

For a quick library test or a lightweight side project, this is enough. The binding lives only inside the virtual environment and leaves everything else untouched.

Step 2: T2 Topology — Let the App Own Its Dependencies

Freestanding relies on your memory or documentation to track the SDK version. Once you start building a real product, that weakness shows. A teammate should be able to git clone and reproduce the exact build environment — telling them over Slack which ZEPHYR_BASE to set is an accident waiting to happen.

T2 is what Zephyr's official docs call the Star topology (application is the manifest repository). You place a west.yml manifest directly inside your app repo, making the app itself the owner of its SDK dependencies.

my_product/              # App repo IS the manifest repo (T2)
├── .west/               # Auto-generated by west init
├── app/                 # Application source
│   ├── CMakeLists.txt
│   ├── prj.conf
│   └── src/main.c
├── west.yml             # ★ Pins Zephyr, NRF, and module versions
├── zephyr/              # Pulled by west update
└── modules/             # nrf, hal_nordic, nrfxlib, etc.

Pin a specific Zephyr tag or commit hash in west.yml, and anyone who runs west init -l . && west update anywhere gets the exact same SDK version. The reproducibility that Freestanding lacked is now baked in.

Zephyr's Manifest Imports feature simplifies west.yml authoring considerably. Instead of listing dozens of module versions by hand, you import the Zephyr manifest wholesale and only override what you need.

The caveat: T2 assumes one app = one manifest. For a single product it is hard to beat, but the moment you need to develop Product A and Product B on the same hardware platform, the model starts cracking.

Step 3: T3 Topology — Forest Structure for Multiple Apps

The moment arrived when I had to develop "Terminal A" and "Terminal B" on the same platform hardware simultaneously. Creating separate T2 workspaces for each meant duplicating multi-gigabyte SDK folders per product.

The answer was T3 Topology. Zephyr's docs call it the Forest topology — a dedicated manifest repository arranges multiple apps and the SDK as siblings at the same directory level.

my_workspace/            # Workspace root (T3 anchor)
├── .west/               # West metadata
├── manifest_repo/       # Single repo holding west.yml (dependency hub)
├── app_product_a/       # Application 1
├── app_product_b/       # Application 2
├── zephyr/              # Zephyr core pulled by West
└── modules/             # nrf, hal, nrfxlib, etc.

The decisive difference from T2: the manifest lives outside any app. A single manifest_repo/west.yml governs the Zephyr version, module versions, and even the Git revisions of every app. app_product_a and app_product_b remain fully decoupled, yet at build time they safely share the same verified SDK within my_workspace.

T3 also pays off when setting up CI/CD pipelines (e.g., GitHub Actions). The CI server clones manifest_repo, runs west update, and every app plus its dependencies land at the correct version in one shot.

Troubleshooting: The Curse of Windows Long Paths (260-char Limit)

The moment I moved to a West Workspace structure (T2 or T3) and wired up CI, builds started failing:

"No such file or directory"

NCS and Zephyr have deeply nested directory hierarchies. When CMake and Ninja generate build artifacts on top of that, the path easily blows past the Windows MAX_PATH limit of 260 characters. Unless you are using third-party tools that handle long paths natively, you will hit this.

If you are building this structure on Windows, open an admin PowerShell and run this before anything else:

# Disable the Windows 10/11 long path restriction (reboot recommended after)
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" -Name "LongPathsEnabled" -Value 1 -PropertyType DWORD -Force

I missed this one setting and spent half a day chasing phantom CMakeLists.txt errors.

Key differences between the three topology options at a glance

Takeaway: Which Structure Should You Pick?

After ditching the Toolchain Manager's global install, we gained three weapons for NCS project management.

There is no silver bullet. Each structure carries clear trade-offs, and the right choice depends on your project's expected lifetime and team size.

	Freestanding	T2 (Star)	T3 (Forest)
Manifest	None	App = Manifest	Separate manifest repo
App count	1	1	Multiple
SDK version pinning	Manual (`ZEPHYR_BASE`)	Pinned via `west.yml`	Pinned via `west.yml`
Reproducibility	Low	High	High
Initial setup cost	Near zero	Medium	High
Storage	Minimal	One SDK copy per app	One shared SDK copy

1. Freestanding — When You Need Isolation Right Now

Best for: One-off side projects, quick sensor driver tests you plan to throw away, getting a build environment running in under 5 minutes on a personal machine.
Downside: west does not manage versions for you. You have to remember or document which SDK version you depended on, and manually bind the environment variable every time. Three months later — or when handing the project to a teammate — reproduction may fail.

2. T2 (Star) — When You Are Building a Real Product

Best for: Serious single-product development where anyone should be able to git clone and reproduce the exact build environment. A solo developer or small team focused on one firmware project.
Downside: The entire SDK lives inside the app workspace, so adding a second product means duplicating the same Zephyr/NRF sources. Storage and west update time scale linearly with product count.

3. T3 (Forest) — When the Team Manages Multiple Products

Best for: Company-scale development with multiple products (A, B, C...) on the same hardware platform sharing common core logic. CI/CD pipeline integration is a must at this stage.
Downside: Significant learning curve for the initial manifest_repo/west.yml setup and directory structure conventions. A manifest maintainer must mediate version conflicts across products.

My own path: I started with Freestanding for rapid prototyping, moved to T2 once the product was greenlit, and switched to T3 when derivative products appeared on the same platform. You do not need to start at T3. Binding the SDK with a single zephyr-env.cmd call via Freestanding is enough. That alone is the first step toward reclaiming control in the closed NCS ecosystem.

Zephyr CMake Hell is Dead: Why I Let Google Antigravity Write My Firmware

Errata Hunter — Wed, 11 Mar 2026 21:41:32 +0000

I just burned another weekend chasing a ghost I2C timeout that wasn't even in the datasheet. Decided it was time to ditch the proprietary vendor lock-in and migrate to the modern Zephyr RTOS. My reward? Welcome to west and CMakeLists.txt hell.

A high-level representation of Zephyr's build pipeline complexity. Before the HN pedants start arguing about exact CMake module dependencies in the comments—yes, this is simplified. The point is that you shouldn't need a PhD in build systems just to toggle a GPIO.

Bare-metal firmware debugging is painful enough on its own. We shouldn't have to bleed over build system setups too. Web devs have AI agents scaffolding their entire async microservice architectures while we’re still grepping through 2010-era PDFs just to figure out a device tree path.

Why I Brought Antigravity into the Embedded World

I got sick of it. I decided to throw Google's new agent-centric IDE, Antigravity, at my firmware problems.

The software world is moving at warp speed with AI, while the embedded industry remains a walled garden of bloated IDEs and slow iteration. We need to adapt. By offloading the massive barrier to entry—Kconfig labyrinths, linker scripts, and toolchain paths—to an AI agent, we can actually focus on what matters: the core logic and hardware interactions. I’m documenting this because we need to lower the barrier to entry in bare-metal engineering. Stop fighting the build system. Get your ideas out there.

Arming Antigravity: Mandatory & Recommended Extensions

It’s not some bloated enterprise tool. Setup is dead simple.

Download the OS-specific build from [antigravity.google](https://antigravity.google/download).
It’s a VS Code fork under the hood, so your muscle memory for shortcuts and UI remains intact.

But since we are forcing an AI agent to write firmware, we have to arm it with traditional weapons for hardware debugging. Go to the Extensions tab and install these:

1. Mandatory Extensions (The Core) The nRF Extensions Quirk: In standard VS Code, you'd just lazy-install the nRF Connect for VS Code Extension Pack and call it a day. However, Antigravity’s extension search currently doesn't index the consolidated pack. Don't panic. You just have to manually search and install its four horsemen individually:

nRF Connect for VS Code: The absolute backbone for SDK, toolchain management, building, and debugging.
nRF DeviceTree: Visualizes and edits the nightmare that is device tree structures.
nRF Kconfig: GUI editor for project settings so you don't go blind reading Kconfig files.
nRF Terminal: Serial and RTT logging terminal.

2. Recommended Auxiliary Extensions To actually read the code the agent spits out and survive debugging, you should install these for development efficiency:

Cortex-Debug (marus25.cortex-debug): Provides ARM Cortex-M debugging capabilities. Do not skip this. You can't debug bare-metal if you can't dump your hardware registers.
C/C++ (Microsoft): Essential for code compilation, IntelliSense (autocomplete), and debugging support.
CMake Tools (Microsoft): Manages the CMake build system, which is the beating heart of Zephyr.

The Antigravity Workflow: Navigating the nRF Connect Sidebar

Once you have the extensions installed, you'll see the Nordic icon pop up on your left activity bar. Open it up, and you get three beautiful panels:

Welcome: This is your entry point. You use this panel to manage your SDK versions, set up toolchains, and create new projects from templates.
Application: This shows the structure of your loaded Zephyr projects. It’s where you manage not just your source code, but also keep an eye on your device tree overlays and Kconfig (prj.conf) files.
Build: The holy grail. You don't have to constantly wrestle with west build commands in the terminal anymore. Once your board target is set, you just hit the "Build" and "Flash" buttons right here. Need to open the Kconfig GUI or start a Debug session? One click. It’s a completely frictionless workflow.

What’s Next: NCS and Project Architecture

The toolchain is ready, and the workflow is set. But before we unleash the AI to actually write our firmware, there’s a multi-gigabyte elephant in the room: installing the Nordic Connect SDK (NCS) and structuring your repository.

If you dump your code inside the vendor SDK folder ("In-tree") like beginner tutorials suggest, your Git history will become a dumpster fire.

In Part 2, I’ll walk you through taming the massive NCS installation without breaking your python paths. More importantly, we’ll deep-dive into the architectural holy war of Zephyr project management: Freestanding Applications vs. T2 Topology (Workspace). I’ll break down their pros, cons, exact use cases, and how to set them up so you don't hate yourself later. Stay tuned.