AEL — AI-Driven Embedded Engineering

AEL (AI Embedded Lab) is a new way of doing embedded engineering.

Instead of writing code, flashing firmware, and debugging manually, you define the goal — and AI executes the workflow.

AI generates firmware
AI runs it on hardware or simulation
AI analyzes results and fixes issues
AI iterates until it works

This turns embedded development into a closed-loop system:

AI → Generate → Execute → Observe → Iterate

🚀 What is AEL?

AI executes the embedded workflow end-to-end
Humans define goals, not steps
Development becomes a closed-loop system on real hardware

👉 Demo video showcasing AI-driven embedded development in action: AI-Driven Embedded Development: STM32 + ESP32JTAG.

👉 Tutorial: Getting_Started_with_AI_Driven_Embedded_Development_Using_STM32 + ESP32JTAG

👉 Learn more: AEL Paradigm Shift

🚀 Installation and Getting Started

AEL is intentionally simple to install and easy to use.

Clone and set up the AEL repository.
Start an AI coding agent inside the repository, such as Codex or Claude Code.
Describe your goal in natural language.

That is the basic workflow.

You do not need to learn a large command surface before getting started. In the common case, you work inside the AEL repository with your AI agent and simply say what you want to do: bring up a board, generate firmware, run a test, investigate a failure, or validate a hardware feature. AEL provides the structure, assets, and command surface underneath, while the AI agent uses them to carry out the work.

This is one of AEL’s main advantages: it is powerful, but still easy to use. The experience is not centered on memorizing commands or manually stitching together tools. Instead, you install the repository, open an AI agent in that environment, and start working through natural language.

Hardware

AEL is built for real hardware — but the barrier to entry is surprisingly low.

You can start with almost nothing:

ST-Link + an STM32 MCU/board — a standard path, often just $10–20 USD
a single ESP32 dev board — already enough to begin exploring AI-driven workflows
ESP32JTAG + a target board — a next-gen, all-in-one instrument

From "debug probe" → to "AI instrument"

Traditional tools like ST-Link do one thing well: → flash and debug

AI instrument like ESP32JTAG changes the model:

Wireless (WiFi) — no cables, AI can access it over the network
Flash firmware
Capture signals at high speed (~256 MHz in supported setups)
Generate stimulus signals
Interact with hardware in real time

Instead of multiple lab tools, you get one programmable, networked instrument.

Why this matters

This is not just cheaper hardware.

It changes how embedded systems are developed:

The instrument becomes AI-controllable
The workflow becomes fully automated
Hardware is no longer "manual-only"

In many cases, a single ESP32 device can replace an entire entry-level lab setup.

You do not need expensive equipment to begin.

AEL is designed so that real hardware + AI becomes accessible, programmable, and scalable.

🤖 Natural-Language-First Usage

AEL is designed to be driven by AI. Instead of relying on manual command-by-command operation, you describe your goal to the AEL Agent, for example through Codex or Claude Code running inside the repository.

Example 1: New Hardware Bring-up

User: “I have an STM32F411 Black Pill and an ST-Link. Can you help me run a smoke test?”
AEL Agent: “I can use ST-Link as the flashing and debug interface for your F411. I’ll generate a minimal smoke test, flash it, and verify startup through a mailbox signal. Shall I proceed?”

Example 2: Feature Validation

User: “Generate firmware for my RP2040 that toggles GPIO 16 at 1 kHz, then verify the frequency.”
AEL Agent: “I will generate the RP2040 firmware, build it, flash it to your Pico, and then use the connected Instrument to capture and verify the 1 kHz signal on GPIO 16. I’ll report the measured frequency back to you.”

Example 3: Debugging

User: “My UART loopback test is failing on the G431. Can you investigate?”
AEL Agent: “I’ll check the UART configuration in the firmware, verify the physical loopback connections using the Connection Doctor, and then rerun the test with additional debug logging enabled.”

Instead of stopping at code generation, AEL allows AI and the engineer to collaborate: designing tests, debugging failures, and completing experiments using evidence from real hardware.

This project explores a future where AI becomes an active engineering partner in embedded development.

🚀 Latest Milestones

CH32V203C8T6 + CH32V305RBT6 — Dual WCH RISC-V Golden Suites Complete (2026-04-12)

AEL has validated two WCH RISC-V boards end-to-end via WCHLink-E SDI, adding 48 passing tests to the golden registry in a single session.

CH32V203C8T6 (nanoCH32V203) — 23/23 PASS

A budget RISC-V (RV32IMAC @ 72 MHz, 64 KB Flash, 20 KB SRAM) with near-complete STM32F103-compatible peripheral coverage:

Stage	Tests	Peripherals
Stage 0 — Boot	2	GPIO blinky (visual + mailbox)
Stage 1 — On-chip	13	SysTick, IWDG, RTC, Flash R/W, CRC, ADC Vrefint, ADC temp, ADC+DMA, DMA M2M, CAN loopback, PVD, BKP, TIM OPM
Stage 2 — Loopback	8	Wire-check, GPIO, EXTI, UART, DMA-UART, SPI, SPI-DMA, TIM PWM+capture

Stage 2 wiring (4 jumpers):

PA2  ↔ PA3   — GPIO loopback / EXTI
PA9  ↔ PA10  — UART loopback / DMA-UART
PA7  ↔ PA6   — SPI MOSI↔MISO / SPI-DMA
PA8  → PA0   — TIM1 PWM → TIM2 capture

Canonical result:

DUT: ch32v203xxx (RV32IMAC @ 72 MHz, WCHLink-E SDI)
Pack: packs/ch32v203xxx_golden.json

CH32V305RBT6 (nanoCH32V305) — 25/25 PASS

An enhanced WCH RISC-V (RV32IMAFCXW @ 96 MHz, 128 KB Flash, 32 KB SRAM) with hardware FPU, hardware RNG, and full CAN/SPI-DMA coverage:

Stage	Tests	Peripherals
Stage 0 — Boot	2	GPIO blinky (visual + mailbox)
Stage 1 — On-chip	13	SysTick, IWDG, RTC, Flash R/W, CRC, ADC Vrefint, ADC temp, ADC+DMA, DMA M2M, CAN loopback, PVD, BKP, RNG
Stage 2 — Loopback	10	Wire-check, GPIO, EXTI, UART, DMA-UART, SPI, SPI-DMA, TIM PWM+capture, TIM OPM, USART half-duplex

Stage 2 wiring (4 jumpers, identical layout to V203):

PA1  ↔ PA2   — GPIO loopback / EXTI / USART HDSEL pull-up
PA9  ↔ PA10  — UART loopback / DMA-UART / USART HDSEL echo
PA7  ↔ PA6   — SPI MOSI↔MISO / SPI-DMA
PA8  → PA0   — TIM1 PWM → TIM2 capture

Key engineering discoveries:

Finding	Impact
`ch32v30x_rng.h` not included in `ch32v30x_conf.h` — must be explicit	Compile error without it
CH32V30x HDSEL: RX disabled during TX; TC→RX guard ≈ 1–2 bit periods	Echo must wait ≥3 bit periods after TC (fix: `wait_bit()×3`)
TIM2 is 32-bit on V305 (unlike V203's 16-bit)	No `& 0xFFFF` mask in capture difference
ADC clock max 14 MHz: use `RCC_PCLK2_Div8` at 96 MHz	Prevents ADC mis-conversion

Canonical result:

DUT: ch32v305xxx (RV32IMAFCXW @ 96 MHz, WCHLink-E SDI)
Pack: packs/ch32v305xxx_golden.json
Report: reports/ch32v305xxx_golden_suite_report.md

nRF52840 nice!nano v1 — First Nordic + Zephyr Golden Suite: 15/15 PASS (2026-04-12)

AEL completed a full golden suite on the nRF52840 nice!nano v1 — a Pro Micro form-factor keyboard controller board — using UF2 mass-storage flashing (no SWD probe required) and USB CDC-ACM observation. This is AEL's first validated Zephyr-native target without any external debug probe.

What was covered:

Category	Tests	Peripherals
Stage 0 — Boot	2	UF2 blinky (visual), USB CDC banner
Stage 1 — On-chip	6	TEMP, RNG, TIMER0, RTC1, NVMC flash R/W/erase, AES-ECB
Stage 2 — Loopback	5	GPIO, UART, SPI full-duplex, PWM+capture, SAADC (VBATT divider)
Stage 2 — Radio	2	BLE 2.4 GHz beacon, IEEE 802.15.4 bare-metal PLL lock

Stage 2 wiring (4 connections total):

P0.17 ↔ P0.20  — GPIO / UART loopback  (left-col PIN6↔PIN5)
P1.13 ↔ P1.11  — SPI MOSI→MISO        (right-col PIN16↔PIN15)
P0.22 → P0.24  — PWM → capture        (left-col PIN7→PIN8)
P0.31           — SAADC, no wire      (on-board VBATT divider)

Key engineering discoveries:

Finding	Impact
IEEE 802.15.4 `CONFIG_IEEE802154` requires full networking stack — use bare-metal RADIO registers instead	Avoids 100+ KB ROM overhead
nice!nano connector only exposes specific P1.xx pins — P1.10/P1.12 not on header (see nrfmicro wiki)	Prevents silent SPI wiring mistakes
Zephyr 4.x USB CDC: `USB_DEVICE_STACK_NEXT` + `USBD_CDC_ACM_CLASS` (old `CDC_ACM_SERIAL_*` removed)	Required for all Zephyr 4.x USB CDC targets
Stage 1 firmware prints sub-results at ~1.5s boot; `post_load_settle_s=4` misses them — match `AEL_STAGE1_PASS` in repeat loop	Fixes false-FAIL on all 6 stage1 tests

Canonical result:

DUT: nrf52840_nicenano (Cortex-M4F @ 64 MHz, 1 MB Flash, UF2 bootloader)
Pack: packs/nrf52840_nicenano_golden.json
Report: docs/reports/nrf52840_nicenano_golden_suite_closeout_2026-04-12.md

CH32V003F4U6 — First RISC-V Board Validated with AEL: 14/14 PASS (2026-04-06)

AEL has been successfully validated on a RISC-V architecture for the first time. The CH32V003F4U6 (WCH RV32EC, 24 MHz HSI, 16 KB Flash, 2 KB SRAM) completed a 14-test golden suite via WCH-LinkE SDI (1-wire debug), covering nearly the full peripheral set of this ultra-low-cost RISC-V MCU.

What was covered:

Category	Tests	Peripherals
I/O / Loopback	3	GPIO, UART (TX-only + bidirectional), SPI full-duplex
Interrupts / Capture	2	EXTI rising-edge, TIM1 PWM + EXTI capture
Timers / Watchdogs	3	TIM2 free-running, SysTick, IWDG, WWDG
Internal Peripherals	3	ADC Vrefint (ch8), DMA1 MEM2MEM, Flash R/W/Erase
Power	1	PWR sleep + AWU wakeup

Key engineering discoveries (all recorded in Civilization Engine):

Finding	CE ID	Impact
WCH OpenOCD `init` halts target — `catch {resume}` required	`91a479e9`	[HIGH_PRIORITY] pattern
CH32V003 AFIO EXTICR: 2-bit/line layout (not 4-bit like STM32)	`d994bafa`	board_family
ADC EXTSEL must be 0b111 for SWSTART to work	`db402746`	board_family
ch32v003fun.c `.data` startup copy bug — use `.bss` + runtime init	`5e480c33`	[HIGH_PRIORITY] board_family
TIM2 CNT is 16-bit — use modulo subtraction + UIF flag	`ae4804b7`	board_family

Canonical result:

DUT: ch32v003xxx (RV32EC @ 24 MHz HSI, WCH-LinkE SDI probe)
Pack: packs/ch32v003_golden.json
Report: docs/reports/ch32v003_golden_suite_closeout_2026-04-06.md

Zephyr + FreeRTOS — Three-Board RTOS Coverage Complete (2026-04-05)

AEL now has full RTOS coverage across three boards and two RTOS families (Zephyr and FreeRTOS). Every board in the active bench can run bare-metal, FreeRTOS, and Zephyr firmware under closed-loop AEL validation with no bench reconfiguration.

12 RTOS tests across 3 boards, all PASS

Board	Chip	Instrument	UART path	Zephyr (3)	FreeRTOS (1)
STM32F103RCT6	Cortex-M3 @ 72 MHz	DAPLink CMSIS-DAP	PA9 → DAPLink bridge `/dev/ttyACM0`	✅ hello_loop / synchronization / philosophers	✅ freertos_uart
STM32F4 Discovery	Cortex-M4 @ 16 MHz HSI	ST-Link onboard	PA2 → USB-UART `/dev/ttyUSB0`	✅ hello_loop / synchronization / philosophers	✅ freertos_uart
STM32H563RGT6	Cortex-M33 @ 64 MHz HSI	DAPLink CMSIS-DAP	PA9 → DAPLink bridge `/dev/ttyACM0`	✅ hello_loop / synchronization / philosophers	✅ freertos_uart

RTOS proof points (identical across all three boards):

Test	RTOS	What it proves
`*_zephyr_hello_loop`	Zephyr	Full west build → pyocd/openocd flash → UART observe pipeline
`*_zephyr_synchronization`	Zephyr	Kernel scheduler + semaphore: two threads alternate every 500 ms
`*_zephyr_philosophers`	Zephyr	6 threads (preemptible + cooperative) compete for mutexes — EATING/THINKING/STARVING confirmed
`*_freertos_uart`	FreeRTOS	Two tasks at different priorities print `TICK` interleaved; scheduler and `vTaskDelay` verified

Key per-board engineering notes:

STM32H563RGT6 (Zephyr): nucleo_h563zi Zephyr board used with a DTS overlay disabling HSE/PLL and switching to HSI 64 MHz — the board carries no external crystal. Console remapped from USART3/PD8 to USART1/PA9. Overlay applied via -DDTC_OVERLAY_FILE= CMake arg (more reliable than --extra-dtc-overlay with west 1.5.0 for upstream samples).
STM32F4 Discovery (Zephyr): stm32f4_disco board — console is PA2/USART2; PA9/PA10 are hardwired to the onboard ST-Link USB-UART bridge and cannot be used as a user UART.
STM32F103RCT6 (Zephyr): stm32f103_mini board — DAPLink USB-UART bridge doubles as console adapter; no separate USB-serial adapter needed.
FreeRTOS (all boards): ARM_CM3 FreeRTOS port used on all three (including Cortex-M4/M33 with -mfloat-abi=soft). Handler names mapped via FreeRTOSConfig.h macros. _init() stub required for ST ASM startup's __libc_init_array.

ZephyrBackend fixes landed this session:

ZephyrBackend.build(): --extra-conf / --extra-dtc-overlay flags must precede the source directory argument — west ignores them when placed after [source_dir].
build_zephyr.py: added extra_conf_file / extra_overlay_file field resolution; resolves repo-relative paths to absolute before passing to west.

Hybrid Mode — Zephyr + bare-metal in one pack run:

packs/stm32f103rct6_hybrid.json runs 3 bare-metal mailbox tests and 2 Zephyr UART observe tests interleaved on the same board, all PASS in a single ael pack run. AEL's pack runner is firmware-class-agnostic: Zephyr and bare-metal firmware coexist in the same suite without conflict.

Canonical assets:

Asset	Path
ZephyrBackend	`ael/backends/zephyr_backend.py`
Test plan template	`tests/plans/templates/zephyr_uart_observe_template.json`
Firmware template	`firmware/templates/zephyr_hello_loop_template/`
Board onboarding guide	`docs/guides/zephyr_ael_board_onboarding.md`
Hybrid pack	`packs/stm32f103rct6_hybrid.json` — 5/5 PASS (3 bare-metal + 2 Zephyr)

STM32H563RGT6 — Deepest Cortex-M33 Golden Suite: 46/46 PASS via DAPLink (2026-04-05)

AEL completed the most comprehensive STM32H5-series bare-metal golden suite: 46 tests across 35+ peripherals on an STM32H563RGT6 board (Cortex-M33, 250 MHz, TrustZone), validated via DAPLink/CMSIS-DAP over USB.

What was covered:

Category	Tests	Peripherals
Connectivity / Loopback	6	GPIO, UART, EXTI, SPI, PWM capture, I2C
Analog	3	ADC loopback, DAC→ADC, ADC internal temp
Core / Runtime	3	minimal runtime mailbox, FPU, MPU
DMA / Cache / Memory	5	GPDMA1 M2M, GPDMA2 M2M, ICache, DCache, RAMCFG
Timers	5	TIM basic, LPTIM, LPTIM multi, LPTIM2, TIM15/16/17
Crypto / Math Accelerators	4	CRC, HASH (SHA-256), CORDIC, FMAC
ID / RNG / Sensor	3	UID, RNG, DTS (temp sensor)
Communication Peripherals	7	LPUART, FDCAN, USB DRD FS, I3C, CEC, UCPD, CRS
System / Security	7	SBS, SAU (TrustZone), DBGMCU, DWT, Flash option bytes, BKPSRAM, VREFBUF
RTC / Tamper / Watchdog	3	RTC, TAMP, WWDG

Key engineering findings:

PKA ECC anomaly — PKA internal SRAM ECC state survives NRST and appears to persist even after power cycle on this board instance; INITOK never fires within any tested timeout. Suspended pending board-swap diagnosis. See docs/reports/stm32h563rgt6_pka_mailbox_investigation_2026-04-05.md.
STM32H5 DTS requires TS1_START (CFGR1 bit4) + ITENR.TS1_ITEEN for valid measurements; TS1_RDY alone is insufficient. CE record db885....
FDCAN needed multiple iterations to stabilize (19% historical pass rate → now reliable); key was correct bit-timing configuration at HSI 64 MHz.

Canonical result:

DUT: stm32h563rgt6 (Cortex-M33 @ 64 MHz HSI, 512 KB Flash, TrustZone)
Pack: packs/stm32h563rgt6_golden.json
Report: docs/reports/stm32h563rgt6_golden_suite_closeout_2026-04-05.md

STM32F103C6T6 — Blue Pill Golden Suite: 24/24 PASS via ESP32JTAG (2026-04-01)

AEL completed a full 24-test staged golden suite on an STM32F103C6T6 (Blue Pill-like) board via ESP32JTAG over WiFi, covering the complete Cortex-M3 peripheral set available on this small 64 KB Flash chip.

What was covered:

Stage	Tests	Peripherals
0 — Board life	pc13_blinky_visual, minimal_runtime_mailbox	LED blink (LA-verified), mailbox health
1 — Internal self-tests	timer, systick, internal_temp, system_identity, reset_cause, sleep_wfi, adc_vref, iwdg	TIM2, SysTick, ADC temp, UID, RCC reset cause, WFI, VDDA sense, IWDG
Pre-Stage 2 — Wire scan	pb0_pb1, pb8_pb9, pa0_pa1_adc, pb15_pb14 probes	GPIO connectivity verification via IDR scan
2 — Functional	gpio_loopback, exti_trigger, adc_loopback, capture_mailbox, pwm_capture, tim3_pwm, spi1_loopback, uart_loopback, uart_multibyte, uart_dma	GPIO, EXTI, ADC, TIM3 capture+PWM, SPI1, USART1

Canonical result:

DUT: stm32f103c6t6 (Blue Pill-like, Cortex-M3 @ 72 MHz, 64 KB Flash)
Instrument: esp32jtag_stm32_golden @ 192.168.2.98:4242
Pack: packs/stm32f103c6t6_golden.json
Report: docs/reports/stm32f103c6t6_golden_suite_closeout_2026-04-01.md

STM32F407VET6 — Deepest Cortex-M4 Golden Suite: 21/21 PASS via ESP32JTAG (2026-04-01)

AEL completed the most comprehensive STM32 bare-metal golden suite to date: 21 tests across 20 peripherals on a custom STM32F407VET6 board, validated end-to-end via ESP32JTAG over WiFi (BMDA/SWD).

What was covered:

Stage	Tests	Peripherals
0	timer_mailbox	TIM3 IRQ, mailbox health
1	gpio, uart, spi	GPIO loopback, USART2, SPI2
2	adc_temp, exti, adc_loopback	ADC1 (internal temp + external), EXTI
3 (14 tests)	i2c, pwm_capture, dma_m2m, crc, rng, dac_adc, fpu, rtc, uart_dma, spi_dma, can, tim2, flash, dac_dma	I2C master↔slave, TIM4 PWM+capture, DMA2 M2M, CRC unit, RNG (PLL48CLK), DAC1→ADC1, FPU (7 sub-tests), RTC+LSI, DMA1 UART/SPI, CAN1 internal loopback, TIM2 32-bit, Flash sector erase/write, DMA2 circular DAC waveform + ADC verify

Key engineering findings recorded to Civilization Engine:

3f13ca66 — ARM Cortex-M bare-metal must define HardFault_Handler with SYSRESETREQ (AIRCR=0x05FA0004). Without it: HardFault → Cortex-M LOCKUP → SWD cannot halt → all subsequent pack tests fail. Applies to all Cortex-M MCUs (STM32, RP2040, NXP, SAM) loaded via any JTAG/SWD tool.
DMA2 required for M2M on F407 — DMA1 cannot do memory-to-memory transfers.
RNG needs PLL48CLK = 48 MHz — configure PLLM=16 / PLLN=192 / PLLQ=4 from 16 MHz HSI.
CAN internal loopback (BTR.LBKM=1) — no external transceiver needed; must configure ≥1 RX filter or FIFO stays empty.

Canonical result:

DUT: stm32f407vet6 (custom board, 512 KB Flash, Cortex-M4 @ 16 MHz HSI)
Pack: packs/stm32f407vet6_golden.json
Report: reports/stm32f407vet6_golden_suite_report.md
CE golden run: 0e8931af-d3b4-4de5-bb1a-7e7047c75fc3

STM32 + DAPLink Milestone — AEL Brings Up CMSIS-DAP on Linux and Completes `STM32F103RCT6` Golden Suite (2026-03-31)

AEL now supports a practical DAPLink / CMSIS-DAP workflow for STM32 development on Linux, and that path has already been carried through to a completed golden suite on a real STM32F103RCT6 target.

What was done:

Brought up a real CMSIS-DAP_LU DAPLink probe on Linux
Installed and tested pyOCD, then documented why it was not the right tool path for this specific HID-style probe
Switched to OpenOCD, forced the working cmsis_dap_backend hid path, and established stable SWD flash/debug access
Identified the target in software as STM32F1 high-density / Cortex-M3, matching STM32F103RCT6
Validated DAPLink UART on PA9/PA10
Built and validated a formal STM32F103RCT6 staged suite on the DAPLink fixture
Promoted that suite to canonical golden status in AEL

Why this matters:

This milestone proves AEL is not limited to ST-Link or WiFi-based instruments for STM32 workflows. A low-cost USB DAPLink probe can also be brought under AI control for real STM32 development: identify the chip, recover flash access, program firmware, read mailbox state, validate UART behavior, and close out a full golden suite.

Canonical result:

DUT: stm32f103rct6
pack: packs/stm32f103rct6_golden.json
tutorial: docs/tutorials/stm32f103rct6_daplink_to_golden_suite_tutorial_2026-03-31.md

AMD(Xilinx) Artix XC7A35T — Closed-Loop FPGA Verification via ESP32JTAG LA (2026-03-27)

The first FPGA milestone is complete: AEL can now take over, modify, build, program, instrument, and verify a Xilinx FPGA project on real hardware!

AEL completed a full closed-loop verification workflow on a Xilinx Artix-7 (xc7a35tfgg484-2) FPGA project using the PA35T StarLite board. This extends AEL's reach beyond MCU firmware into repeatable, measurement-backed FPGA validation on real hardware.

What was done:

Brought a Vivado brownfield FPGA project under AEL command-line build and program control (build.tcl / program.tcl)
Integrated the design as an AEL DUT asset (assets_golden/duts/pa35t_starlite_led/)
Extended the RTL to expose internal counter bits as LA probe outputs on the JM1 connector (4 × LVCMOS33 output pins)
Captured all 4 channels simultaneously via ESP32JTAG logic analyzer at 264 MHz sample rate
Wrote a new AEL adapter (observe_fpga_counter_freq.py) for multi-channel frequency, duty cycle, and divide-ratio verification
Ran end-to-end automated verification — all three stages PASS

Verification results (counter_freq_verify.py):

Stage	Check	Result
Stage 1	Frequency accuracy (4 channels)	PASS ±1% (observed ~0.56% offset)
Stage 2	Duty cycle (50% target)	PASS ±6% (50 MHz is quantization-limited at 264 MHz LA)
Stage 3	Adjacent-channel divide ratio (2:1)	PASS ±0.1% (max error 0.016%)

Additional finding — clock offset measurement:

All channels showed a consistent ~0.56% frequency offset (~5600 ppm), confirming a systematic clock difference between the FPGA oscillator and the ESP32JTAG measurement reference. AEL detected and reasoned about this real hardware characteristic automatically.

Why this matters:

This milestone demonstrates a practical FPGA workflow under AEL: modify RTL → build → program → capture signals → verify behavior quantitatively. The same instrument infrastructure (ESP32JTAG as a networked LA) that validates MCU firmware works equally well as a measurement backend for FPGA designs — showing AEL's approach scales across device families.

Brownfield Embedded Project — AEL Drives a Real Firmware Project to Open-Source Release (2026-03-27)

AEL was applied to esp32jtag_firmware, an existing embedded firmware project for the ESP32JTAG instrument, as a concrete real-world test of AEL's engineering capabilities beyond greenfield prototyping.

This was not a demo or a toy project. The firmware had real hardware dependencies, an existing architecture, and outstanding work: bugs to fix, features to complete, issues to resolve, and a release to prepare. AEL was used to take over and drive that remaining work.

What AEL did:

Reviewed the existing codebase and understood its architecture without starting from scratch
Identified and fixed bugs across the firmware stack
Resolved hardware bring-up issues encountered during integration testing
Completed remaining features required for the release milestone
Ran the project through validation against real hardware (RP2040 Pico DUT via SWD)
Prepared the project for open-source publication

The result:

The firmware project was brought to release state and published as an open-source project. AEL contributed materially to the speed and quality of that outcome.

Why this matters for AEL:

Most AI-assisted embedded development work targets fresh greenfield projects. This milestone demonstrates that AEL can be applied to existing brownfield work — reviewing unfamiliar code, working within established constraints, and producing verifiable engineering outcomes on real hardware. That is a meaningfully harder problem, and a more representative test of practical utility.

📄 ESP32JTAG Firmware Brownfield Onboarding Pattern — experience captured in the Civilization Engine (92fd939d)

RP2040 Pico + S3JTAG — Full Rule-B Golden Suite Validated (2026-03-26 / 2026-03-27)

AEL completed a full Rule-B golden test suite for the RP2040 Pico using the S3JTAG wireless instrument over WiFi. This is the 2nd validated ARM Cortex-M + wireless instrument combination in AEL after ESP32JTAG: SWD access, flash, and signal verification all happen over the network — no USB cable from the host to the debug probe.

Instrument setup:

S3JTAG (ESP32-S3 based) acts as a networked BMDA (Black Magic Debug App) SWD probe. It is based on open source project esp32jtag_firmware.
Connected to RP2040 Pico via SWDIO, SWCLK, and signal wires
All AEL pipeline operations (flash, GDB mailbox read, UART observe, signal capture) go through WiFi

Test suite — 13 tests across three stages:

Stage	Test	Coverage
Stage 0	`minimal_runtime_mailbox`	Basic bring-up gate — firmware boots and mailbox responds
Stage 1	`internal_temp_mailbox`	Internal temperature sensor via ADC
Stage 1	`timer_mailbox`	Hardware repeating timer ISR
Stage 2	`gpio_level_low / high`	GPIO output levels via S3JTAG TARGETIN capture
Stage 2	`gpio_signature_100hz / 1kHz`	GPIO frequency output measured by S3JTAG
Stage 2	`pwm_capture`	PWM duty cycle and frequency capture
Stage 2	`gpio_interrupt_loopback`	GPIO interrupt driven by loopback wire
Stage 2	`uart_rxd_detect`	UART RX line detection via S3JTAG
Stage 2	`uart_banner`	Full UART text output via S3JTAG Web UART bridge
Stage 2	`spi_loopback`	SPI MOSI→MISO loopback
Stage 2	`adc_loopback`	ADC input driven by GPIO output

Additional validated asset (2026-03-27):

timer_led_blink_ctrl — a bidirectional mailbox test: firmware drives GPIO25 LED via a 10 ms timer ISR; AEL reads led_state, toggle_count, and period_ms from the mailbox via GDB, and can write cmd_period_ms to change the blink rate at runtime. Demonstrates live firmware observability over SWD.

Rule-D combined firmware:

A full_suite firmware asset runs all 13 sub-tests sequentially and reports results via UART through the S3JTAG Web UART bridge — a single flash covers the full board validation pass.

Closeout reports:

ESP32 Family Golden Suite Coverage — Major ESP32 Series Validated (2026-03-26)

AEL now has systematic golden test suite coverage across the major ESP32 families:

Board	Family	Suite
ESP32-WROOM-32D	ESP32 (original)	Rule-B
ESP32-C3 DevKit	ESP32-C3	Rule-B
ESP32-C5 DevKit	ESP32-C5	Rule-B
ESP32-C6 DevKit	ESP32-C6	Rule-B
ESP32-S3 DevKit	ESP32-S3	Rule-B

Each board was validated against a consistently structured golden test suite covering the core peripheral set: GPIO, UART, SPI, ADC, PWM, interrupt handling, and board-specific features (WiFi, BLE, sleep modes, temperature sensor, NVS). The suite structure is uniform across families, making coverage directly comparable and results reproducible.

What this represents for AEL:

This is not ad-hoc board support added incrementally. Each entry was validated through the same systematic Rule-B methodology, with a firmware asset, a test pack, a golden record, and a detailed closeout report. The result is a coherent cross-family baseline that can serve as a regression anchor as the platform evolves.

Closeout reports:

AEL Experience System v0.1 — Record, Reuse, and Grow from Engineering Experience (2026-03-22)

AEL now records, reuses, and grows from engineering experience.

Completed in this milestone:

Experience Engine — structured Experience Unit storage with confidence, tags, outcome, and feedback loop
Civilization Engine (ael/civilization/) — the only layer that talks to the Experience Engine; pipeline never imports it directly
Closed Experience Loop (run → record → reuse) — skills from past debugging sessions surface before the next run on the same board

The before-run protocol now outputs four sections every time a run begins:

Run statistics — N runs, S success / F failed, confidence
Known skills — fix/decision experiences relevant to this board and domain
Likely pitfalls — paths previously marked as dangerous
Observation focus — derived watch points from past failures

A new record_skill() entry point allows capturing reusable engineering fixes at the moment of realization — during or after a run, with no dependency on run-outcome sequence. Fields: trigger, fix, lesson, scope, source_ref.

AEL has moved from pure automation toward an experience-driven engineering system.

📄 Full memo 📄 Civilization Engine v0.1 Spec 📄 Civilization Engine essentials

Schema Convergence Milestone — Default Verification Reached Parallel Stable Closure (2026-03-20)

The post-refactor validation result now shows that AEL has moved past "functionally working" and into a stable converged phase.

A six-platform, cross-instrument default verification baseline was run in full parallel mode for three consecutive rounds, and all three rounds passed without flaky behavior.

This milestone supports four concrete conclusions:

system behavior has converged
the schema abstraction and execution model are self-consistent
the architecture is not showing hidden coupling or unstable resource contention on this baseline
AI can now drive the full repo-native engineering loop repeatedly on real hardware with stable outcomes

What this means in practice:

default verification is no longer only a feature demo or a one-off green run
the repaired ST-Link path now holds inside the same parallel batch as the ESP32JTAG and meter-backed paths
the recent schema and execution-layer changes now have repeated live-bench evidence behind them

Representative live evidence:

first full six-way parallel pass: 2026-03-20_10-33-07
repeated six-way parallel passes:
- 2026-03-20_10-36-49
- 2026-03-20_10-37-43
- 2026-03-20_10-38-37
all six experiments passed in each run set, including stm32f103_gpio_no_external_capture_stlink

This is the point where AEL starts to look less like "AI-assisted execution" and more like an AI-reliable engineering system.

📄 Parallel stability closeout 📄 ST-Link recovery skill

ESP32JTAG Native API Milestone — Minimal Instrument Interface Live-Validated (2026-03-19)

ESP32JTAG now has a minimal instrument-level native API on top of the existing backend package.

This layer now explicitly owns:

identify
get_capabilities
get_status
doctor
preflight_probe

Its runtime model now explicitly presents ESP32JTAG as a multi-capability instrument family with subsystem-oriented health domains:

network
gdb_remote
web_api
capture_subsystem
monitor_targets

It is integrated through:

instrument_view
instrument_doctor
native_api_dispatch

Healthy live sample already captured:

esp32jtag_stm32f411 @ 192.168.2.103
ael instruments doctor --id esp32jtag_stm32f411
result: ok = true

Second healthy live sample:

esp32jtag_g431_bench @ 192.168.2.62
ael instruments doctor --id esp32jtag_g431_bench
result: ok = true

Additional healthy live samples:

esp32jtag_rp2040_lab @ 192.168.2.63
esp32jtag_h750_bench @ 192.168.2.106
both returned ok = true

This means ESP32JTAG is now legible both as:

a unified action backend
a named multi-capability instrument interface

📄 ESP32JTAG native API closeout

ESP32 Instrument Backend Milestone — Meter Runtime Path Revalidated (2026-03-19)

After the backend unification work:

esp32_meter action execution is now unified behind the backend package
usb_uart_bridge is package-aligned with the same backend family
esp_remote_jtag is now bounded as a legacy shim instead of a live mixed implementation

This was also revalidated on a real meter-backed runtime path:

esp32c6_gpio_signature_with_meter
instrument: esp32s3_dev_c_meter @ 192.168.4.1:9000
result: PASS
run id: 2026-03-19_10-34-45_esp32c6_devkit_esp32c6_gpio_signature_with_meter

The practical result is that the runtime consumer path still works on real hardware after the meter action path moved behind the unified backend boundary.

Instrument Backend Milestone — ESP32 Meter Consumer Migration and Legacy Backend Cleanup (2026-03-19)

AEL's instrument backend layout is now substantially cleaner and more uniform.

esp32_meter now has unified backend packaging and real consumer-path usage
usb_uart_bridge is now package-aligned with the rest of the backend family
esp_remote_jtag is no longer treated as an active mixed backend; it is now a legacy compatibility shim over:
- esp32_jtag
- esp32_meter

This means the main instrument backend family is now much clearer:

stlink_backend
esp32_jtag
esp32_meter
usb_uart_bridge

And the old overlapping path is now explicitly bounded as legacy:

esp_remote_jtag

STM32 Cross-Instrument Milestone — Shared Test Packs Across ST-Link and ESP32JTAG (2026-03-19)

AEL now has validated dual-instrument support for shared test-pack execution on both:

STM32F103C8T6 Bluepill GPIO Bench
STM32F407 Discovery

The same validation methodology now works across two instrument paths:

ST-Link
ESP32JTAG

This milestone proves that, for the same DUT family and shared test assets, AEL can switch instrument paths without changing the test intent.

STM32F103C8T6 pack family:

shared base pack:
- packs/smoke_stm32f103_gpio_loopbacks_base.json
instrument-specific child packs:
- packs/smoke_stm32f103_gpio_loopbacks_stlink.json
- packs/smoke_stm32f103_gpio_loopbacks_esp32jtag.json

STM32F103C8T6 shared tests validated:

stm32f103_gpio_no_external_capture
stm32f103_uart_loopback_mailbox
stm32f103_spi_mailbox
stm32f103_exti_mailbox
stm32f103_adc_mailbox

STM32F103C8T6 results:

ESP32JTAG + STM32F103C8T6: 5/5 PASS
ST-Link + STM32F103C8T6: 5/5 PASS

STM32F407 mailbox pack family:

shared base pack:
- packs/smoke_stm32f407_mailbox_base.json
instrument-specific child packs:
- packs/smoke_stm32f407_mailbox_stlink.json
- packs/smoke_stm32f407_mailbox_esp32jtag.json

STM32F407 shared test validated:

stm32f407_mailbox

STM32F407 results:

ESP32JTAG + STM32F407: repeated live passes
ST-Link + STM32F407: repeated live passes

What this proves:

shared pack / child-pack structure works on real hardware
the same DUT-side validation assets can run through two instrument paths
instrument-specific execution details can stay in board/child-pack configuration
cross-instrument debug can expose tool-path issues without invalidating shared firmware/test methodology

Key debug conclusion from this milestone sequence:

ST-Link mailbox verify failures on this path were not caused by DUT wiring or loopback logic
the real issue was st-util session semantics in check_mailbox_verify
for skip_attach sessions, disconnect is correct and detach is not

📄 STM32F103 closeout 📄 STM32F103 ST-Link child pack 📄 STM32F103 ESP32JTAG child pack 📄 STM32F407 closeout 📄 STM32F407 ST-Link child pack 📄 STM32F407 ESP32JTAG child pack

STM32F407 Discovery — ST-Link + STM32 board support added (7/7 PASS, 2026-03-18)

AEL completed full bring-up and validation on STM32F407VGT6 Discovery using the onboard ST-Link V2 instrument path (USB → st-util GDB server → SWD).

All 7 tests passed:

mailbox (basic run verification)
timer interrupt (TIM3 at 100ms intervals, 10 interrupts for PASS)
GPIO loopback (PB0 → PB1)
UART loopback (USART2 PD5 → PD6, 115200 8N1)
EXTI trigger (PB8 → PB9, 10 rising edges via SYSCFG routing)
ADC loopback (PC0 → PC1, 12-bit, software-start)
SPI loopback (PB15 MOSI → PB14 MISO, SPI2 master mode 0)

Key notes:

Firmware generated by AI (bare-metal C, direct register access, no HAL). Zero human code written.
Uses monitor reset run after load — st-util leaves target halted without it.
USART2/PD5/PD6 used instead of USART1/PA9/PA10 — onboard ST-Link UART bridge occupies PA9/PA10.
All 5 loopback jumpers placed once; no re-wiring between tests.

📄 Full session record 📄 Smoke pack

STM32H750 — Golden Suite Complete (25/25 PASS)

AEL completed full bring-up, validation, and golden suite certification on STM32H750VBT6 (YD-STM32H750VBT6).

25 tests across 4 stages (verified 2026-03-30):

Stage 0 — Boot gate:

blinky_visual, minimal_runtime_mailbox

Stage 1 — No-wire self-tests:

timer_mailbox, internal_temp, RNG, CRC, WWDG, TIM1-PWM, QSPI flash, PLL1 clock, BDMA, LPTIM, RTC

Stage 2 — Bench wiring loopbacks:

wiring_verify, IWDG, EXTI, UART loopback, SPI loopback, UART DMA, FDCAN loopback, I2C loopback

Stage 3 — Mixed-signal:

gpio_loopback, pwm_capture, adc_dac_loopback

Wiring: PB8↔PB9, PA9↔PA10, PA4→PA0, PB4↔PB5, PB6↔PB10, PB7↔PB11

👉 First full autonomous bring-up on STM32H7-class MCU. Golden pack certified.

📄 Full postmortem 📄 Golden pack

STM32G431 — Golden Suite Complete (9/9 PASS)

AEL completed full bring-up and golden suite certification on STM32G431CBU6.

All tests passed:

minimal_runtime_mailbox
gpio_signature
uart_loopback
spi
adc
capture
exti
gpio_loopback
pwm

Key fixes during bring-up:

SPI: CR2.FRXTH=1 required to lower RXNE threshold to 8-bit (G4 FIFO, not present on F4)
ADC: ADC12_CCR.CKMODE=01 required to select synchronous clock (async default needs PLL)

👉 First board to use the minimal_runtime_mailbox Step 0 debug-path gate as part of the pack.

📄 Full postmortem 📄 Golden pack

STM32F411 / STM32F401 — Golden Suite Complete (8/8 PASS)

AEL completed full bring-up and golden suite certification on both STM32F4-family boards.

STM32F411CEU6 (Black Pill) and STM32F401RCT6 — 8 experiments each:

gpio_signature
uart_loopback
spi
adc
capture
exti
gpio_loopback
pwm

These boards established the reference bring-up template used for all subsequent targets.

📄 STM32F411 board doc 📄 STM32F401 board doc 📄 F411 golden pack | 📄 F401 golden pack

STM32F407 Discovery — Smoke Pack Baseline (7/7 PASS, ST-Link)

AEL includes a fully validated STM32F407 Discovery smoke pack using ST-Link (st-util).

Run:

python3 -m ael pack --pack packs/smoke_stm32f407.json --board stm32f407_discovery

Coverage — 7 tests:

mailbox (basic run verification)
timer interrupt (TIM3)
GPIO loopback (PB0 → PB1)
UART loopback (USART2 PD5 → PD6)
EXTI trigger (PB8 → PB9)
ADC loopback (PC0 → PC1)
SPI loopback (PB15 → PB14)

Wiring:

PB0  -> PB1
PD5  -> PD6
PB8  -> PB9
PC0  -> PC1
PB15 -> PB14

Notes:

On STM32F4 Discovery, avoid PA9/PA10 for UART loopback — the onboard ST-Link UART bridge circuit causes interference. Use USART2 PD5/PD6 instead.
When using st-util, GDB load does not start execution automatically. The board config includes monitor reset run to handle this.

This pack is fully validated (7/7 PASS) and serves as the regression baseline for STM32F407 + ST-Link in AEL.

📄 Baseline document 📄 Smoke pack

STM32U585 — Bring-up In Progress

AEL is currently bringing up the STM32U585CIU6 (WeAct CoreBoard), an STM32U5-class ultra-low-power MCU with TrustZone.

Status: In progress — firmware and test plan framework ready, validation running.

Planned coverage (21 tests): blinky, minimal_runtime, timer, UID, RNG, CRC, CORDIC, ADC temp/vref, DAC+ADC, GPIO loopback, UART loopback, SPI loopback, I2C loopback, EXTI, IWDG, PWM capture, button idle, ADC drive

What AEL can do

AEL can automatically:

✔️ Generate firmware ✔️ Install toolchains (if missing) ✔️ Build projects ✔️ Flash target MCUs ✔️ Monitor UART logs ✔️ Detect crashes (panic / watchdog / reboot loops) ✔️ Capture and verify GPIO signals

All as part of a single automated pipeline.

Why AEL?

Embedded development still relies heavily on manual iteration:

build → flash → observe → debug → repeat

AEL closes this loop using:

AI-assisted project generation
automated build & flash
runtime monitoring
hardware signal verification

And it works on real hardware, not simulations.

How it works (Simplified)

Human → Orchestrator → Instrument → DUT (Target MCU)

Where:

Orchestrator orchestrates the workflow and makes decisions
Instrument provides debug access and signal capture
DUT runs real firmware and produces observable behavior

Example

Imagine:

You have an STM32 board
Its SWD is connected to an Instrument that supports Cortex MCU flash
Its GPIOs P4–P7 are connected to capture inputs

You tell AEL:

Generate firmware that outputs four different frequencies on P4–P7, build it, flash it, run it, and verify the signals are present.

AEL will:

Generate firmware
Build it
Flash the target
Run it
Capture signal behavior
Validate the result
Report PASS / FAIL

No manual intervention required.

Reference Instrument: ESP32JTAG

AEL works with programmable Instruments that provide:

debug access
signal capture
runtime monitoring

Today, ESP32JTAG serves as the first fully-supported Instrument.

It enables AEL to:

flash firmware
capture GPIO signals
monitor UART output
verify real hardware behavior

AEL itself is not tied to any specific hardware. ESP32JTAG is simply the first concrete implementation of the AEL Instrument concept.

Try AEL with Two Dev Boards (No Dedicated Hardware Required)

You don't need ESP32JTAG to experience AEL.

A minimal setup uses:

One ESP32-S3 dev board (Instrument)
One RP2040 or STM32 or ESP32 dev board (DUT)

Total cost: under $20–$30.

The first board is a WiFi-based signal instrument that captures signals from the DUT or generates stimulus signals, and communicates with the Orchestrator over WiFi.

This allows AEL to build firmware, flash the target, run code, and verify signal behavior — without specialized hardware.

Example Setup

Connect:

ESP32 GPIO A → RP2040 IN0
ESP32 GPIO B → RP2040 IN1
ESP32 GPIO C → RP2040 IN2
ESP32 GPIO D → RP2040 IN3
GND → GND

Then tell AEL:

Generate firmware with four different output frequencies, build it, flash it, run it, and verify signals.

AEL will compile, flash, run, measure, and validate automatically.

Capability Comparison

Setup	Auto Build	Flash	UART Monitor	Signal Verify
ESP32 only	✔️	✔️	✔️	❌
+ RP2040 / STM32	✔️	✔️	✔️	✔️
ESP32JTAG	✔️	✔️	✔️	✔️ (higher speed & stability)

Some Use Case Examples

Here is an example using ESP32JTAG as Instrument with an RP2040 Pico board:

Another example uses two ESP32-S3 boards — one as Instrument to check GPIO levels, toggling, and target voltage; the other as DUT:

A screenshot showing AEL and Codex running together on Ubuntu:

Supported Targets (v0.1)

RP2040
STM32F103
STM32F411
ESP32-S3

And much more to come.

Golden-Standard Validated MCUs

MCUs that have completed real-hardware validation at AEL's current golden-standard level.

STM32F103C8T6
- validated with shared cross-instrument loopback pack on both ST-Link and ESP32JTAG
STM32F103RCT6
- validated with full 7/7 PASS smoke suite
STM32F401RCT6
- validated with full 8/8 PASS smoke suite
STM32F411CEU6
- validated with full 8/8 PASS smoke suite
STM32F407VGT6
- validated on STM32F407 Discovery
- shared mailbox path validated on both ST-Link and ESP32JTAG
- full 7/7 PASS smoke baseline validated on ST-Link
STM32G431CBU6
- validated with full 9/9 PASS smoke suite
STM32H750VBT6
- validated with full 7/7 PASS smoke suite
RP2040
- full 13/13 PASS Rule-B golden suite via S3JTAG wireless instrument
- covers: mailbox, internal temp, timer, GPIO levels, GPIO frequency, PWM, GPIO interrupt, UART, SPI, ADC
ESP32-C6
- validated in current AEL verified-board baseline
ESP32-C5
- full 12/12 PASS Rule-B golden suite
ESP32-C3
- validated in current AEL verified-board baseline
ESP32-S3
- validated in current AEL verified-board baseline
ESP32-WROOM-32D
- validated in current AEL verified-board baseline

Verified Boards

Boards that have completed full bring-up and sequential verification on real hardware.

Board	MCU	Family	Experiments	Status	Doc
STM32F103 GPIO Bench	STM32F103C8T6	STM32F1	5	verified (ST-Link + ESP32JTAG)	docs/stm32f103_gpio_cross_instrument_closeout_2026-03-19.md
STM32F103RCT6 board	STM32F103RCT6	STM32F1	7	verified	docs/boards/stm32f103rct6.md
STM32F407 Discovery	STM32F407VGT6	STM32F4	7	verified (ST-Link baseline + dual-instrument mailbox)	docs/methodology/smoke_stm32f407_baseline_v0_1.md
STM32F411CEU6 (Black Pill)	STM32F411	STM32F4	8	verified	docs/boards/stm32f411ceu6.md
STM32F401RCT6	STM32F401	STM32F4	8	verified	docs/boards/stm32f401rct6.md
STM32G431CBU6	STM32G431CBU6	STM32G4	9	verified	docs/methodology/stm32g431_milestone_postmortem_v0_1.md
STM32H750VBT6 YD	STM32H750VBT6	STM32H7	7	verified	docs/methodology/stm32h750_milestone_postmortem_v0_1.md
RP2040 Pico (S3JTAG)	RP2040	RP2	13	verified (Rule-B, S3JTAG wireless)	docs/rp2040_s3jtag_full_suite_closeout_2026-03-26.md
ESP32-WROOM-32D	ESP32	ESP32	Rule-B	verified	docs/reports/esp32_wroom32d_rule_b_closeout_2026-03-25.md
ESP32-C3 DevKit	ESP32-C3	ESP32	Rule-B	verified	docs/reports/esp32c3_devkit_rule_b_closeout_2026-03-26.md
ESP32-C5 DevKit	ESP32-C5	ESP32	12	verified (Rule-B)	docs/reports/esp32c5_devkit_rule_b_closeout_2026-03-26.md
ESP32-C6 DevKit	ESP32-C6	ESP32	Rule-B	verified	docs/reports/esp32c6_devkit_rule_b_closeout_2026-03-25.md
ESP32-S3 DevKit	ESP32-S3	ESP32	Rule-B	verified	docs/reports/esp32s3_devkit_rule_b_closeout_2026-03-26.md
ESP32-C6 DevKit	ESP32-C6	ESP32	—	verified	—

Terminology

An AEL lab consists of four core roles: Orchestrator, DUT, Instrument, Connections.

Orchestrator

The system running AEL software. Typically a PC or server.

Responsible for:

orchestration and decision making
build & flash control
verification logic

DUT (Device Under Test)

The target system being developed or verified.

Examples:

STM32 board
RP2040 Pico
ESP32-S3 target

Runs firmware and produces behavior.

Instrument

A device that interacts with the DUT.

Instruments provide capabilities such as:

debug access (SWD / JTAG)
signal capture and generation
UART monitoring
measurement

Examples:

ESP32JTAG
RP2040 USB GPIO meter
ESP32-S3 dev board (DIY instrument)
External lab equipment

Connections

Defines how DUTs are wired to Instruments.

Examples:

SWD → Instrument Port P3
DUT GPIO P4 → Capture IN0

Connections make automation reproducible.

Together:

Orchestrator → Instruments → Connections → DUTs

For AI Agents

See docs/AI_USAGE_RULES.md for CLI design rules and deterministic execution guidance.

Latest Runs Helper

Use the helper script to quickly view the newest run folders and key logs:

tools/show_latest_runs.sh
tools/show_latest_runs.sh 3

It prints:

latest run directories
run status (ok / fail)
key log paths (preflight.log, build.log, flash.log, verify.log)

Workspace Cleanup

Use cleanup scripts to remove generated runs, artifacts, queue entries, reports, and cache files.

# Remove everything generated by AEL in this repo
tools/cleanup_workspce --full

# Preview what would be removed
tools/cleanup_workspce --full --dry-run

# Remove only entries older than a cutoff date/time
tools/cleanup_workspce 2026-03-06_15-10-59
tools/cleanup_workspce 2026-03-06

Notes:

tools/cleanup_workspce is the compatibility alias (kept for existing usage).
tools/cleanup_workspace is the canonical wrapper.
.gitkeep placeholder files are preserved.

Board Golden Test Suite Summary

Last updated: 2026-03-28 — full audit report: docs/reports/stm32_golden_suite_inventory_2026-03-28.md

┌───────────────────────────────┬────────┬───────────┬───────┬────────────┬────────────────────────────────────────────────────────────────┐
│             Board             │ Family │ Lifecycle │ Tests │  Verified  │                            Pack(s)                             │
├───────────────────────────────┼────────┼───────────┼───────┼────────────┼────────────────────────────────────────────────────────────────┤
│ stm32f103_gpio                │ F1     │ golden    │ 6     │ 2026-03-13 │ smoke_stm32, smoke_stm32f103_gpio_loopbacks_esp32jtag          │
├───────────────────────────────┼────────┼───────────┼───────┼────────────┼────────────────────────────────────────────────────────────────┤
│ stm32f103_gpio_stlink         │ F1     │ —         │ 6     │ —          │ smoke_stm32f103_gpio_loopbacks_stlink                          │
├───────────────────────────────┼────────┼───────────┼───────┼────────────┼────────────────────────────────────────────────────────────────┤
│ stm32f103c6t6_bluepill_like   │ F1     │ —         │ 2     │ —          │ smoke_stm32f103c6_minimal                                      │
├───────────────────────────────┼────────┼───────────┼───────┼────────────┼────────────────────────────────────────────────────────────────┤
│ stm32f103rct6                 │ F1     │ draft     │ 7     │ —          │ smoke_stm32f103rct6, smoke_stm32f103rct6_mailbox_esp32jtag     │
├───────────────────────────────┼────────┼───────────┼───────┼────────────┼────────────────────────────────────────────────────────────────┤
│ stm32f103rct6_stlink          │ F1     │ —         │ 7     │ —          │ smoke_stm32f103rct6_stlink, smoke_stm32f103rct6_mailbox_stlink │
├───────────────────────────────┼────────┼───────────┼───────┼────────────┼────────────────────────────────────────────────────────────────┤
│ stm32f401ce_blackpill         │ F4     │ —         │ 1     │ —          │ none (draft)                                                   │
├───────────────────────────────┼────────┼───────────┼───────┼────────────┼────────────────────────────────────────────────────────────────┤
│ stm32f401rct6                 │ F4     │ golden    │ 13    │ 2026-03-15 │ smoke_stm32f401, stage0, stage0_mailbox, stage1                │
├───────────────────────────────┼────────┼───────────┼───────┼────────────┼────────────────────────────────────────────────────────────────┤
│ stm32f407_discovery           │ F4     │ golden    │ 7     │ 2026-03-18 │ smoke_stm32f407, smoke_stm32f407_mailbox_stlink                │
├───────────────────────────────┼────────┼───────────┼───────┼────────────┼────────────────────────────────────────────────────────────────┤
│ stm32f407_discovery_esp32jtag │ F4     │ —         │ 1     │ —          │ smoke_stm32f407_mailbox_esp32jtag                              │
├───────────────────────────────┼────────┼───────────┼───────┼────────────┼────────────────────────────────────────────────────────────────┤
│ stm32f411ceu6                 │ F4     │ golden    │ 8     │ 2026-03-14 │ smoke_stm32f411, stm32f411_full_suite                          │
├───────────────────────────────┼────────┼───────────┼───────┼────────────┼────────────────────────────────────────────────────────────────┤
│ stm32g431cbu6                 │ G4     │ golden    │ 10    │ 2026-03-16 │ smoke_stm32g431                                                │
├───────────────────────────────┼────────┼───────────┼───────┼────────────┼────────────────────────────────────────────────────────────────┤
│ stm32h750vbt6                 │ H7     │ golden    │ 7     │ 2026-03-16 │ smoke_stm32h750                                                │
├───────────────────────────────┼────────┼───────────┼───────┼────────────┼────────────────────────────────────────────────────────────────┤
│ nrf52840_nicenano             │ nRF52  │ golden    │ 15    │ 2026-04-12 │ nrf52840_nicenano_golden                                       │
└───────────────────────────────┴────────┴───────────┴───────┴────────────┴────────────────────────────────────────────────────────────────┘

13 boards · 90 test entries — refactoring ongoing, priority: stm32f401rct6 (pack consolidation) and stm32f103c6t6_bluepill_like (golden promotion).

Status

Early stage but actively used in daily development.

Feedback and contributions are welcome.

License

AEL is released under the Apache 2.0 License.

You are free to:

use it in personal projects
integrate it into commercial products
extend it for internal tooling

Third-party components and vendor code remain under their respective original licenses.

Name		Name	Last commit message	Last commit date
Latest commit History 1,187 Commits
.claude		.claude
ael		ael
ael_controlplane		ael_controlplane
artifacts/runs		artifacts/runs
assets_branch		assets_branch
assets_golden		assets_golden
assets_user		assets_user
configs		configs
docs		docs
experiments		experiments
firmware		firmware
instruments/STLinkInstrument		instruments/STLinkInstrument
packs		packs
progress		progress
projects		projects
queue		queue
reference/instrument_reference		reference/instrument_reference
reports		reports
skills		skills
templates		templates
tests		tests
third_party		third_party
tools		tools
workflow_archive		workflow_archive
.gitignore		.gitignore
.gitmodules		.gitmodules
AEL_CONCEPTS.md		AEL_CONCEPTS.md
AGENTS.md		AGENTS.md
CLAUDE.md		CLAUDE.md
GEMINI.md		GEMINI.md
README.md		README.md

Folders and files

Latest commit

History

Repository files navigation

AEL — AI-Driven Embedded Engineering

🚀 What is AEL?

🚀 Installation and Getting Started

Hardware

From "debug probe" → to "AI instrument"

Why this matters

🤖 Natural-Language-First Usage

Example 1: New Hardware Bring-up

Example 2: Feature Validation

Example 3: Debugging

🚀 Latest Milestones

CH32V203C8T6 + CH32V305RBT6 — Dual WCH RISC-V Golden Suites Complete (2026-04-12)

CH32V203C8T6 (nanoCH32V203) — 23/23 PASS

CH32V305RBT6 (nanoCH32V305) — 25/25 PASS

nRF52840 nice!nano v1 — First Nordic + Zephyr Golden Suite: 15/15 PASS (2026-04-12)

CH32V003F4U6 — First RISC-V Board Validated with AEL: 14/14 PASS (2026-04-06)

Zephyr + FreeRTOS — Three-Board RTOS Coverage Complete (2026-04-05)

STM32H563RGT6 — Deepest Cortex-M33 Golden Suite: 46/46 PASS via DAPLink (2026-04-05)

STM32F103C6T6 — Blue Pill Golden Suite: 24/24 PASS via ESP32JTAG (2026-04-01)

STM32F407VET6 — Deepest Cortex-M4 Golden Suite: 21/21 PASS via ESP32JTAG (2026-04-01)

STM32 + DAPLink Milestone — AEL Brings Up CMSIS-DAP on Linux and Completes STM32F103RCT6 Golden Suite (2026-03-31)

AMD(Xilinx) Artix XC7A35T — Closed-Loop FPGA Verification via ESP32JTAG LA (2026-03-27)

The first FPGA milestone is complete: AEL can now take over, modify, build, program, instrument, and verify a Xilinx FPGA project on real hardware!

Brownfield Embedded Project — AEL Drives a Real Firmware Project to Open-Source Release (2026-03-27)

RP2040 Pico + S3JTAG — Full Rule-B Golden Suite Validated (2026-03-26 / 2026-03-27)

ESP32 Family Golden Suite Coverage — Major ESP32 Series Validated (2026-03-26)

AEL Experience System v0.1 — Record, Reuse, and Grow from Engineering Experience (2026-03-22)

Schema Convergence Milestone — Default Verification Reached Parallel Stable Closure (2026-03-20)

ESP32JTAG Native API Milestone — Minimal Instrument Interface Live-Validated (2026-03-19)

ESP32 Instrument Backend Milestone — Meter Runtime Path Revalidated (2026-03-19)

Instrument Backend Milestone — ESP32 Meter Consumer Migration and Legacy Backend Cleanup (2026-03-19)

STM32 Cross-Instrument Milestone — Shared Test Packs Across ST-Link and ESP32JTAG (2026-03-19)

STM32F407 Discovery — ST-Link + STM32 board support added (7/7 PASS, 2026-03-18)

STM32H750 — Golden Suite Complete (25/25 PASS)

STM32G431 — Golden Suite Complete (9/9 PASS)

STM32F411 / STM32F401 — Golden Suite Complete (8/8 PASS)

STM32F407 Discovery — Smoke Pack Baseline (7/7 PASS, ST-Link)

STM32U585 — Bring-up In Progress

What AEL can do

Why AEL?

How it works (Simplified)

Example

Reference Instrument: ESP32JTAG

Try AEL with Two Dev Boards (No Dedicated Hardware Required)

Example Setup

Capability Comparison

Some Use Case Examples

Supported Targets (v0.1)

Golden-Standard Validated MCUs

Verified Boards

Terminology

Orchestrator

DUT (Device Under Test)

Instrument

Connections

Together:

For AI Agents

Latest Runs Helper

Workspace Cleanup

Board Golden Test Suite Summary

Status

License

About

Resources

Uh oh!

Stars

Watchers

Forks

Releases

Packages 0

Uh oh!

Contributors

Uh oh!

Languages

STM32 + DAPLink Milestone — AEL Brings Up CMSIS-DAP on Linux and Completes `STM32F103RCT6` Golden Suite (2026-03-31)

Packages