fprime
Frameworknasa/fprime
Flight software framework for rapid development of embedded space applications.
Overview
F´ is a component-driven framework developed by NASA JPL for building flight software and embedded systems. It provides modeling tools, a C++ core, and reusable components for small satellites and instruments.
README Preview
A Flight-Proven, Multi-Platform, Open-Source Flight Software Framework\n\n\n\n\n#\nF´ (F Prime) is a component-driven framework that enables rapid development and deployment of spaceflight and other embedded software applications. Originally developed at the [Jet Propulsion Laboratory](https://www.jpl.nasa.gov/), F´ has been successfully deployed on [several space applications](https://fprime.jpl.nasa.gov/overview/projects/). It is tailored but not limited to small-scale spaceflight systems such as CubeSats, SmallSats, and instruments.\n\n**Please Visit the F´ Website:** [https://fprime.jpl.nasa.gov](https://fprime.jpl.nasa.gov/) for more information.\n\n\n## What does F´ provide\n\n- An architecture that decomposes flight software into discrete components with well-defined interfaces\n- A C++ framework that provides core capabilities such as message queues and threads\n- Modeling tools for specifying components and connections and automatically generating code\n- A growing collection of ready-to-use components\n- Testing tools for testing flight software at the unit and integration levels.\n\nLearn more about [F´ key features](https://fprime.jpl.nasa.gov/overview).\n\n\n## System Requirements\n\nThe following system requirements apply to your workstation for developing F´ applications. To see the list of supported platforms on which F´ applications can run on, see [Supported Platforms](./docs/user-manual/framework/supported-platforms.md).\n\n1. Linux, Windows with WSL, or macOS operating system\n\n2. [git](https://git-scm.com/)\n\n3. [Python 3.10+](https://www.python.org/downloads/), [virtual environments](https://docs.python.org/3/library/venv.html), and [PIP](https://pypi.org/project/pip/)\n\n4. [Clang](https://clang.llvm.org/) or [GNU C and C++ compilers](https://gcc.gnu.org/) (e.g. gcc and g++)\n\n\nClick to Expand: How to Verify System Requirements\n\n2. `git --version`\n\n3. `python --version` and `python -m venv -h`. Your system might use an alternate like `
FAQ (5)
TroubleshootingHow to fix unreachable test bodies in F´ Svc/Health unit tests?
Edit Svc/Health/test/ut/HealthTester.cpp. Remove the early return; in warningTlm() so the warning-timeout assertions for ISF-HTH-002 run and verify the expected HLTH_PING_WARN events. Remove the early return; in nominal2CmdsDuringTlm() as well, then account for the HLTH_CHECK_ENABLE events emitted by the disable/enable commands—clear those expected events before the later zero-event assertions. No production code changes are required. Rebuild and run Svc_Health_ut_exe; all 11 tests should pass.
TroubleshootingHow to fix the F´ DpCatalog FATAL assert after STOP_XMIT_CATALOG followed by BUILD_CATALOG when a late fileDone arrives?
This is fixed in F´ PR #5797, merged into devel on 2026-09-30. Update your F´ checkout or dependency to a devel commit containing that PR, then rebuild:
git fetch origin
git merge origin/devel # or rebase/cherry-pick PR #5797 as appropriateThe fix changes stale fileDone handling to use the existing recovery path instead of reaching FW_ASSERT at DpCatalog.cpp:801; it clears the transmit state, completes any waiting command, and emits a warning event.
On affected commits before the fix, serialize the commands as a workaround: after STOP_XMIT_CATALOG, wait for FileDownlink to return the current file’s fileDone(STATUS_OK) before issuing BUILD_CATALOG. Do not use CLEAR_CATALOG followed by BUILD_CATALOG while the previous file is still transmitting, because it triggers the same assert.
TroubleshootingHow do I fix F´ GDS silently stopping downlink/telemetry when using an older dictionary or receiving an unknown packet descriptor?
Upgrade fprime-gds to a release containing the fix from PR #368, or install the patched main branch:
pip install --upgrade fprime-gds
# or, if needed:
pip install "fprime-gds @ git+https://github.com/nasa/fprime-gds.git@main"The failure occurs in Distributor.on_recv: it catches DeserializeException but not EnumMismatchException, so an unknown descriptor kills the receiver thread. On older versions this may appear as ValueError: 65536 is not a valid DataDescType; on v4.4.0 it can fail silently. The patch catches EnumMismatchException, logs a warning, skips the bad packet, and continues processing.
Immediate workaround: use the dictionary generated by the exact deployment build connected to the GDS—do not mix a v4.0.0 dictionary with a v4.4.0 deployment. For packets caused by corruption, upgrading is required because matching dictionaries cannot prevent them.
TroubleshootingHow do I fix fprime-merge-dictionary error "match() missing 1 required positional argument: 'string'" when using --name?
This is a validation bug in the fprime-merge-dictionary CLI: the identifier regex is called without the user-supplied name and uses a prefix match instead of matching the whole string.
Temporary workaround: omit --name; the command then uses the generated deployment name:
fprime-merge-dictionary --output combined.json first.json second.jsonPermanent fix: update fprime-gds to a version containing the fix, or change the name validation in parse_arguments() from a call such as:
re.match(IDENTIFIER_PATTERN)to:
re.fullmatch(IDENTIFIER_PATTERN, args.name)fullmatch ensures valid identifiers such as Combined are accepted, while invalid values such as Combined-extra or Combined\n are rejected before the output file is written.
TroubleshootingHow to fix duplicate or out-of-order TESTCASE numbers in fprime CommandDispatcher unit tests?
In fprime v4.4.1, this is a cosmetic copy-paste error in TEST_CASE traceability labels, not a GoogleTest failure or functional bug. Edit Svc/CmdDispatcher/test/ut/CommandDispatcherTestMain.cpp, keep nominal tests under 102.1.x and off-nominal tests under 102.2.x, and assign unique IDs in source order. One valid renumbering is: change ClearSequenceTracker from 102.1.3 to 102.2.6; change CommandQueueOverflow from the duplicate 102.2.5 to 102.2.7; renumber the existing 102.2.9, 102.2.6, 102.2.7, and 102.2.8 tests to 102.2.8, 102.2.9, 102.2.10, and 102.2.11, respectively. Verify with cd Svc/CmdDispatcher && fprime-util check --ut. Maintainers note these numbering labels are deprecated, so leaving them unchanged does not affect test execution.