TFC1 flight tests: BetaFlight on RP2354B

First power-on

The TFC1 boards arrived in mid-March, and the first task was bringing up the hardware with BetaFlight firmware. The approach was methodical: start with the most basic configuration and progressively add peripherals.

Four firmware configurations were built in stages:

1. TFC_RP2354_V1 — Baseline: UART, DEBUG, PWM only. Designed for RP2350A testing
2. TFC_RP2354B_V1 — Same as above, for RP2350B
3. TFC_RP2354B_ICM45686/MPU6000/MPU9250 — Full sensor configurations for each IMU variant
4. TFC_RP2354B_ICM45686_SX1281 — Sensors + built-in ELRS receiver

Since the RP2354B wasn’t yet a native BetaFlight target, we started by using the RP2350x images. The RP2350 and RP2354 differ mainly in internal flash capacity and a few peripheral errata — the core architecture is identical. This gave us a reasonable starting point.

The EEPROM problem

The first major hurdle was a confusing issue: after flashing the firmware, no UART ports appeared in BetaFlight Configurator. Only the USB/CDC port was visible.

The root cause was BetaFlight’s EEPROM configuration system. On PICO platforms, the last 64 KB of internal flash stores configuration data. When the board booted, it loaded whatever UART pin-out configuration was previously written to EEPROM — and the initial flash had none configured.

Unlike STM32 platforms, where the BootLoader supports full chip erase, the PICO’s BootLoader only accepts UF2 files dropped onto the USB mass storage device. There’s no built-in way to clear the configuration section.

The temporary fix was to force an EEPROM reset on every boot:

if (isEEPROMStructureValid()) {
    return;
}
resetEEPROM();

This worked but had the side effect of clearing all flight parameters on each restart. The proper solution would be either a special UF2 to erase the config section or an improved BootLoader — both deferred for now since the full hardware config makes this issue increasingly rare.

PIO-UART limitations

Another discovery: the RP2350B has three PIO (Programmable IO) blocks, but only two IRQ lines available. Each UART requires an RX IRQ, meaning a maximum of two PIO-UART instances can be active simultaneously.

Debug UART had to use hardware UART0 or UART1 — PIO-UART cannot serve as stdio because it initializes too late in the boot sequence. This required reassigning GPIO pins: Debug moved to GPIO20/21 (UART1), while the original UART1 pins (GPIO4/5 for GPS) were shifted to PIO-UART2.

Sensor detection

The MPU6000 on the Waveshare RP2350B-CORE breakout board was detected correctly by the BetaFlight firmware. Subsequent testing confirmed that all three IMU variants (ICM-45686, ICM-42688, MPU-6000) were properly detected by the flight stack.

However, BetaFlight Configurator initially failed to display the ICM-45686 sensor ID — a separate issue related to how the Configurator app resolves sensor names. This was resolved by updating to a newer firmware build where the sensor name list is dynamically queried from the flight controller via CLI, rather than relying on a hardcoded enumeration table.

Building the test aircraft

With the flight controller bring-up complete, the next step was assembly. Components were mounted onto 2S frame builds for initial testing. The TFC1 boards were integrated into the airframe alongside the ESCs, receiver, and power distribution.

BlackBox and telemetry

BetaFlight’s BlackBox logging was configured for UART output. Since the TFC1 doesn’t include an onboard microSD slot, flight data is written to an external device via OpenLog-compatible protocol over UART. This can be an dedicated OpenLog/OpenLager hardware module, or a Raspberry Pi running a lightweight blackbox logger service.

The configuration in BetaFlight Configurator:

set blackbox_device = SERIAL
set blackbox_mode = ALWAYS

Setting blackbox_mode to “ALWAYS” (rather than the default “NORMAL”) enabled continuous logging for ground testing without requiring the drone to be armed and flying.

First flights

The first flight tests confirmed that the TFC1 could successfully run BetaFlight firmware, detect sensors, receive RC input, and control motor output. The RP2354B handled the flight control loops without issue, and the BetaFlight Configurator responded normally for tuning and configuration.

The foundation was solid — the TFC1 was ready for more advanced testing including optical flow integration, GPS positioning, and autonomous flight modes.