Firmware & System Architecture

03. Firmware & System Architecture

This section provides a detailed breakdown of the FlatSat v1.0 firmware infrastructure, its dual-core task distribution, the non-blocking worker architecture, and maintenance status indicators.

---

Asymmetric Multiprocessing (AMP) Architecture

The firmware utilizes an Asymmetric Multiprocessing (AMP) approach on the Raspberry Pi RP2040 microcontroller. By splitting tasks across two separate cores, the system ensures that high-speed data links do not interfere with time-critical radio or flight operations.

Dual-Core Task Distribution

• Core 0 (Flight Operations & RF): Manages the physical radio interfaces (Uplink/Downlink), sensor data acquisition loops, and the primary telemetry state machine.
• Core 1 (OBC Data Link): Dedicated entirely to running the TinyUSB stack, handling the usbCDC interface. This provides a high-speed command-and-control link for the On-Board Computer (OBC) or ground station simulation.

Note: The OBC Data Link on Core 1 acts as a backup or alternative interface in case you do not have access to a Software Defined Radio (SDR) device to collect and send packets over the air.

---

Subsystem Logic & Non-Blocking Workers

The firmware operates as a continuous, non-blocking state machine governed by the telemetryRadioWorker routing.

The Telemetry Worker

To maintain system responsiveness and handle simultaneous tasks without freezing execution, the firmware avoids the use of standard blocking delay() functions. Instead, the worker utilizes a timeout_worker_t structure to track precise temporal intervals.

This enables the system to remain continuously responsive to incoming ground commands while concurrently managing multiple periodic tasks at different schedules:

• Sensor Telemetry: Triggered every 10.5 seconds.
• Sync / Ping: Triggered every 15 seconds.
• Idle Frame: Triggered every 20 seconds.

Command Processing Flow

When an interaction occurs, data passes through the following internal pipeline:

1. Ingress: Data arrives via Radio 0 (over the air) or the USB CDC link (Core 1 bridge).
2. Unpacking: The spp_unpack_packet routine validates the CCSDS space header, checking for version consistency and length parameters.
3. Dispatch: The internal commandApidHandler matches the extracted Application Process Identifier (APID) to its corresponding subsystem function.
4. Execution: The targeted subsystem (e.g., thruster.cpp) updates its internal state registers.
5. Feedback: The system generates a Telemetry (TM) frame response or blinks the onboard LED to confirm successful command execution.

---

Hardware Hacking Foundations: The Flash Worker

An educational feature designed specifically for auditing and tracking data transfer routines is the telemetrySPPTransmitFlash routine. This subsystem simulates the transfer of a firmware image or large data block over a constrained link by fragmenting it into smaller chunks:

• Fragmentation: Large data blocks are split into sequential 16-byte segments.
• Sequencing: Packets are individually marked with START, CONTINUE, or END segmentation flags within the Space Packet Protocol (SPP) primary header.
• Integrity: A custom crc8_compute routine is applied to each chunk to ensure data was not corrupted during RF transit.

---

Maintenance & Status Indicators

The firmware drives the onboard WS2812B NeoPixel LED (connected to GPIO 15) to provide real-time operational status without requiring an open serial monitor connection. The visual patterns programmed into the system firmware are:

LED Color	Pattern	Meaning
White	Single Blink	Successful Downlink Transmission
Blue	Single Blink	Successful Uplink Reception
Yellow	8 Blinks	SPP Unpacking / Parsing Error
Red	8 Blinks	Hardware Interface / Radio Failure
Red / Yellow	Alternating Blinks	System Watchdog Reboot Initiated