Nasa cFS hardware requirements on Cubesat

[andreazann]

Hello everyone,

my Team and I are contributing developing a Cubesat as part of a university project. We are now in the process of choosing the OBC and regarding the framework we wanted to opt for the Nasa cFS. But we are unsure if the OBCs under review qualify for the hardware requirements in order for the cFS to run smoothly. Just to make a rough idea we have to manage 2 payloads and 4 subsystems.

The OBCs are:

ISIS OBC
CPU - 400MHz, 32-bit ARM9 (AT91SAM9G20)
RAM - 16MB or 32MB SDRAM
Code storage - 1MB NOR-flash
Non-volatile data storage - 2x2GB SD-Cards with FAT32 file system, 256kB FRAM (high endurance and fast read/writes)

NanoAvionics SatBus3C2
CPU - Cortex-M7 core, clock speed up to 400 MHz (configurable), 200 MHz typical
RAM - 1 MB of integrated RAM
Code storage - 2 MB of integrated FLASH memory, 2×512 kB of FMC-connected FRAM memory
Non-volatile data storage - 256 MB of external NOR-FLASH for data storage (2 × two die (64 MB each) chips, QSPI), 2×512 kB of FRAM (SPI) for frequently changing data storage

Do they both qualify to run the cFS without expecting memory or computational power issues?
Is one of the two OBCs much more recommendable than the other when using the cFS?

If needed I can attach the datasheets from the respective OBCs.

[jphickey]

Most of CFS system requirements depend on your specific usage, that is - the collection of apps you plan on running, and your various time budgets.

The CFE framework itself should fit onto those without much fuss, as long as the cortex M7 has a 32-bit word size it should be OK (there are some assumptions/expectation that "int" will be 32 bits and be atomic, which may not be true on smaller microcontrollers).

You may have to prune down some stuff to fit into 16MB of RAM, but it shouldn't be hard - some users have fit it into RAM sizes as small as 2MB.

But I'll reiterate, that's just CFE as a baseline, the apps you choose will all get added to this baseline.

I'd recommend compiling the collection of apps you plan on running initially for Linux (via SIMULATION=native) to get a better idea of the respective code and data sizes. If you are planning on using an RTOS like RTEMS, then you can also run that in an emulator like QEMU, which you can also set to reflect your planned RAM size and also emulate the slower CPU speed, to get a better feel/estimation for how much overhead you might have.

[ghost]

I agree with what @jphickey said above. Here are a few notes:
ISIS OBC
CPU - 400MHz, 32-bit ARM9 (AT91SAM9G20) - This should be more than enough performance
RAM - 16MB or 32MB SDRAM - With an RTOS 16MB would work
Code storage - 1MB NOR-flash - You may struggle to fit the RTOS image + cFS + Mission apps in 1MB
Non-volatile data storage - 2x2GB SD-Cards with FAT32 file system, 256kB FRAM (high endurance and fast read/writes)
The SD cards can be used to load cFS and/or apps
Does this board use FreeRTOS? - this has been done but is not in the open source repositories, so factor that work in.
For code storage, if you can somehow dynamically load the cFS and/or cFS apps at boot time, then you can have the OS/firmware image in the 1MB flash, and the cFS artifacts on the SD cards. Depending on how the firmware works, you may be able to create a compressed image with the RTOS+cFS+Mission Apps that fits in the 1MB flash.

From what I recall, we had a FreeRTOS based satellite with 2MB of flash - the combined FreeRTOS + Drivers + cFS + Some apps is a little over 1MB.

For the NanoAvionics SatBus3C2, I would not recommend using cFS - You will need to do too many hacks/modifications to get that to work

Alan

[andreazann]

Thank you both @jphickey and @acudmore for your detailed answers.

• Regarding loading cFS and/or apps from SD cards, is it considered safe practice? One thing that pops to mind is that SD cards could unmount for whatever unexpected reason on the satellite, wouldn't it be dangerous to have the cFS on it?

• Based on your analysis and other requirements from our mission we're going to choose the ISIS OBC, which only supports FreeRTOS and Kubos Linux. Is there a FreeRTOS OSAL written for cFS? Unfortunately we're finding it difficult to obtain references or resources for it online

[ghost]

Sorry for the late reply..
SD card use is a risk that has to be weighed by the mission. I personally experience SD card failures occasionally on Raspberry Pis, and I would be inclined not to use one for critical functions. Doesn't one of the OBCs have redundant SD cards? That may help.

For the FreeRTOS OSAL implementation, I don't believe there Is an up to date one. The most recent port I am aware of is here:
https://github.com/METECS/OSAL-PC-FreeRTOS