Hardware Agent - Bare Metal Ethernet UDP program on STM32F767ZI: 5 AI Models, 1 Board, Raw Register Access

Bare-metal Ethernet is where “hello world” goes to die. To get a single ping on the STM32F767ZI, you need to initialize the RMII PHY, configure MAC DMA descriptors with strict memory alignment, build Ethernet frames with CRC from raw bytes, and handle ARP request/reply cycles. Most engineers spend days debugging a silent wire. We asked frontier AI models to do it in under 60 seconds.

Hardware Validated: AI-Generated Ethernet UDP Firmware on Real Silicon

AI-generated bare-metal Ethernet UDP firmware running on a physical Nucleo-F767ZI. Blue LED (PB7) active, Ethernet cable connected to LAN8742A PHY. Prompt → AI generates code → ARM cross-compilation → pyOCD flash → real UDP packets on the wire. No SDK, no HAL, no human edits.

The Challenge: Bare-Metal Ethernet Without a Safety Net

Bare-metal Ethernet on the STM32F767ZI requires getting at least 6 major subsystems correct simultaneously, all without any library, any HAL abstraction, or any example code to lean on:

• System Clock (PLL) ; HSE 8 MHz → PLL → 216 MHz SYSCLK. Wrong PLL dividers = wrong HCLK, wrong MDIO clock, wrong baud rate for UART debug. Everything cascades.
• RMII GPIO Pin Mapping ; 9 specific pins across 4 GPIO ports (PA1, PA2, PA7, PC1, PC4, PC5, PG11, PG13, PB13) must be configured as AF11. A single wrong pin or wrong port = no Ethernet signal.
• PHY Management (MDIO) ; The LAN8742A PHY at address 0 must be soft-reset, auto-negotiation must complete, and the MDIO clock divider must be set for 216 MHz HCLK (CR=100, HCLK/102).
• MAC Configuration ; The Ethernet MAC requires DMA soft reset, 100 Mbps full-duplex mode, store-and-forward DMA, and correct MAC address programming.
• DMA Descriptors ; TX and RX descriptor rings must be 32-byte aligned, chained correctly, with OWN bits managed between CPU and DMA. A misaligned descriptor = hard fault or silent DMA failure.
• Network Protocol Stack ; ARP request/reply handling to resolve MAC addresses, plus building complete Ethernet + IP + UDP frames from raw bytes with correct checksums.

This is not LED blink. This is not UART serial. This is the hardest single-prompt firmware generation test we’ve run on RespCode.

The Prompt

Write a bare metal Ethernet UDP program for STM32F767ZI.
The board has a LAN8742A PHY connected via RMII.
Configure static IP 192.168.0.200, send a UDP packet to
192.168.0.175 port 9000 every 2 seconds containing
"Hello from STM32F767ZI". Blink green LED on each packet sent.

One prompt. No hints about register addresses, no pin mapping, no clock configuration. The model must know ; or figure out ; every hardware detail from its training data, augmented by RespCode’s SVD register injection system.

The Agent Pipeline

This test was run on the RespCode Hardware Agent ; our autonomous firmware engineer. The agent takes a prompt, orchestrates AI models, compiles in cloud sandboxes, and in the case of the physical test, flashes to real hardware via pyOCD and captures UART output.

RespCode Agent: Compete Mode ; Ethernet UDP on Nucleo-F767ZI

The full agent run: 4 models generate in parallel, 2 compile (Opus and Gemini), GPT-5.2 hits a linker error, DeepSeek fails with wrong GPIO typedef. Opus is flashed via pyOCD, UART captures real UDP packets, and the agent declares the winner ; all autonomous, no human intervention.

Compete Mode: 4 Models, 2 Compiled, 1 Works

We ran Claude Opus 4.6, GPT-5.2, Gemini 3.1 Pro, and DeepSeek Coder simultaneously in Compete Mode. Each model received the same prompt with identical SVD register injection. The results diverged dramatically.

* GPT-5.2 compiled but produced firmware that could never work on the Nucleo-F767ZI due to wrong TX pin mapping.

Deep Code Analysis: What Went Right and Wrong

🏆 Claude Opus 4.6 ; The Winner

Opus produced the most comprehensive Ethernet firmware of any model we’ve tested: 836 lines of C across 5 files (main.c, startup.c, stm32f767zi.h, linker.ld, plus compiled binaries). The code demonstrates deep hardware understanding at every layer.

Clock Configuration: Opus correctly configured the PLL chain from HSE 8 MHz to 216 MHz SYSCLK with PLLM=8, PLLN=432, PLLP=2, PLLQ=9 ; matching the reference manual exactly. It set the flash wait states for 216 MHz, configured AHB/APB prescalers (APB1=/4, APB2=/2), and initialized SysTick at 216,000 ticks per millisecond. Every parameter is correct.

RMII Pin Mapping: All 9 RMII pins are correct, including the Nucleo-F767ZI-specific routing of TX_EN to PG11, TXD0 to PG13, and TXD1 to PB13. This is the critical detail that other models got wrong ; the STM32F767ZI datasheet allows multiple pin options for TX, and only the Nucleo board schematic reveals which are actually connected.

/* PG11 - ETH_TX_EN (AF11) */
gpio_set_af(GPIOG, 11, 11);
/* PG13 - ETH_TXD0 (AF11) */
gpio_set_af(GPIOG, 13, 11);
/* PB13 - ETH_TXD1 (AF11) */
gpio_set_af(GPIOB, 13, 11);

MDIO Clock Divider: Opus used CR=0b100 (decimal 4, selecting HCLK/102) for the MDIO interface, producing an MDC clock of ~2.1 MHz from 216 MHz HCLK ; safely within the LAN8742A’s 2.5 MHz maximum. The PHY initialization includes soft reset, PHY ID verification, auto-negotiation with timeout, and link speed/duplex detection from the LAN8742A’s Special Control/Status Register.

Full Protocol Stack: Unlike any other model, Opus implemented a complete bidirectional Ethernet stack: ARP request generation, ARP reply handling (both responding to requests and processing replies to resolve the destination MAC), and UDP packet construction with proper IP header checksums. The DMA ring buffers use 4 TX and 4 RX descriptors, 32-byte aligned, with correct OWN bit management.

UART Output: Claude Opus 4.6 Ethernet UDP on Nucleo-F767ZI

Real UART capture from the Nucleo-F767ZI running Opus 4.6’s firmware. Clock at 216 MHz, PHY link up at 100 Mbps full-duplex, ARP resolution to 38:CA:84:45:87:99, then continuous UDP packets to 192.168.0.175:9000 every 2 seconds. Every line generated by AI-written bare-metal code ; no SDK, no HAL.

⚠️ Gemini 3.1 Pro ; Compiled, But Three Fatal Flaws

Gemini produced the smallest binary at 2,152 bytes and the most compact code at 285 lines. It compiled cleanly and demonstrates correct Ethernet MAC/DMA initialization structure. But three independent errors killed it on real hardware:

Flaw 1 ; HSI Instead of HSE: Gemini configured the PLL from the internal HSI oscillator at 16 MHz, targeting 100 MHz SYSCLK instead of the Nucleo’s 8 MHz HSE crystal targeting 216 MHz. The Ethernet MAC needs a 50 MHz REF_CLK from the PHY, and the MDIO clock divider was set for a 100 MHz HCLK range (CR=2). While this isn’t necessarily fatal, it deviates from the board’s intended configuration and may cause MDIO timing issues.

Flaw 2 ; Wrong TXD1 Pin: Gemini mapped ETH_RMII_TXD1 to PG14. On the Nucleo-F767ZI, TXD1 is routed to PB13. PG14 is a valid alternate function for TXD1 on the STM32F767 chip, but on the Nucleo board, it’s not connected to the PHY. This means TX data bit 1 never reaches the LAN8742A ; every transmitted frame is corrupted.

Flaw 3 ; No ARP, Broadcast Only: Instead of resolving the destination MAC via ARP, Gemini sends all UDP packets to the broadcast address FF:FF:FF:FF:FF:FF. While this can technically work on a local network, it means the firmware never handles incoming ARP requests and can’t participate in normal IP communication. Combined with the TX pin error, no packets could ever reach the wire.

❌ GPT-5.2 ; Compiled, But Wrong TX Pins

GPT-5.2 produced a capable TX-only Ethernet implementation with proper UDP checksum calculation ; a detail Opus also got right but Gemini skipped. The code includes ARP request generation and a state machine for MAC address resolution. But a critical pin mapping error makes it dead on arrival.

The Fatal Error: GPT mapped the three RMII TX pins to PB11 (TX_EN), PB12 (TXD0), and PB13 (TXD1). On the Nucleo-F767ZI, TX_EN is on PG11 and TXD0 is on PG13. Only TXD1 on PB13 is correct. Worse, GPT never enabled the GPIOG clock ; it only enabled GPIOA, GPIOB, and GPIOC. Even if the pins were remapped, GPIOG would be powered off.

/* GPT-5.2 used generic STM32 pin mapping */
RMII_TX_EN  : PB11 (AF11)  /* ❌ Should be PG11 */
RMII_TXD0   : PB12 (AF11)  /* ❌ Should be PG13 */
RMII_TXD1   : PB13 (AF11)  /* ✅ Correct */

/* Missing: GPIOG clock not enabled */
RCC->AHB1ENR |= BIT(0) | BIT(1) | BIT(2);
/* Only GPIOA, GPIOB, GPIOC ; no BIT(6) for GPIOG */

This is a pattern we see repeatedly in AI-generated firmware: the model knows the chip’s alternate function table but not the board’s physical wiring. PB11/PB12 are valid AF11 options for ETH TX on the STM32F767, but the Nucleo-F767ZI routes those signals through PG11/PG13. Only board schematics ; or RespCode’s hardware database ; can disambiguate this.

❌ DeepSeek Coder ; Generated Code for the Wrong MCU

This is the most dramatic failure of the four. DeepSeek received a prompt explicitly requesting STM32F767ZI firmware with LAN8742A PHY over RMII. Instead, it generated NXP LPC55S69 code ; SYSCON registers at 0x40000000, IOCON pin mux, Flexcomm UART, and GPIO on port 1 pin 4. An entirely different ARM Cortex-M microcontroller family.

The code contains zero Ethernet functionality. No MAC, no DMA, no PHY, no ARP, no UDP. Instead, it outputs “UDP Packet #N: Hello from LPC55S69JBD100” over UART ; simulating UDP packets as serial text. The binary is only 1,004 bytes because there’s no Ethernet stack to compile.

Register-Level Correctness Analysis

The following table compares critical register configurations across the three models that targeted the correct MCU (Opus, Gemini, GPT). DeepSeek is excluded because it targeted a different chip entirely.

* GPT-5.2 omitted PLL configuration entirely. The STM32F7 always boots from the 16 MHz HSI oscillator on reset ; there is no “default” 216 MHz. Without explicit PLL setup, the firmware runs at 16 MHz, causing incorrect SysTick timing, wrong MDIO clock rates, and potentially broken Ethernet timing.

“Base addresses are the easy part ; SVD injection solves those. The hard part is board-specific pin routing, clock source selection, and peripheral initialization sequencing. That’s where models diverge and hardware fails silently.”

Single Mode: Sonnet 4.6 ; The Follow-Up That Worked

After the Compete Mode results, we ran the same prompt through Claude Sonnet 4.6 in Single Mode to see if a second Claude model could match Opus’s result. It did ; and in some ways exceeded it.

Sonnet’s code is 920 lines ; the most of any model ; with several production-quality touches. The startup file includes a 220-entry interrupt vector table covering every STM32F767 peripheral IRQ, compared to Opus’s 50 entries. The linker script correctly separates DTCM (for stack and CPU-exclusive variables) from SRAM1 (for .data, .bss, and DMA buffers). This distinction matters on the STM32F7: the DTCM at 0x20000000 is connected directly to the CPU’s TCM bus for zero-wait-state access, but the Ethernet DMA master operates on the AHB bus matrix and physically cannot access DTCM. DMA descriptors and packet buffers must live in SRAM1/SRAM2 (0x20020000+), which are AHB-accessible. Sonnet places DMA buffers in SRAM ; the correct architecture for DMA-safe Ethernet operation. The header file at 323 lines defines named constants for every PLL parameter, GPIO mode, and Ethernet register bit ; cleaner than raw magic numbers.

Sonnet also reads the LAN8742A’s PHY Special Control/Status Register (PHYSCSR) to detect actual link speed and duplex after auto-negotiation, then configures the MAC accordingly ; a detail Opus hardcodes as 100 Mbps full-duplex.

Code Architecture Comparison

The Claude models (Opus and Sonnet) stand out on protocol completeness: both implement bidirectional ARP handling, which is essential for real-world Ethernet. GPT-5.2 had the right idea with ARP request generation but couldn’t receive replies because it had no RX processing. Gemini took a shortcut with broadcast-only UDP, which avoids ARP entirely but breaks normal IP networking.

The RespCode Hardware Agent: What Made This Possible

This test was run entirely by the RespCode Hardware Agent ; an autonomous CLI tool that orchestrates the entire firmware development lifecycle. Here’s what the agent handles automatically:

• MCU Detection & SVD Injection: The agent parses the prompt, identifies the target MCU (STM32F767ZI), and injects precise register addresses, peripheral maps, and pin alternate functions from our database of 2,914 MCUs and 4.5 million indexed registers.
• Multi-Model Orchestration: In Compete Mode, the agent sends the same prompt to up to 11 AI models simultaneously. Each model generates a complete firmware project (main.c, startup.c, linker.ld, header files). In Single Mode, one model generates and the agent manages retry cycles.
• Cloud Compilation: Each model’s output is compiled in an isolated Docker container with the full ARM bare-metal toolchain (arm-none-eabi-gcc). The agent captures compiler output, warnings, and errors.
• Autonomous Flash & Verify: For connected hardware, the agent flashes compiled binaries via pyOCD (ST-Link, CMSIS-DAP, J-Link) or UF2 (Raspberry Pi Pico). It then captures UART output to verify the firmware is producing expected results.
• USB Board Auto-Detection: The agent detects connected development boards on startup by scanning USB devices across 8 families: STM32, NXP, Nordic nRF, Raspberry Pi Pico, TI, SEGGER J-Link, Microchip/Atmel, and CMSIS-DAP probes. Works on both Linux and macOS.
• 3-Attempt Retry System: If compilation fails, the agent feeds compiler errors back to the model and retries up to 3 times with escalating context. Many trivial failures (missing semicolons, naming mismatches) are resolved automatically.

The entire process ; from prompt to verified UDP packets on the wire ; takes under 60 seconds. No manual editing, no copy-pasting code, no debugging register addresses. The agent handles MCU detection, SVD injection, compilation, flashing, and UART verification autonomously.

• Board schematic injection ; Extending our hardware database beyond SVD register data to include board-level pin routing, crystal frequencies, and PHY connections. This would solve the PG11-vs-PB11 problem that killed GPT’s firmware.
• MCU-prompt validation ; Automatic detection when the SVD injection target doesn’t match the MCU referenced in the user’s prompt. Would have caught the DeepSeek mismatch.
• Network verification ; Extending the agent’s UART capture to include packet capture (tcpdump on the host) for automated verification that UDP packets actually arrive at the destination.
• Multi-peripheral progression ; After Ethernet: SPI loopback, I2C sensor reads, DMA transfers, USB device, and CAN bus ; each requiring progressively deeper hardware knowledge.

Try It Yourself

Open RespCode, select ARM32 Baremetal, choose Compete Mode, and try:

Write a bare metal Ethernet UDP program for STM32F767ZI.
The board has a LAN8742A PHY connected via RMII.

Or install the agent and flash directly to your Nucleo board:

curl -fsSL https://respcode.com/agent/install.sh | bash
respcode-agent