How RespCode Compiles Real Bare-Metal Firmware with AI

Hardware Viable: AI-Generated Firmware Running on Real Silicon

Gemini 2.5 Pro's AI-generated firmware running on a physical NXP LPC55S69-EVK board. Human prompt → AI generates code → SVD validation → ARM cross-compilation → flash → real LED blinking. No SDK, no HAL, no human edits. Pure AI-generated bare-metal firmware on real silicon.

Ask any AI to write bare-metal firmware for a microcontroller. You'll get code back. It might even compile. But will it actually work on the physical chip? We built a pipeline that answers that question — and the results are brutal. Of 4 flagship AI models, only one produced firmware with correct register addresses. The others write to unmapped memory and silently fail.

RespCode doesn't just generate embedded firmware — we compile it with real cross-compilers, validate it against official ARM CMSIS hardware specifications, and auto-correct wrong peripheral addresses using SVD register data from 2,690 MCUs. For this post, we went further — disassembling the compiled binaries instruction by instruction to verify register addresses against the datasheet, then flashing the firmware to a real board.

The Problem: AI Doesn't Know Your Hardware

Large language models are trained on code, documentation, and forum posts. They learn patterns — what a vector table looks like, how GPIO registers are typically configured, what a linker script should contain. But they don't have a datasheet in front of them. They're pattern-matching, not engineering.

This leads to subtle but critical errors in AI-generated bare-metal code:

• Wrong peripheral addresses — An LLM defines #define GPIOA_BASE 0x40020000 for an STM32L4 target. That's the STM32F4 address. The correct L4 address is 0x48000000. The code compiles, flashes, and does nothing.
• Wrong struct layouts — An LLM places GPIO DIR registers at offset +0x4000 from the base when the real offset is +0x2000. The struct compiles perfectly, but every register access writes to the wrong address.
• Incorrect linker sizes — Every LLM we tested writes 640KB flash and 320KB SRAM for the LPC55S69. The usable contiguous values are 630KB and 256KB.
• Missing boot-time initialization — On complex MCUs like the NXP RT1176, the RTWDOG is enabled by default after reset. Firmware that doesn't disable it gets reset-looped before the LED ever toggles.

These aren't syntax errors. They compile cleanly with arm-none-eabi-gcc. They just don't work on real hardware. And until now, no AI tool catches them.

What RespCode Actually Does

When you submit a bare-metal prompt on RespCode — say, "Write a baremetal LED blink for LPC55S69-EVK" — here's what happens behind the scenes:

Each stage runs inside a Docker container with the full ARM bare-metal toolchain, CMSIS database with 2,177 SVD files, and Renode emulator pre-installed. The container is ephemeral, sandboxed, and network-isolated.

SVD Register Validation — The #1 LLM Failure Mode

This is the stage no other AI platform has. SVD (System View Description) files are vendor-published XML files that define every peripheral register, its base address, and its bit fields. We parsed 2,177 SVD files into our CMSIS database, covering 2,690 of our 2,701 supported MCUs (99.6% coverage).

When an LLM generates code like #define SYSCON_BASE 0x40000000, our validator extracts the address and cross-references it against the SVD database. If the address is wrong, we auto-fix it before compilation.

But SVD validation catches #define base addresses. What about the struct layout — the offsets from those base addresses to individual registers like DIR, SET, CLR, and NOT? That's where our binary analysis comes in.

The Flagship Battle: LPC55S69-EVK — 4 Models, 1 Board, 1 Winner

We gave the same prompt to four flagship AI models: Claude Opus 4, o1, Gemini 2.5 Pro, and DeepSeek Reasoner. The target: write a bare-metal LED blink for the NXP LPC55S69-EVK board, targeting PORT1 PIN4 (the green RGB LED). The prompt explicitly called out the 256KB SRAM and 630KB flash limits — traps that caught every model in earlier rounds.

Write bare-metal LED blink firmware for the LPC55S69-EVK board.
Target: LPC55S69JBD100 (Cortex-M33)

Board details:
- LED: PORT1 PIN4 (active low)
- Flash: 630KB at 0x00000000 (NOT 640KB — 10KB reserved)
- SRAM: 256KB at 0x20000000 (SRAM0-3 only, NOT 320KB)
  Warning: SRAM4 (64KB) is in a separate power domain. Use only 256KB.

Provide: main.c, lpc55s69.h, startup.c, linker.ld
Use direct register access. No SDK.

Compilation Results

Flagship Compete: LPC55S69-EVK — 3 of 4 Compiled Successfully

Flagship models on the LPC55S69-EVK. Claude Opus 4 (336 B), Gemini 2.5 Pro (528 B), and DeepSeek Reasoner (368 B) compile successfully. o1 fails with a linker script error — 631KB flash instead of 630KB.

All four models obeyed the 256KB SRAM instruction — none used 320KB. Three got 630KB flash correct. o1 uniquely failed by specifying 631KB (646,144 bytes instead of 645,120), plus a linker script syntax error. Three of four compiled successfully. But compilation success ≠ hardware success.

Deep Binary Analysis: Disassembling AI-Generated Firmware

We built a custom Thumb-2 disassembler to decode the main() function of each binary and trace every memory access to its effective address. For each peripheral register write, we verified the address against the LPC55S69 User Manual (UM11126). The results reveal bugs that no compiler, linter, or SVD check can catch.

What the Firmware Needs to Do

For an LED blink on PORT1 PIN4 of the LPC55S69, the firmware must:

1. Enable clocks — Write to SYSCON->AHBCLKCTRL0 at address 0x40000200 (offset +0x200 from SYSCON base). Set bit 13 (IOCON clock) and bit 15 (GPIO1 clock).
2. Configure the pin — Write to IOCON->PIO[1][4] at address 0x40001090. Set function 0 (GPIO).
3. Set direction — Write to GPIO->DIR[1] at address 0x4008E004 (GPIO base + 0x2000 + 4).
4. Toggle the LED — Write to GPIO->SET[1] at 0x4008E204 and GPIO->NOT[1] at 0x4008E304.

The critical detail: the LPC55S69 GPIO peripheral starts at 0x4008C000 and has a multi-kilobyte register layout. Byte-access registers (B[]) start at the base, word-access registers (W[]) are at +0x1000, and the direction/set/clear/toggle registers are at +0x2000. Getting this offset wrong means writing to the wrong register entirely.

The Source Code: Where the Bugs Hide

Each model produced a device header (lpc55s69.h) with a GPIO struct. The bugs hide in the struct padding that determines register offsets:

typedef struct {
    volatile uint8_t  B[6][32];     /* Byte access */
    volatile uint8_t  RESERVED0[0x1000 - 0xC0];
    volatile uint32_t W[6][32];     /* Word access */
    volatile uint32_t RESERVED1[0x1000 - 0x300];
    volatile uint32_t DIR[6];       /* Direction */
    ...
} GPIO_Type;
// ❌ RESERVED1 is (0x1000 - 0x300) = 0xD00 uint32_t = 0x3400 bytes
// Total offset to DIR: 0xC0 + 0xF40 + 0x300 + 0x3400 = 0x4700
// Effective DIR address: 0x4008C000 + 0x4700 = 0x40090700 ← WRONG

typedef struct {
    volatile uint8_t B[2][32];       /* Byte pin registers */
    uint8_t RESERVED_0[4032];
    volatile uint32_t W[2][32];     /* Word pin registers */
    uint8_t RESERVED_1[3840];
    volatile uint32_t DIR[2];       /* Direction — offset 0x2000 ✅ */
    uint8_t RESERVED_2[120];
    volatile uint32_t SET[2];       /* Set — offset 0x2200 ✅ */
    ...
    volatile uint32_t NOT[2];       /* Toggle — offset 0x2300 ✅ */
} GPIO_Type;
// ✅ B[2][32]=64 + 4032 pad = 0x1000 → W[2][32]=256 + 3840 pad = 0x2000
// DIR at +0x2000, SET at +0x2200, NOT at +0x2300 — ALL CORRECT

// ❌ Wrong GPIO base: 0x40010000 (SVD auto-fixed to 0x4008C000)
// ❌ Missing B[] and W[] arrays — DIR starts at offset 0
typedef struct {
    volatile uint32_t DIR[2];       /* offset 0x0000 — should be 0x2000 */
    uint32_t RESERVED0[30];
    volatile uint32_t SET[2];       /* offset 0x0200 — should be 0x2200 */
    ...
} GPIO_Type;
// ❌ DIR[1] lands at 0x4008C004 = B[0][4] byte register, NOT DIR[1]

The Disassembly Verdict: Register-by-Register

1. Clock Enable — SYSCON AHBCLKCTRL0

Required: write to 0x40000200 (SYSCON base + 0x200) with bits 13 (IOCON) and 15 (GPIO1).

2. GPIO Register Addressing — The Fatal Bug

GPIO Base:    0x4008C000
B[port][pin]  base + 0x0000         // Byte-access registers
W[port][pin]  base + 0x1000         // Word-access registers
DIR[port]     base + 0x2000 + port×4 // Direction
SET[port]     base + 0x2200 + port×4 // Set output
CLR[port]     base + 0x2280 + port×4 // Clear output
NOT[port]     base + 0x2300 + port×4 // Toggle output

For PORT1:
  DIR[1] = 0x4008E004    SET[1] = 0x4008E204    NOT[1] = 0x4008E304

Claude Opus 4 adds 0x4000 to the GPIO base instead of 0x2000. The Thumb-2 disassembly shows an ADD.W r3, r3, #0x4000 instruction. Every GPIO access writes to unmapped memory above 0x40090000. The LED will never blink.

DeepSeek Reasoner skips the byte/word register arrays entirely, placing DIR at offset 0 from the GPIO base. DIR[1] lands at 0x4008C004 — actually B[0][4], a byte-access register for a completely different port and pin.

Gemini 2.5 Pro gets every address exactly right. Its struct uses B[2][32] (64 bytes) + 4032 bytes padding = 0x1000, then W[2][32] (256 bytes) + 3840 bytes padding = 0x2000 for DIR. The disassembly confirms ADD.W r3, r3, #0x2000.

3. Blink Loop Patterns

DeepSeek has a second bug: it writes SET twice instead of alternating between SET and CLR (or using NOT). Even with correct addresses, the LED would turn on and stay on.

Hardware Validation: Flashing to the Real Board

Analysis predicted only Gemini's binary would work. We flashed all three to a physical LPC55S69-EVK board via the on-board LPC-Link2 debug probe.

LPC55S69-EVK Running Gemini 2.5 Pro Firmware

The RGB LED (bottom-right, near D0-D7 headers) lit up by Gemini 2.5 Pro's firmware. Red LED at top-left is the LPC-Link2 debugger status. First end-to-end proof: human prompt → AI code → SVD validation → ARM compilation → flash → real LED on real silicon.

Every prediction from the binary analysis was confirmed. The struct layout determines whether the firmware works or fails silently — and no amount of compilation success or SVD base-address validation can catch struct offset bugs.

"Same prompt, same compilation pipeline, same SVD validation — all three binaries pass compilation. But only one model produces a GPIO struct that puts DIR at offset +0x2000. That's the difference between a blinking LED and a write to unmapped memory."

Vector Table Analysis

All three correctly set SP to 0x20040000 (top of 256KB SRAM). Gemini populated all 54 device interrupt handlers, matching the LPC55S69 exactly — professional practice, not bloat.

The Harder Target: MIMXRT1170-EVK — 12 Models, 3 Tiers

The LPC55S69 is a well-known Cortex-M33. How do AI models handle a truly complex target? We chose the NXP MIMXRT1170-EVK — dual-core Cortex-M7/M4 at 1 GHz with ITCM/DTCM tightly coupled memory, an elaborate clock tree (CCM with LPCG-based clock gating), and a watchdog timer that's enabled by default out of reset.

We ran the same bare-metal LED blink prompt across 12 models in three tiers:

The Ultimate Scoreboard

Flagship Compete: MIMXRT1170-EVK — 3 of 4 Compiled Successfully

Flagship models on the MIMXRT1170-EVK. Claude Opus 4 (368 B), Gemini 2.5 Pro (320 B), and DeepSeek Reasoner (324 B) compile successfully. o1 fails with a linker script syntax error. Gemini 2.5 Pro generates the smallest binary in just 18.3 seconds.

The Watchdog Problem — Only 1 of 12 Survived

Open Source Compete: MIMXRT1170-EVK — 1 of 4 Compiled

Open source models on the MIMXRT1170-EVK. Only DeepSeek Coder compiles (292 B). Llama 3.3 70B forgets #include <stdint.h>. Qwen 3 32B has a struct/macro mismatch. Llama 3.1 8B produces completely wrong GPIO addresses in the Cortex-M system space (0xE000xxxx).

Of 12 models, exactly one handled the watchdog: Gemini 2.5 Pro. It generated code to unlock RTWDOG3 with the correct sequence (0xD928C520), set the timeout, and clear the enable bit — all before touching GPIO. Every other model's firmware would reset-loop on real silicon.

"Of 12 models tested on the RT1170, only Gemini 2.5 Pro handled the RTWDOG — a boot-time watchdog that resets the MCU before the LED ever toggles. Compilation success ≠ hardware success."

What We Learned Building This

1. Struct layouts are the #1 failure mode for real hardware

Not peripheral base addresses (SVD catches those). Not linker scripts. The single most dangerous bug in AI-generated firmware is wrong struct padding. The base address can be perfect, and the code still writes to the wrong register because the reserved-field sizes are wrong. This only shows up when you disassemble the binary or flash it to hardware.

2. Watchdog timers kill firmware on complex MCUs

On targets like the NXP RT1176, firmware must handle boot-time watchdogs before anything else. Only 1 of 12 models handled RTWDOG3. This knowledge lives deep in reference manuals that LLMs haven't adequately learned from.

3. Compilation success is a weak signal

On the LPC55S69, three of four flagship models compiled successfully. But only one produced firmware that actually works on hardware. arm-none-eabi-gcc happily compiles code that writes to unmapped memory.

4. Gemini 2.5 Pro dominates embedded targets

Across both boards, Gemini 2.5 Pro was the only model that produced hardware-viable firmware. On the LPC55S69 it was the fastest (18.3s) with all register addresses correct. On the RT1170 it was the only model to handle the watchdog. At 7 credits, it's also cheaper than Claude Opus 4 (15 cr) and o1 (20 cr).

5. Small models can't handle complex MCU targets

Llama 3.1 8B produced GPIO addresses in the Cortex-M system control space (0xE000xxxx), Thumb-1 assembly on a Thumb-2 target, and broken macro definitions. At 1.6 seconds, it was the fastest response — and the most wrong.

What's Next

• RespCode Autonomous Agent — An end-to-end AI agent that handles the entire workflow autonomously: generating firmware, validating registers, compiling, analyzing binaries, flashing to real hardware, and verifying the result — all without human intervention. The goal is a single prompt that goes from English description to confirmed-working firmware on physical silicon.
• SVD register injection into system prompts — Inject correct peripheral definitions from our SVD database directly into the LLM prompt, eliminating struct-offset bugs at generation time.
• Binary-level register verification — Automate the Thumb-2 disassembly analysis, flagging firmware that accesses addresses outside known peripheral regions.
• Hardware validation for MIMXRT1170-EVK — Flash the Gemini 2.5 Pro firmware and confirm it blinks on the RT1176 board.
• Watchdog detection — Post-compilation check that warns when firmware for MCUs with default-enabled watchdogs doesn't disable them.
• Linker script auto-fix — Automatically correct flash and SRAM sizes using the CMSIS database.
• Clock configuration validation — Cross-reference PLL/prescaler settings against vendor clock tree databases.

Try It Yourself

Open RespCode, select ARM32, choose Compete Mode, and try a bare-metal prompt:

Write bare-metal LED blink firmware for the LPC55S69-EVK board.
Target: LPC55S69JBD100 (Cortex-M33)

Board details:
- LED: PORT1 PIN4 (active low)
- Flash: 630KB at 0x00000000
- SRAM: 256KB at 0x20000000 (SRAM0-3 only)

Provide: main.c, lpc55s69.h, startup.c, linker.ld
Use direct register access. No SDK.
Target: LPC55S69JBD100

In Compete Mode with flagship models, you'll see four AI models each generate a complete firmware project — compiled, validated against SVD peripheral data, with downloadable binaries ready to flash.