Would like to run on my ARM based raspberry pi, the instructions don't seem to detail a means of building for different arch.

Thanks

Some structure definitions that define specific ground commands and telemetry messages use array sizes for strings that are either defined in osconfig.h (e.g. OS_MAX_PATH_LEN) or cfe_platform_cfg.h (e.g. CFE_ES_MAX_APPLICATIONS).

However, by definition, these header files contain parameters that are tunable to the specific CPU. For instance, a resource-constrained CPU may need to reduce CFE_ES_MAX_APPLICATIONS to a small number to save memory. It is therefore problematic to use these values to define messages that serve as a data definition across processors, particularly in a multi-board setup.

External message definitions must be limited to mission-wide configuration parameters only, such as cfe_mission_cfg.h, where all CPUs as well as the ground system will have the same values.

Hi
I'm very new for write .mak file. I checked gcc(5.5.0) manual, found some symbols such as -Wall, -m32, but did not find ix86. Could you tell me how can I find this? Which manual should I reference to? I want to make psp and osal for raspberry or freertos! Thanks
Sincerely

The unit test code uses its own (re-)definitions of the memory pool management structures. Specifically, these structure definitions are duplicated:

• CFE_ES_CDSBlockDesc_t
• CFE_ES_CDSBlockSizeDesc_t
• CFE_ES_CDSPool_t
• BD_t
• BlockSizeDesc_t
• Pool_t

These should not be redefined here. If these ever diverge from the definitions that CFE ES uses, the tests will break.

The definitions should be moved to a header file and #include'ed in both places to ensure that the same definitions are always used.

Since CFE_ES_CalculateCRC() does not modify the data passed into it, the pointer should be declared "const" in the prototype.

This will not affect any existing usage of the function, but it will allow usage in areas where the data is already "const".

By definition, a task's stack memory must be writeable. The stack pointer parameter to CFE_ES_CreateChildTask() is qualified as "const". Although this matches OSAL's Task API, OSAL is wrong too and should be fixed.

See: [https://babelfish.arc.nasa.gov/trac/cfs_osal/ticket/13]

This ticket should be merged into CFE before the OSAL ticket is fixed.

This change will not affect compatibility with prior versions of OSAL because it is OK to pass a non-const pointer for a const parameter (but vice-versa is an error).

You can run the following as a script if you find that easier:

    git clone https://github.com/nasa/cFE.git
    cd CFE/
    git checkout cf6f7a771c52fa97c834e765a6c1cb50205c6df0
    rm -rf osal/
    git clone https://github.com/nasa/osal.git
    cd osal/
    git checkout 7139592f04e47f7522b07b1ef9f84a21393df88a
    cd src/os
    ln -s posix posix-ng
    cd ../../..
    cp -r cfe/cmake/sample_defs/ cfe/sample_defs/
    mkdir build-sim/
    cd build-sim/
    export SIMULATION=native
    cmake -DCMAKE_C_COMPILER=gcc -DENABLE_UNIT_TESTS=TRUE ../cfe

Then it complains about needing a MISSIONCONFIG directory.
When I create an empty directory, x, for that, it complains about x_defs/targets.cmake not existing.
Is there a default mission config that I can use? I want to build this with a custom compiler, but I need a method to build it with gcc first and get unit tests running.

The alternate build system uses CMake and offers several enhancements:

• Completely isolated build tree - No mixing of source files and generated files
• Dynamic application search path, supports "app-store" concept by keeping app repos separate from cFS repos.
• Supports multiple different build configurations from the same source tree
• Includes mechanisms for electronic data sheets (data dictionary) support and Lua functional testing support in the future

When ran on POSIX systems with SystemD, cFE's log doesn't show up on journalctl, the default logging service. It records all stdout by default. A test with a standard hello world C program on infinite loop showed that the stdout wasn't being buffered or detached. Any help would be greatly appreciated

In the current implementation, CFE_TIME_GetReference() uses a lockless version counter that is checked before and after reading the reference time to determine if the time got updated while it is being read.

However, this protection is insufficient for some systems:

• The global needs to be marked "volatile" for this to have any effect. If compiled with optimizations, the optimizer is likely to remove the "redundant" read of the global value therefore defeating the purpose of the loop altogether.
• It does not protect against the reader interrupting the writer and receiving a "half-updated" value. Running the updater at higher priority does not work on multi-core CPUs since the two threads can be concurrently running.

The "L" suffix on an integer literal tells the compiler that it is supposed to be interpreted as a "long" type. However, CFE error constants are supposed to be 32-bit signed integers, which may or may not be the same thing as the system native "long" type.

To be correct, the constants should be defined to be the same as the "int32" OSAL type and the "L" suffix should be removed.

This causes problems on a 64-bit machine where the "long" type is 64 bits.

Hi Flight Software folks!
First off, great to see the project is finally being hosted somewhere other than SourceForge! I noticed that because of all of the documentation present in the repository, GitHub is falsely identifying the project as HTML-based. For my university project's fork of cFE, we edited our .gitattributes to tell GitHub's linguist software to interpret .htm, .html, and .css files in this project as being part of the documentation. This should give the repository the proper language statistics.

Describe the bug
The default makefiles / CMake scripts do not enforce any strict compiler warning flags and do not treat warnings as errors. This means issues like #22 can more easily slip past.

To Reproduce
Building the rc-6.7.0 branch as a "release" (-O3) using the default settings/sample config/makefile wrapper by preparing as:

make SIMULATION=native BUILDTYPE=release prep

Then run make and you do get some warnings, at least when using gcc 7.x and above:

[ 56%] Building C object cfe_core_default_cpu1/CMakeFiles/cfe_core_default_cpu1.dir/src/es/cfe_es_task.c.o
/home/joe/code/cfecfs/github/cfe/fsw/cfe-core/src/es/cfe_es_task.c: In function ‘CFE_ES_TaskInit’:
/home/joe/code/cfecfs/github/cfe/fsw/cfe-core/src/es/cfe_es_task.c:374:64: error: array subscript is below array bounds [-Werror=array-bounds]
        strncat(EventBuffer, VersionBuffer, sizeof(EventBuffer)-strlen(EventBuffer-1));
                                                                ^~~~~~~~~~~~~~~~~~~~~
/home/joe/code/cfecfs/github/cfe/fsw/cfe-core/src/es/cfe_es_task.c:380:64: error: array subscript is below array bounds [-Werror=array-bounds]
        strncat(EventBuffer, VersionBuffer, sizeof(EventBuffer)-strlen(EventBuffer-1));
                                                                ^~~~~~~~~~~~~~~~~~~~~

However, the build continues and completes the process with no error results.

Expected behavior
The build should stop, because warnings are problems that need to be resolved. If the build does not stop then it is very easy to not notice these issues.

System observed on:
Ubuntu 18.04 (64-bit), kernel 5.0.0-23-generic, gcc 7.4.0

Reporter Info
Joseph Hickey, Vantage Systems, Inc.

One major improvement that could be made to cFE is the ability to specify which apps to build and which platforms to build for at runtime, instead of by changing the Makefiles. CACTUS has a rudimentary implementation of this (see CACTUS-Mission@bec0b57) so that we can declare THE_APPS as an environment variable. I think it would be a huge improvement to the build process to be able to optionally declare THE_APPS, PSP, BSP, and more at the make command line, i.e.

make THE_APPS="sample_lib sample_app"

Some tricks may need to be done to allow this to propagate to make sub-tasks, as those variables would only be accessible in the Makefile in the directory the command is run.

The CFE build currently contains a 4-part version number, i.e. "6.4.1.0". This version number is is #define'd in a header file and is manually updated with each official release.

However, git and Cmake (see ticket #32) offer additional build information where the current git commitid and most recent tag name are built into a global object that is accessible at runtime. When it is available, this extended build information should be displayed along with the manually updated official version number.

The major benefit here is that it updates automatically with every commit, not just official releases. It also indicates the whether the source code tree has been modified from the pristine version in the commit ("dirty") or not. It is extremely useful to have this information built into the executable in order to verify the correct binary is loaded as well as being able to reproduce running binaries when needed.

In the CFE core apps, many files reference functions and data structures defined in other files. However, the function prototypes or "extern" declarations are not in common header files, but simply put at the top of the C file that uses it.

While this does build, it defeats the type checking done by the compiler.

It is far from ideal because if the real variable type or function prototype ever changes, the linker will still happily link it together even though they might be completely incompatible (or worse, incompatible in a really subtle way).

The only reason to NOT put a declaration in a header file is if it should not be called or referenced by CFS apps, but this can be solved by creating a private CFE core shared header file.

When strict compiler flags are used, there are several instances of unused variables in CFE TIME. These are related to the configuration options (e.g. CFE_TIME_CFG_DEFAULT_TAI) where under some configurations a variable is declared and/or set but not actually used.

The preprocessor macros need to be adjusted such that the variable is not declared unless it is used.

cfe_mission_cfg.h shows a note circa line 49 that 'CCSDS allocates 8 bits for this field in the standard VCDU'. Newer CCSDS versions actually allocate 10-bits for this field - this seems like a minor thing but could potentially have implications elsewhere in the code. Per @acudmore , maybe TO, DS, and CF?

All CFE apps that write a file should prefix that file with a header object defined in FS. Currently they do so on-the-fly by simply memset()'ing the structure to zero and setting a key field.

This should be cleaned up and moved to an InitHeader() call in CFE FS such that if fields need to be added to the header in the future this can be done without having to touch many different places where the header is initialized/written.

While attempting to build this project, the submodule update process fails on GFS_CI.git

Cloning into 'apps/ci'...
Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
fatal: clone of '[email protected]:nasa/CFS_CI.git' into submodule path 'apps/ci' failed

It looks like the recent commit in .gitmodules added new apps and used ssh instead of HTTPS. I presume changing them to the form of

[submodule "apps/to"]
	path = apps/to
	url = https://github.com/nasa/CFS_TO.git
[submodule "apps/ci"]
	path = apps/ci
	url = https://github.com/nasa/CFS_CI.git
[submodule "apps/io_lib"]
	path = apps/io_lib
	url = https://github.com/nasa/CFS_IO_LIB.git

will prevent this issue for others.

One roadblock to turning on strict compiler settings (such as -Werror) with full error checking is that MANY compiler warnings are generated by printf error checking done by gcc.

The full error checking is VERY USEFUL because it verifies that the argument corresponding to each escape code is the right type, e.g. %s has a string, %d has an integer, etc.

The problem is that we are using the OSAL abstractions such as int32 or uint32. For example, on some systems, printf'ing an int32 needs a "%d" and on other systems it needs a "%ld" depending on whether it was typedef'ed as an int or a long. So fixing an error on one platform by changing the escape code in the format string only generates an error on a different platform.

In order to fix this so that it builds without warnings on all platforms, any argument that ultimately gets passed to any C library printf() call needs to be cast to the right fundamental C type, not the abstracted type, at the call to the variadic function.

Note this is really only an issue for variable argument functions since for normal functions the correct type is known and the compiler automatically casts it when possible. But for variadic C library functions this is not possible so we must explicitly ensure that the argument gets converted to the correct type //for the c library//. GCC is nice enough to implement warnings for this when it is mismatched, we should leverage that.

In many places a uint32 is used to store a memory address which breaks horribly on 64-bit architectures.

The new version of OSAL "common_types.h" introduced a "cpuaddr" type to address this -- it is defined as an integer type large enough to store a memory address on the local processor.

This ticket is to replace all uses of a uint32 to store a memory address with the cpuaddr type for better portability. This is a requirement for a native 64-bit build to work.

It would be helpful to construct a small Wiki page corresponding to each Application in cFE giving a quick overview of each.

I suggest including hotlinks on each such page back into the doc
subtree of the specific App for extended documentation -- as clones
will obtain the content of the project sources but do not clone
the Trac wiki.

The RV tool analysis reported several cases of reading/writing shared memory variables without a lock.

The intention behind the code was that the data type being read/written simultaneously here was atomic in nature, thus the parallel access would be safe, as it is not possible to catch an atomic value mid-update.

To be more portable the code should use the C99 type sigatomic_t to ensure that the data type is in fact atomic on the given platform. Currently it is using uint32 which is not guaranteed to be atomic on all platforms.

Calling this "minor" because the uint32 type will be atomic on all the platforms that the code in question is actually used on. There is no bug currently here, this is just to prevent a future bug if this code is expanded to smaller CPUs (microcontrollers) where uint32 is not atomic.

Hi
When I delete all app.so in this fold, then I make clean, make config and make again, there are not any app.so in this fold? Is this right? Thanks!
Sincerely

Certain files are directly #include'ed from the PSP library in the CFE code.

Only the "public" PSP API defined in "psp/fsw/inc" should be directly used by application code. Other files such as those under an architecture-specific PSP (e.g. psp/fsw/pc-linux/inc) should be treated as private data to that particular PSP and NOT be used or called directly from the application. If some value is necessary then a public API should be defined to retrieve it, rather than #including it directly.

Fixing this up will make the build cleaner and more efficient. It will also ensure that application code is portable to ALL PSP's because it does not depend on some value that only one particular PSP provides.

Note there is a corresponding ticket in the PSP to stop using CFE headers as well: [https://babelfish.arc.nasa.gov/trac/cfs_psp/ticket/6].

When both of these tickets are merged in the incremental build process becomes much cleaner and faster.

https://github.com/nasa/CFS_CI
https://github.com/nasa/CFS_TO

All of the cFS messages are currently defined in C structures. As a first step toward moving to "electronic data sheets" to describe the external data format, these need to be slightly modified to better separate the header portion of the structure from the payload portion of the structure.

Currently, message structures are typically defined by reserving a block of space for the header as a uint8 array of size CFE_SB_CMD_HDR_SIZE or CFE_SB_TLM_HDR_SIZE. This approach has several issues:

• Using a fixed-size block assumes only a single type of encapsulation (CCSDS) will ever occur. This may not be the case, as other non-CCSDS encapsulations may be a requirement for some missions.
• The fixed size block is not guaranteed to be properly aligned for a CCSDS header. Since it is declared as a uint8 array, the compiler will not ensure any alignment this structure. It is technically not valid to cast this as a CCSDS header since that contains uint16's.
• This is unlikely to be compatible with electronic data sheets (EDS) no matter what specific implementation is used. Since the definition of the message content (payload) and the message header (CCSDS or other format) will come from different data sheets, it becomes very problematic to have them mixed together like this.

To solve this problem requires a bit of restructuring: instead of declaring the format of the payload directly within the message structure, declare a separate "Payload" structure and define it in there.

This adds one extra layer to the structure tree but will improve flexibility going forward, and it will NOT change the external data format, so compatibility with ground systems is unaffected. It only affects the syntax of code accessing members of the payload structure.

Hi,
Did you close the forum or did we need an authorization to access? Thanks

make config returns the following error:

>>> [PRE-BUILD] GET MISSING HEADER FILES FROM <CFS_MISSION> CORE <<<

mkdir: cannot create directory ‘inc’: File exists
make: *** [cfs_copy_core_incs] Error 1

ls -al

[tdev@localhost cpu1]$ ls -al inc 
-rw-rw-r--. 1 tdev tdev 1353 Sep 26 14:52 inc

file returns

inc: C source, ASCII text

Full output of make config

GSFC Classic Build Version 6.5.0
>>> [PRE-BUILD] VERIFY OSAL CONFIGURED <<<
>>> [PRE-BUILD] GET MISSING HEADER FILES FROM <CFS_APP_SRC>/INC <<<



>>> [ENVS] MAKEFILE ENVIRONMENT VARIABLES <<<

MISSION = CFE_TST
‘/home/tdev/workspace/cFE/apps/inc/sample_lib.h’ -> ‘/home/tdev/workspace/cFE/build/mission_inc/sample_lib.h’

THE_APPS = sample_lib sample_app ci_lab to_lab sch_lab
>>> [PRE-BUILD] GET MISSING HEADER FILES FROM <APP>/PUBLIC_INC <<<
THE_TBLS = 


CFS_MISSION = /home/tdev/workspace/cFE

CFS_MISSION_INC = /home/tdev/workspace/cFE/build/mission_inc
>>> [PRE-BUILD] GET MISSING HEADER FILES FROM <APP>/MISSION_INC <<<
CFS_APP_SRC = /home/tdev/workspace/cFE/apps

CFE_FSW = /home/tdev/workspace/cFE/cfe/fsw
CFE_CORE_SRC = /home/tdev/workspace/cFE/cfe/fsw/cfe-core/src

CFE_CORE_PLATFORM_INC_SRC = cpu1
‘/home/tdev/workspace/cFE/apps/sample_app/fsw/mission_inc/sample_app_perfids.h’ -> ‘/home/tdev/workspace/cFE/build/mission_inc/sample_app_perfids.h’
>>> [PRE-BUILD] GET MISSING HEADER FILES FROM <APP>/PLATFORM_INC <<<
CFE_TOOLS = /home/tdev/workspace/cFE/tools
‘/home/tdev/workspace/cFE/apps/ci_lab/fsw/mission_inc/ci_lab_perfids.h’ -> ‘/home/tdev/workspace/cFE/build/mission_inc/ci_lab_perfids.h’

‘/home/tdev/workspace/cFE/apps/to_lab/fsw/mission_inc/to_lab_perfids.h’ -> ‘/home/tdev/workspace/cFE/build/mission_inc/to_lab_perfids.h’
‘/home/tdev/workspace/cFE/apps/sch_lab/fsw/mission_inc/sch_lab_perfids.h’ -> ‘/home/tdev/workspace/cFE/build/mission_inc/sch_lab_perfids.h’
CFE_PSP_SRC = /home/tdev/workspace/cFE/psp/fsw
OSAL = /home/tdev/workspace/cFE/osal
OSAL_SRC = /home/tdev/workspace/cFE/osal/src/os

BUILD_PATH = .
CFS_EXE = ./exe

CFS_PROM = ./exe/cf
>>> [PRE-BUILD] CREATING MISSING <APP> BUILD DIRECTORIES <<<
CFS_PROM_APPS = ./exe/cf/apps


CFS_RAM = ./exe/ram
>>> [PRE-BUILD] GET MISSING MAKEFILES FROM <APP>/FOR_BUILD <<<


‘/home/tdev/workspace/cFE/apps/sample_lib/fsw/for_build/Makefile’ -> ‘sample_lib/Makefile’
>>> [PRE-BUILD] CREATE MISSING TOOL BUILD DIRECTORIES <<<
‘/home/tdev/workspace/cFE/apps/sample_app/fsw/for_build/Makefile’ -> ‘sample_app/Makefile’

‘/home/tdev/workspace/cFE/apps/ci_lab/fsw/for_build/Makefile’ -> ‘ci_lab/Makefile’
‘/home/tdev/workspace/cFE/apps/to_lab/fsw/for_build/Makefile’ -> ‘to_lab/Makefile’
‘/home/tdev/workspace/cFE/tools/elf2cfetbl/for_build/Makefile’ -> ‘elf2cfetbl/Makefile’
‘/home/tdev/workspace/cFE/apps/sch_lab/fsw/for_build/Makefile’ -> ‘sch_lab/Makefile’

>>> [PRE-BUILD] GET MISSING HEADER FILES FROM <CFS_MISSION> CORE <<<

mkdir: cannot create directory ‘inc’: File exists
make: *** [cfs_copy_core_incs] Error 1

Describe the bug
The function calls strlen as:
strlen(EventBuffer-1)

To Reproduce
This is undefined behavior but probably works by accident most of the time, so long as the byte before EventBuffer is not null. This also generates a compiler warning which somehow was never noticed before in previous reviews of this code (gcc 7.4.0 with -Wall switch)

Expected behavior
It probably was meant to be:
strlen(EventBuffer)-1

System observed on:
Ubuntu 18.04 (64-bit), kernel 5.0.0-23-generic, gcc 7.4.0-1ubuntu1~18.04.1

Reporter Info
Joe Hickey

cfe_es_devsrvr.c and .h appear to be stale/obsolete and not being called or referenced by anything else in cFE.

Furthermore, it should be deprecated anyway since device-support code logically fits better within the PSP. At the cFE layer it should be all hardware-independent code.

If this is correct, these two files should be removed from the build.

cFE refuses to load my custom app. I built it from the sample_app provided, and it compiles correctly. Moreover make realclean && make config && make will create the expected lls_app.so and place them in the expected locations (i.e. build/cpu1/exe/cf/apps/lls_app.so and build/cpu1/exe/lls_app.so). Furthermore, the header of these dynamic libraries confirms that they compiled for the correct target when compared to the other default libraries which load.

Any hint is greatly appreciated as I've been struggling with this issue for several long hours now.

Here's the relevant log:

1980-012-14:03:20.25303 ES Startup: Loading file: /cf/apps/lls_app.so, APP: LLS_APP
1980-012-14:03:20.25304 ES Startup: loading directly:/cf/apps/lls_app.so (LLS_APP) -70028.
1980-012-14:03:20.25322 ES Startup: Could not load cFE application file:/cf/apps/lls_app.so. EC = 0xFFFFFFFF

And the full boot-up log:

CFE_PSP: Default Reset Type = PO
CFE_PSP: Default Reset SubType = 1
CFE_PSP: Default CPU ID = 1
CFE_PSP: Default Spacecraft ID = 66
CFE_PSP: Default CPU Name: CPU1
CFE_PSP: Starting the cFE with a POWER ON reset.
CFE_PSP: Clearing out CFE CDS Shared memory segment.
CFE_PSP: Clearing out CFE Reset Shared memory segment.
CFE_PSP: Clearing out CFE User Reserved Shared memory segment.
2027-356-20:29:57.62589 POWER ON RESET due to Power Cycle (Power Cycle).
2027-356-20:29:57.62591 ES Startup: CFE_ES_Main in EARLY_INIT state
CFE_PSP: CFE_PSP_AttachExceptions Called
2027-356-20:29:57.62596 ES Startup: CFE_ES_Main entering CORE_STARTUP state
2027-356-20:29:57.62597 ES Startup: Starting Object Creation calls.
2027-356-20:29:57.62598 ES Startup: Calling CFE_ES_CDSEarlyInit
2027-356-20:29:57.62609 ES Startup: Calling CFE_EVS_EarlyInit
2027-356-20:29:57.62613 Event Log cleared following power-on reset
2027-356-20:29:57.62614 ES Startup: Calling CFE_SB_EarlyInit
2027-356-20:29:57.62627 ES Startup: Calling CFE_TIME_EarlyInit
1980-012-14:03:20.00000 ES Startup: Calling CFE_TBL_EarlyInit
1980-012-14:03:20.00023 ES Startup: Calling CFE_FS_EarlyInit
1980-012-14:03:20.00050 ES Startup: Core App: CFE_EVS created. App ID: 0
EVS Port1 66/1/CFE_EVS 14: No subscribers for MsgId 0x808,sender CFE_EVS
EVS Port1 66/1/CFE_EVS 1: cFE EVS Initialized. cFE Version 6.5.0.0
1980-012-14:03:20.05067 ES Startup: Core App: CFE_SB created. App ID: 1
1980-012-14:03:20.05072 SB:Registered 4 events for filtering
EVS Port1 66/1/CFE_SB 14: No subscribers for MsgId 0x808,sender CFE_SB
EVS Port1 66/1/CFE_SB 1: cFE SB Initialized
1980-012-14:03:20.10086 ES Startup: Core App: CFE_ES created. App ID: 2
EVS Port1 66/1/CFE_SB 14: No subscribers for MsgId 0x808,sender CFE_ES
EVS Port1 66/1/CFE_ES 1: cFE ES Initialized
EVS Port1 66/1/CFE_SB 14: No subscribers for MsgId 0x808,sender CFE_ES
EVS Port1 66/1/CFE_ES 2: Versions:cFE 6.5.0.0, OSAL 4.2.1.0, PSP 1.3.0.0, chksm 15267
1980-012-14:03:20.15104 ES Startup: Core App: CFE_TIME created. App ID: 3
EVS Port1 66/1/CFE_SB 14: No subscribers for MsgId 0x808,sender CFE_TIME
EVS Port1 66/1/CFE_TIME 1: cFE TIME Initialized
1980-012-14:03:20.20121 ES Startup: Core App: CFE_TBL created. App ID: 4
EVS Port1 66/1/CFE_TBL 1: cFE TBL Initialized.  cFE Version 6.5.0.0
1980-012-14:03:20.25129 ES Startup: Finished ES CreateObject table entries.
1980-012-14:03:20.25135 ES Startup: CFE_ES_Main entering CORE_READY state
1980-012-14:03:20.25140 ES Startup: Opened ES App Startup file: /cf/apps/cfe_es_startup.scr
1980-012-14:03:20.25158 ES Startup: Loading file: /cf/apps/ci_lab.so, APP: CI_LAB_APP
1980-012-14:03:20.25160 ES Startup: loading directly:/cf/apps/ci_lab.so (CI_LAB_APP) -70028.
1980-012-14:03:20.25194 ES Startup: CI_LAB_APP loaded and created
EVS Port1 66/1/CI_LAB_APP 6: CI: RESET command
EVS Port1 66/1/CI_LAB_APP 3: CI Lab Initialized.  Version 2.2.0.0
1980-012-14:03:20.25217 ES Startup: Loading file: /cf/apps/to_lab.so, APP: TO_LAB_APP
1980-012-14:03:20.25219 ES Startup: loading directly:/cf/apps/to_lab.so (TO_LAB_APP) -70028.
1980-012-14:03:20.25245 ES Startup: TO_LAB_APP loaded and created
EVS Port1 66/1/TO_LAB_APP 1: TO Lab Initialized. Version 2.2.0.0 Awaiting enable command.
1980-012-14:03:20.25266 ES Startup: Loading file: /cf/apps/sch_lab.so, APP: SCH_LAB_APP
1980-012-14:03:20.25267 ES Startup: loading directly:/cf/apps/sch_lab.so (SCH_LAB_APP) -70028.
1980-012-14:03:20.25286 ES Startup: SCH_LAB_APP loaded and created
SCH Lab Initialized.  Version 2.2.0.0
1980-012-14:03:20.25303 ES Startup: Loading file: /cf/apps/lls_app.so, APP: LLS_APP
1980-012-14:03:20.25304 ES Startup: loading directly:/cf/apps/lls_app.so (LLS_APP) -70028.
1980-012-14:03:20.25322 ES Startup: Could not load cFE application file:/cf/apps/lls_app.so. EC = 0xFFFFFFFF
1980-012-14:03:20.25324 ES Startup: CFE_ES_Main entering OPERATIONAL state
EVS Port1 66/1/CFE_TIME 21: Stop FLYWHEEL

Describe the bug
The CFE_TBL_MAX_FULL_NAME_LEN size definition, which is used as part of the CFE_TBL_FileDef_t structure, is partly based on the OS_MAX_API_NAME value.

The problem is that this value is platform scope and thereby configurable on a per-cpu basis. Therefore, the OS_MAX_API_NAME value can be (validly) different on each CPU in a multi-cpu deployment. This, in turn, means the table definition headers may be different on each CPU.

Tools like elf2cfetbl and tblCRCTool do not account for this possibility; when reading or writing the table header, they use a single definition. The definition that they use may or may not even match what the flight code uses at all, depending on how the mission is configured.

To Reproduce
Configure a mission with two CPUs, and specify a different osconfig.h for each one (i.e. set TGT2_PLATFORM to something other than default). Change the value of OS_MAX_API_NAME for the second CPU, and build all software.

Observe that the sizeof(CFE_TBL_FileDef_t) is now also different on CPU2 vs. CPU1. Tables generated by elf2cfetbl and the CRC computed by tblCRCTool only work in CPU1. CPU2 will not be able to load tables because of the incompatible header.

Expected behavior
The sizeof(CFE_TBL_FileDef_t) should remain consistent regardless of the platform-scope values used, because this is an external format shared between (at least) between ground systems and flight code.

The CFE_MISSION_MAX_API_LEN macro is a better choice here. It was introduced in a previous version of CFE for telemetry packets, but table files are effectively the same issue.

Code snips
The problem definition is:

#define CFE_TBL_MAX_FULL_NAME_LEN_COMP (CFE_MISSION_TBL_MAX_NAME_LENGTH + OS_MAX_API_LEN + 2)

Furthermore, as this definition is only really for the header struct, it should be in cfe_tbl_filedef.h, not cfe_tbl.h. This allows external tools to include this definition without having to pull in the rest of CFE headers implicitly.

System observed on:
Ubuntu 18.04 (64-bit), kernel 5.0.0-23-generic

Reporter Info
Joseph Hickey, Vantage Systems, Inc.

Is your feature request related to a problem? Please describe.
SB Subscription Report message is not timestampted:

Describe the solution you'd like
Timestamp should be added here and anywhere else it's missing for all cFS generated SB messages:

CFE_SB_TimeStampMsg((CFE_SB_Msg_t *) &CFE_SB.SubRprtMsg);

Describe alternatives you've considered
None

Additional context
None

Requester Info
Jacob Hageman/NASA-GSFC
Originated from PACE/OCI

In general it is not a good idea to return a structure from a function because compilers do not all perform this the same way. Some compilers/ABIs are reasonably efficient at this (as gcc seems to be), but others are not so efficient and will do extra copies of the structure.

Although the git repositories established on babelfish so far appear to work well enough for our development model, it is rather complicated to set up a build from a clean slate using them. In order to do so you need to clone (at least) 5 repos and also make sure you get compatible versions/branches from all 5, then set up your build, which may involve copying some files around, which then have to go into the mission-specific version control.

I suspect that real missions/users would not want to keep these repos separate even though they are distributed separately; it is much more effort to manage it when each subdirectory comes from a different repo and it is very easy to "break" the build by grabbing incompatible branches.

Instead, a project using these would probably want to set up a single git repo for their mission that has everything included. There are a couple ways to do this in git such that compatibility with the "upstream" repo is retained, but it does require some of the more esoteric git features to do this right.

A script could do most of this work to simplify deployment and make sure it is done right.

I get the following error when doing a make install - it fails on mission-install.

Install the project...
-- Install configuration: "debug"
-- Up-to-date: /home/elliot/obc/src/cFS/build/exe/cpu1/cf/cfe_es_startup.scr
-- Installing: /home/elliot/obc/src/cFS/build/exe/cpu1/core-cpu1
-- Up-to-date: /home/elliot/obc/src/cFS/build/exe/cpu1/cf/pe.so
-- Up-to-date: /home/elliot/obc/src/cFS/build/exe/cpu1/cf/img.so
Built target cpu1-install
make[5]: *** No rule to make target 'install'.  Stop.
CMakeFiles/mission-install.dir/build.make:57: recipe for target 'CMakeFiles/mission-install' failed
make[4]: *** [CMakeFiles/mission-install] Error 2
CMakeFiles/Makefile2:195: recipe for target 'CMakeFiles/mission-install.dir/all' failed
make[3]: *** [CMakeFiles/mission-install.dir/all] Error 2
CMakeFiles/Makefile2:202: recipe for target 'CMakeFiles/mission-install.dir/rule' failed
make[2]: *** [CMakeFiles/mission-install.dir/rule] Error 2
Makefile:181: recipe for target 'mission-install' failed
make[1]: *** [mission-install] Error 2
Makefile:117: recipe for target 'install' failed
make: *** [install] Error 2

In particular, this should be done at least for functions that accept char * strings but do not modify them. If a string literal (by definition a const char *) is passed into function argument that is declared a non-const char *, a compiler warning may be generated and the build will fail if compiled with strict settings.

This ticket will add "const" to function parameters where appropriate.

Under normal conditions, when a task is started, the process of loading
the task will clear the BSS segment (used to store global-scope variables
that are not explicitly initialized).

However, if a task is "restarted" without "reloading" it may find that
its BSS segment still retains the content from the prior run.

We discussed this at the CCB meeting on 2016-Jan-19, and the moderate
concensus was that it might be most useful for the BSP to explicitly clear
the BSS of tasks before they are started. According to my notes, Joe was
going to take a look at this.

In the current version, some external interface (command/telemetry) messages contain direct CPU memory addresses.

This can be very bad for several reasons:

• Memory addresses can be a different size on different CPUs
• Since memory addresses are likely to change from run to run (even in the same build) it makes it difficult to script tests
• The receiver has no way to validate it (other than NULL).
• If the address value ever gets corrupted or an invalid value is used, the consequence is usually dire (a crash).

Ultimately the use of direct memory addresses in messages should be avoided.

As a first step to this, this ticket will modify those locations that a memory address is read or written from an external message to use a wrapper function.

This ticket won't change any functionality in itself, but it will provide a path going forward such that the wrapper function can be modified to convert the address to/from a safe, verifiable, architecture independent value rather than using the address directly.

Is your feature request related to a problem? Please describe.
Unable to verify library image integrity (CS cannot scrub library code space)

Describe the solution you'd like
Implement API for querying library information, such that an app could scrub

Describe alternatives you've considered
None

Additional context
None

Requester Info
Jacob Hageman/NASA-GSFC
External request from cfs-community email list on 9/3/2019

Is the cFS version that is available on the master branch compatible with OSX? Looking through the files, it seems like cFS uses a lot of the extended posix functionalities (e.g. timers, thread prioritization and certain real time signals) that are not available on OSX. Although OSX is posix compliant, it doesn't support extended posix functionalities.

From a development standpoint, support for OSX is desirable. I have developed some patches that can be applied to some osal and psp src files to enable compilation on OSX (including a reimplementation of the timer API using the grand central dispatch on OSX). If the cFS developers are interested in looking into this, I can integrate these patches and submit a pull request.

The FS application has a feature where it can decompress file content on the fly. However the decompression routine keeps its internal state in global variables which makes it non-reentrant. To protect against concurrent usage a mutex is used but this has a major performance impact.

The global variables should be replaced with a state structure so that it can be multithreaded like all other parts of CFS.

For the time being a global state object can be implemented in order to preserve API compatibility.

In order to reduce the chance of name space conflicts, enumerated names should follow the general form, with the value prefixed by the group name and the app name:

<VALUEID_1>
<VALUEID_2>
....
<VALUEID_N>

This ensures that even if two enums use the same value name(s) they will not conflict with each other.

Most #define'd values already follow this general form, but there are some exceptions. These should be fixed to be consistent.

In each app directory, such as sample_app/fsw/for_build/Makefile, there is "-I../cfe/inc", but I could find this sub directory in cFE/build/cpu1/cfe, where I can get sample_app int the directory /cFE/build/cpu1. Thanks!
Sincerely

Update documentation to show Posix fix:

Edit /etc/sysctl.conf and add the lines:

	# Increase message queue
	fs.mqueue.msg_max = 256

Or

Edit as root /proc/sys/fs/mqueue/msg_max is set to 256 or some value appropriate.

root# echo 256 > /proc/sys/fs/mqueue/msg_max

https://sourceforge.net/projects/cfs-cfdp/

Describe the bug
This repo has several references to coreflightsystem.org. The current owner of that domain is using it for spreading malware (I got a prompt to install a Firefox malware addon).

To Reproduce
Steps to reproduce the behavior:

1. Go to https://github.com/nasa/cFE
2. Click on the links to coreflightsystem.org
3. Get prompted to install malware, or with spam links.

Expected behavior
No links to malware sites

Code snips
Not applicable

System observed on:
Firefox on Chrome (probably applies to other browsers and platforms)

OSAL returns object identifiers which are defined as uint32 values. In the current implementation of OSAL they happen to be zero-based but this should not be a requirement; in fact there are several advantages to making these identifiers non-zero-based.

The primary offender is the ES core application using the task ID from OSAL directly as an array index.

To ensure compatibility the OSAL object IDs should be treated as opaque integers of undefined range.