ASCENT R3 — Dual-MCU Flight Computer

ASCENT R3 is a custom avionics board and firmware monorepo built around two cooperating microcontrollers: the Flight Management Unit (FMU) and the Telemetry and Data Unit (TDU). High-rate flight processing stays on the ESP32-S3; Sub-GHz radio, local feedback, and supporting board interfaces run on the STM32WLE5JC (Seeed Wio-E5). Shared pin maps and hardware definitions live in one repository; each MCU has an independent firmware build.

Not flight-certified. See SAFETY.md and DISCLAIMER.md before hardware use. License and security reporting: LICENSE.md, SECURITY.md, CODE_OF_CONDUCT.md.

Architecture

Unit	Processor	Role
FMU	ESP32-S3	Flight sensing, logging, storage, and flight-event interfaces
TDU	STM32WLE5JC (Wio-E5)	Sub-GHz LoRa, local LED/buzzer, GNSS-facing UART, recovery support

• Root CMakeLists.txt / ESP-IDF builds the FMU only.
• tdu/CMakeLists.txt is a standalone ARM GCC / CMake project (Ninja Debug and Release presets). It is not an ESP-IDF component.
• Physical drivers live under drivers/; portable device behavior and opt-in TDU hardware diagnostics live under components/devices/.
• Pin assignments: board/ascent_fmu_pinmap.h, board/ascent_tdu_pinmap.h.

Path	Purpose
fmu/	ESP32-S3 application entry
tdu/	STM32WLE5 standalone firmware, CubeMX .ioc, linker script
board/	FMU and TDU pin maps
hal/	ESP32 and STM32WL HAL / interface layers
drivers/	Device drivers (IMU, baro, GNSS, WS2812, DRV8210, STM32WL radio, …)
components/	Higher-level device policy, portable APIs, TDU diagnostics
scripts/	Host bring-up helpers (e.g. SWD identify)
docs/images/	Board photographs

Hardware

ASCENT R3 PCB

Hardware overview

Inter-MCU UART (115200 8N1)

Direction	Path	Status
TDU → FMU	STM32 PB6 USART1_TX → ESP32 GPIO41 UART2 RX	Verified (ASCII heartbeat)
FMU → TDU	ESP32 GPIO42 TX → STM32 PB7 USART1_RX	Not yet validated

STM32 NRST

ESP32 GPIO21 drives STM32 NRST. An external 10 kΩ pull-down holds the STM32 in reset until the FMU drives GPIO21 HIGH. High-Z on GPIO21 is not a release. Do not fight a push-pull HIGH with an external NRST driver pulled LOW.

Verified hardware bring-up

The following have been exercised on ASCENT R3 hardware (bench / lab). Opt-in diagnostics are default OFF and are not part of normal Release images.

FMU

• Boot at 240 MHz with 2 MiB PSRAM
• IMU / barometer SPI bring-up
• GNSS UART and SAM-M10Q configuration / driver paths
• microSD (SDMMC) and external NOR flash bring-up — distinguish ordinary read/write checks from any opt-in destructive storage validation
• Opt-in STM32 NRST hold / pulse control for SWD access

TDU

• Independent ARM GCC Debug and Release ELF builds
• SWD program / verify after an intentional RDP Level 1 → Level 0 unlock (factory Wio-E5 AT image was mass-erased; the programmed unit runs custom firmware at RDP Level 0)
• MSI 48 MHz system clock path and FMU-controlled NRST release
• USART1 PB6 → FMU GPIO41 heartbeat at 115200 8N1
• WS2812 on PB3 via the production DWT GPIO bit-bang driver
• DRV8210 buzzer driver and opt-in audible diagnostics (no SPL / current / acoustic characterization claimed)
• Sub-GHz radio init, TCXO / OpError recovery path, LoRa RX, LoRa TX, and half-duplex Stage 3A PING/PONG against PASTA (see below)

Radio stages above are diagnostic bring-up, not a production telemetry service (no scheduling, framing stack, or flight link reliability yet).

Actual RF test evidence (ASCENT ↔ PASTA)

Bench half-duplex exchange at 915 MHz, LoRa SF7 / BW125 kHz / CR4/5, CRC on, explicit header. ASCENT requested TX power +2 dBm (not a calibrated / measured conducted power claim).

Observation	Value
PASTA PING at ASCENT	−30 dBm RSSI, +12 dB SNR
ASCENT PONG at PASTA	−51 dBm RSSI, +9.25 dB SNR
Round-trip time	280 ms

This demonstrates bidirectional half-duplex packet exchange on the configured channel. It does not prove simultaneous full-duplex operation, flight-range performance, or long-range characterization. 433 MHz operation has not been demonstrated.

Outstanding work

• FMU GPIO42 → TDU PB7 UART receive path not yet validated
• Inter-MCU binary protocol / command and telemetry service not implemented
• Production radio scheduling, packet framing, reliability, and telemetry integration still pending
• TDU GNSS UART and remaining auxiliary GPIOs need final verification where applicable
• Long-range RF characterization (and any planned 433 MHz use) not yet shown
• No flight certification implied

Detailed TDU diagnostics, caveats, and CubeMX regeneration notes: tdu/README.md.

Build

FMU (ESP-IDF 6.1)

From the repository root, with ESP-IDF exported:

idf.py build
idf.py -p <SERIAL_PORT> flash monitor

Opt-in FMU diagnostics (default OFF) and other sensor test flags are documented in the root CMakeLists.txt. Example TDU reset helpers:

idf.py -DASCENT_TDU_RESET_HOLD=ON build
idf.py -DASCENT_TDU_UART_RX_TEST=ON -DASCENT_UART_HAL_TEST=OFF build

TDU (ARM GCC / CMake)

Independent of ESP-IDF. Requires CMake 3.22+, Ninja, and arm-none-eabi-gcc (with newlib / nano.specs).

cmake --preset Debug -S tdu
cmake --build tdu/build/Debug

cmake --preset Release -S tdu
cmake --build tdu/build/Release

Expected outputs: tdu/build/Debug/ascent-r3-tdu.elf and tdu/build/Release/ascent-r3-tdu.elf. Default configurations leave all ASCENT_TDU_* hardware diagnostics OFF. See tdu/README.md for opt-in diagnostic flags.

Continuous integration

.gitea/workflows/build.yml runs two independent jobs on push, pull request, and workflow_dispatch:

Job	Name	What it builds
build-fmu	ESP32-S3 FMU Build	ESP-IDF v6.1 image; root firmware
build-tdu	STM32WLE5 TDU Build	Ubuntu 24.04 + apt ARM GCC; TDU Debug and Release

Jobs do not flash hardware and do not enable diagnostic-only firmware flags.

ST-LINK SWD (identify / program)

On this PCB, FMU GPIO21 owns STM32 NRST. Prefer HotPlug with NRST released. Identify success reports Device ID 0x497. Host helpers such as scripts/stm32_swd_capture.ps1 are identify-oriented; do not casually raise RDP or rewrite option bytes on field units.

Project notes

Personally maintained development project. It is not flight-certified. Practices and licensing: CODE_OF_CONDUCT.md, CONTRIBUTING.md, LICENSE.md, SECURITY.md.