nasa/md

The Core Flight System (cFS) Memory Dwell (MD) application.

core Flight System (cFS) Memory Dwell Application (MD)

Introduction

The Memory Dwell application (MD) is a core Flight System (cFS) application that is a plug in to the Core Flight Executive (cFE) component of the cFS.

The MD application monitors memory addresses accessed by the CPU. This task is used for both debugging and monitoring unanticipated telemetry that had not been previously defined in the system prior to deployment.

The MD application is written in C and depends on the cFS Operating System Abstraction Layer (OSAL) and cFE components.

User's guide information can be generated using Doxygen (from top mission directory):

  make prep
  make -C build/docs/md-usersguide md-usersguide

Software Required

cFS Framework (cFE, OSAL, PSP)

An integrated bundle including the cFE, OSAL, and PSP can be obtained at https://github.com/nasa/cfs

About cFS

The cFS is a platform and project independent reusable software framework and set of reusable applications developed by NASA Goddard Space Flight Center. This framework is used as the basis for the flight software for satellite data systems and instruments, but can be used on other embedded systems. More information on the cFS can be found at http://cfs.gsfc.nasa.gov

md's Issues

Static analysis workflow fails due to style warnings

Checklist (Please check before submitting)

• I reviewed the Contributing Guide.
• I reviewed the README file to see if the feature is in the major future work.
• I performed a cursory search to see if the feature request is relevant, not redundant, nor in conflict with other tickets.

Is your feature request related to a problem? Please describe.
Strict cppcheck warnings cause static analysis workflow failure, see: https://github.com/nasa/MD/runs/6357277924?check_suite_focus=true

[fsw/src/md_cmds.c:50] -> [fsw/src/md_cmds.c:56]: (style) Variable 'Start' is reassigned a value before the old one has been used.
[fsw/src/md_cmds.c:141] -> [fsw/src/md_cmds.c:149]: (style) Variable 'Stop' is reassigned a value before the old one has been used.
[fsw/src/md_cmds.c:421] -> [fsw/src/md_cmds.c:428]: (style) Variable 'SignatureCmd' is reassigned a value before the old one has been used.
[fsw/src/md_dwell_pkt.c:153] -> [fsw/src/md_dwell_pkt.c:158]: (style) Variable 'TblPtr' is reassigned a value before the old one has been used.
[fsw/src/md_dwell_tbl.c:306] -> [fsw/src/md_dwell_tbl.c:311]: (style) Variable 'LocalControlStruct' is reassigned a value before the old one has been used.
[fsw/src/md_dwell_tbl.c:355] -> [fsw/src/md_dwell_tbl.c:358]: (style) Variable 'GetAddressResult' is reassigned a value before the old one has been used.
[fsw/src/md_dwell_tbl.c:435] -> [fsw/src/md_dwell_tbl.c:439]: (style) Variable 'GetAddressResult' is reassigned a value before the old one has been used.

Describe the solution you'd like
Fix

Describe alternatives you've considered
None

Additional context
None

Requester Info
Jacob Hageman - NASA/GSFC

Inconsistent variable naming when referring to the time between dwell passes

It was noted in a recent ITOS .rec file review for the CCRS project that the naming of items that referred to the time between dwell passes was inconsistent. This was traced back to the MD code and it found that the inconsistency stemmed from there.
As posted by the tester that inspected the code and .rec file:
"The commands and telemetry seem to disagree as to whether to use 'rate' or 'delay' to refer to the time between dwell passes. This is reflected in the source code as well - where the source refers to 'delay', the .rec file also uses 'delay', and where the source uses 'rate', the .rec file uses 'rate'. Unclear whether it's worth standardizing this."

It seems the rate and delay are being used to refer to the same thing. One should be picked and used to reduce confusion.

Inconsistent Event ID naming

Checklist

• I reviewed the Contributing Guide.
• I performed a cursory search to see if the bug report is relevant, not redundant, nor in conflict with other tickets.

Describe the bug
Copy of nasa/cFE#2175
After finding that there were 9 different Event IDs to indicate the same thing (Invalid Message ID) in nasa/CF#262, I scrubbed the other common commands (e.g. Task Initialisation [INIT], NOOP, Reset Counters etc.) and found the same issue there - almost every component/app had their own variation of the Event ID name for the exact same event.

Expected behavior
Apply consistent Event ID names to the events which are common to all/most components and apps.

Code snips
Invalid Message ID:
CFE_EVS_ERR_MSGID_EID
CFE_SB_BAD_MSGID_EID
CFE_TIME_ID_ERR_EID
CS_MID_ERR_EID
TO_LAB_MSGID_ERR_EID
SAMPLE_APP_INVALID_MSGID_ERR_EID
BP_INVALID_MID_ERR_EID
SCH_MD_ERR_EID
CI_LAB_COMMAND_ERR_EID

Initialization:
CFE_TIME_INIT_EID
CFE_TBL_INIT_INF_EID
CFE_EVS_STARTUP_EID
CF_EID_INF_INIT
BP_INIT_APP_INFO_EID
SCH_INITSTATS_INF_EID
CI_LAB_STARTUP_INF_EID

NOOP:
CFE_TIME_NOOP_EID
CFE_TBL_NOOP_INF_EID
CFE_SB_CMD0_RCVD_EID
CF_EID_INF_CMD_NOOP
FM_NOOP_CMD_EID
CI_LAB_COMMANDNOP_INF_EID

Reset Counters:
CFE_TIME_RESET_EID
CFE_TBL_RESET_INF_EID
CFE_EVS_RSTCNT_EID
CFE_SB_CMD1_RCVD_EID
CF_EID_INF_CMD_RESET
SC_RESET_DEB_EID
HS_RESET_DBG_EID
FM_RESET_CMD_EID
HK_RESET_CNTRS_CMD_EID
MD_RESET_CNTRS_DBG_EID
CI_LAB_COMMANDRST_INF_EID

etc.

Reporter Info
Avi Weiss @thnkslprpt

Uncovered lines/branches

Checklist (Please check before submitting)

• I reviewed the Contributing Guide.
• I performed a cursory search to see if the bug report is relevant, not redundant, nor in conflict with other tickets.

Describe the bug

• Fix #7: found instances of branches that can never be reached by unit tests.

To Reproduce
Functions with statements that can never be reached:

md_app.c: MD_ExecRequest
can't hit default case since command codes are already verified by MD_SearchCmdHndlrTbl

MD/fsw/src/md_app.c

Lines 666 to 671 in 853c1e0

	default:
	/* unknown function code specified - send error event message */
	CFE_EVS_SendEvent(MD_CC_NOT_IN_LOOP_ERR_EID, CFE_EVS_EventType_ERROR,
	"Command Code %d not found in command processing loop", CommandCode);
	MD_AppData.ErrCounter++;
	break;

md_app.c: MD_SearchCmdHndlrTbl
can't reach this else statement because the message type can't be anything other than MD_CMD_MSGTYPE or MD_TERM_MSGTYPE

MD/fsw/src/md_app.c

Lines 761 to 766 in 853c1e0

	else
	/* Message is not a command message with specific command code */
	{
	/* Matching Message ID is all that is required */
	FoundMatch = true;
	}

md_dwell_tbl.c: MD_TableValidationFunc

MD/fsw/src/md_dwell_tbl.c

Lines 145 to 149 in 853c1e0

	else
	{
	/* Should not get here, MD_ValidTableEntry only returns the above values */
	Status = -1;
	}

Expected behavior
100% coverage

Code snips
See above

System observed on:
CI

Additional context
None

Reporter Info
Haven Carlson, NASA

Move interface definition files to "inc" location

Checklist (Please check before submitting)

• I reviewed the Contributing Guide.
• I reviewed the README file to see if the feature is in the major future work.
• I performed a cursory search to see if the feature request is relevant, not redundant, nor in conflict with other tickets.

Is your feature request related to a problem? Please describe.
The interface definition files of all open source apps currently exist in the "src" directory.

Describe the solution you'd like
Create an "inc" dir to go with the "src" dir. Move the interface definitions into this location: "_msg.h", "_msgdefs.h", "_tbldefs.h", and "_events.h". Consider moving header files in both "platform_inc" and "mission_inc" to "inc"

Describe alternatives you've considered
Leaving as is.

Additional context
N/A

Requester Info
Justin Figueroa, Vantage Systems

Resolve static analysis issues relative to unit tests

Many actual code issues (uninitialized variables, buffer overruns, etc) identified via static analysis in the unit tests. All actual "bugs" should be resolved.

Imported from GSFCCFS-1936

Replace quotes with angle brackets in #include statements within /inc

Describe the solution you'd like
Quotes should be replaced with angle brackets in #include statements that reside in the /inc location. This will ensure that the preprocessor selects the files pre-designated to override the default files contained within the open source cFS build release - as opposed to selecting those located in the same directory.

Requester Info
Dan Knutsen
NASA Goddard

Incorrect unit tests are in this repository

The unit tests in this repository are not the same as the tests on Sourceforge and do not work correctly.

Remove all mentions of ASIST or ITOS artifacts from documentation

Some of our doxygen docs still reference ASIST or ITOS artifacts.

See
cfs_mm repo: fsw/src/mm_msgdefs.h:l28

Imported from GSFCCFS-1929

MD - Table Configuration is Not Consistent with Other Applications

MD currently gets the dwell tables from the CDS or zeros them out. The MD table design is not consistent with other cFS applications:

• The MD task should allow the option to save or not save tables in the CDS (and therefore behave like the other applications).
• The MD task should allow the option to have default tables in EEPROM (and therefore behave like the other applications).
• The default address to be used, should a table not be found, should be user defined. 0 may not be a valid address.
• The MD task doesn't use the CFE_TBL_Manage feature.

Imported from GSFCCFS-764

Remove dependency on CFE_PLATFORM_TLM_MID_BASE in tests

Checklist (Please check before submitting)

• I reviewed the Contributing Guide.
• I performed a cursory search to see if the bug report is relevant, not redundant, nor in conflict with other tickets.

Describe the bug
The MD app depends on CFE_PLATFORM_TLM_MID_BASE which may or may not exist in the user-defined config

To Reproduce
Build MD with latest mainline

Expected behavior
Should not depend on this symbol

System observed on:
Debian

Additional context
Unit test issue, does not affect FSW

Reporter Info
Joseph Hickey, Vantage Systems, Inc.

Standardization of Command Responses

Checklist (Please check before submitting)

• I reviewed the Contributing Guide.
• I reviewed the README file to see if the feature is in the major future work.
• I performed a cursory search to see if the feature request is relevant, not redundant, nor in conflict with other tickets.

Is your feature request related to a problem? Please describe.
cFS should have standardized command responses for commands that set a state/mode like enable/disable, on/off, true/false, start/stop/pause/resume, etc.

For those commands, the app should respond as describe below:

• If the current setting is not in that commanded state,

  1. If the commanded state can be set successfully,
     a. Increment the command counter
     b. Send an INFO event that says command successfully executed
  2. otherwise,
     a. Increment the command error counter
     b. Send an ERROR event that says failed to execute the command

• If the current setting is already in that commanded state,

  1. Increment the command counter, not command error counter
  2. Send an INFO event that says already in that state

The following command response does not align with the standard:
The reset counters success event is debug type MD_RESET_CNTRS_DBG_EID

Describe the solution you'd like
Update logic to align with the standard.

Requester Info
Dan Knutsen
NASA Goddard

Deprecated #include of "cfe_platform_cfg.h"

Checklist (Please check before submitting)

• I reviewed the Contributing Guide.
• I performed a cursory search to see if the bug report is relevant, not redundant, nor in conflict with other tickets.

Describe the bug
The practice of #include "cfe_platform_cfg.h" has been deprecated. Applications should not be dependent on a specific CFE platform configuration

To Reproduce
Manually inspect

Expected behavior
Remove all `#include "cfe_platform_cfg.h"

Code snips

MD/fsw/src/md_verify.h

Line 28 in fe60ebc

#include "cfe_platform_cfg.h"

System observed on:
N/A

Additional context
N/A

Reporter Info
Justin Figueroa, Vantage Systems

Scrub use of () in return statements

Checklist

• I reviewed the Contributing Guide.
• I performed a cursory search to see if the bug report is relevant, not redundant, nor in conflict with other tickets.

Describe the bug
Unnecessary parentheses around return values in MD
Copy of nasa/osal#866

Reporter Info
@thnkslprpt

Two events in md_events.h have the same event ID

MD_TBL_VAL_NULL_PTR_ERR_EID & MD_UPDATE_TBL_SIG_ERR_EID are both assigned event ID 55

MD - consider reporting number of addresses being collected in MD3001

Typically MD3000 will need to have a fixed total size of bytes such that the creation of the message (MD3001) will result in the same size. That means MD3001 item c) number of bytes sampled will typically always be the same on systems that required fixed size telemetry packets (assuming a database change is not made every time a new table is needed) and the address count will always be the max number of entries.

Consider FSW update to report the actual used address count (those with nonzero byte counts).

Imported from GSFCCFS-1769

Remove stray terminators

Checklist (Please check before submitting)

• I reviewed the Contributing Guide.
• I reviewed the README file to see if the feature is in the major future work.
• I performed a cursory search to see if the feature request is relevant, not redundant, nor in conflict with other tickets.

Is your feature request related to a problem? Please describe.

MD/fsw/src/md_dwell_tbl.c

Line 456 in 3760707

;

Describe the solution you'd like
Remove

Describe alternatives you've considered
None

Additional context
None

Requester Info
Jacob Hageman - NASA/GSFC

Apps should use CFE_MSG_PTR macro instead of cast or local unwrapping

Apps typically cast to a CFE_MSG_Message_t or use *.Msg. Better to use abstracted CFE_MSG_PTR. NOTE - Not backwards compatible with Caelum so recommend not addressing in Draco.

Imported from GSFCCFS-1900

Consider using an enum for MD error codes

In file md_dwell_pkt.c function MD_GetDwellData, all the "-1" status values could be replaced with an enum.

Finding from code review.

Imported from GSFCCFS-1048

New Cppcheck errors: '[unreadVariable]'

Checklist

• I reviewed the Contributing Guide.
• I performed a cursory search to see if the bug report is relevant, not redundant, nor in conflict with other tickets.

Describe the bug
Latest version of Cppcheck is issuing the following failures for MD:

fsw/src/md_cmds.c:46:40: style: Variable 'Status' is assigned a value that is never used. [unreadVariable]
    int32              Status          = CFE_SUCCESS;
                                       ^
fsw/src/md_cmds.c:49:40: style: Variable 'TableIndex' is assigned a value that is never used. [unreadVariable]
    uint16             TableIndex      = 0;
                                       ^
fsw/src/md_cmds.c:134:40: style: Variable 'Status' is assigned a value that is never used. [unreadVariable]
    int32              Status          = CFE_SUCCESS;
                                       ^
fsw/src/md_cmds.c:138:40: style: Variable 'TableIndex' is assigned a value that is never used. [unreadVariable]
    uint16             TableIndex      = 0;
                                       ^
fsw/src/md_cmds.c:195:44: style: Variable 'Status' is assigned a value that is never used. [unreadVariable]
    int32                   Status         = CFE_SUCCESS;
                                           ^
fsw/src/md_cmds.c:199:44: style: Variable 'DwellEntryPtr' is assigned a value that is never used. [unreadVariable]
    MD_DwellControlEntry_t *DwellEntryPtr  = 0; /* points to local task data */
                                           ^
fsw/src/md_cmds.c:200:44: style: Variable 'EntryIndex' is assigned a value that is never used. [unreadVariable]
    uint16                  EntryIndex     = 0;
                                           ^
fsw/src/md_cmds.c:410:40: style: Variable 'Status' is assigned a value that is never used. [unreadVariable]
    int32                 Status       = CFE_SUCCESS;
                                       ^
fsw/src/md_dwell_pkt.c:40:37: style: Variable 'Result' is assigned a value that is never used. [unreadVariable]
    int32                    Result = 0;
                                    ^
fsw/src/md_dwell_pkt.c:42:48: style: Variable 'EntryIndex' is assigned a value that is never used. [unreadVariable]
    uint16                   EntryIndex        = 0;
                                               ^
fsw/src/md_dwell_pkt.c:43:48: style: Variable 'NumDwellAddresses' is assigned a value that is never used. [unreadVariable]
    uint16                   NumDwellAddresses = 0;
                                               ^
fsw/src/md_dwell_tbl.c:174:27: style: Variable 'Status' is assigned a value that is never used. [unreadVariable]
    int32  Status         = CFE_SUCCESS;
                          ^
fsw/src/md_utils.c:192:21: style: Variable 'OS_Status' is assigned a value that is never used. [unreadVariable]
    int32 OS_Status = OS_SUCCESS;
                    ^
##[error]Process completed with exit code 255.

To Reproduce
Run the current version of Cppcheck on the current main branch MD source code.

Expected behavior
Cppcheck should pass without raising any errors.

Reporter Info
Avi @thnkslprpt

Add CodeQL to repository

Checklist (Please check before submitting)

• I reviewed the Contributing Guide.
• I reviewed the README file to see if the feature is in the major future work.
• I performed a cursory search to see if the feature request is relevant, not redundant, nor in conflict with other tickets.

Is your feature request related to a problem? Please describe.
Use CodeQL for continuous integration

Describe the solution you'd like
Add CodeQL workflow

Describe alternatives you've considered
None

Additional context
Add any other context about the feature request here.

Requester Info
Haven Carlson

MD `int32` return codes and variables should be converted to `CFE_Status_t`

Checklist

• I reviewed the Contributing Guide.
• I performed a cursory search to see if the bug report is relevant, not redundant, nor in conflict with other tickets.

Describe the bug
MD has quite a few return codes (as well as local status/return variables which hold CFE return codes) that can be easily converted over to the CFE_Status_t typedef.

Expected behavior
Use the more expressive CFE_Status_t and improve consistency with cFS.

Reporter Info
Avi Weiss @thnkslprpt

Static analysis issues relative to flight code

Handful of static analysis issues in the "red" identified (non-Style issues). Need to resolve these.

Filter: -file:elf -file:ut -file:cfe -file:os -file:cf_ -file:_lab_app.c !(significance:style)

should resolve and/or disposition the higher ranked ones at minimum.

Note license restricts publishing issues.

Imported from GSFCCFS-1958

Combine consecutive, mutually-exclusive status checks

Checklist

• I reviewed the Contributing Guide.
• I performed a cursory search to see if the bug report is relevant, not redundant, nor in conflict with other tickets.

Describe the bug
md_app.c contains a couple of consecutive, mutually exclusive status checks.

Code snips

MD/fsw/src/md_app.c

Lines 188 to 197 in 116d298

	if (Status != CFE_SUCCESS)
	{
	CFE_ES_WriteToSysLog("MD_APP:Call to CFE_EVS_Register Failed:RC=%d\n", Status);
	}
	/*
	** Set up for Software Bus Services
	*/
	if (Status == CFE_SUCCESS)
	{

MD/fsw/src/md_app.c

Lines 274 to 283 in 116d298

	if (Status != CFE_SUCCESS)
	{
	CFE_EVS_SendEvent(MD_CREATE_PIPE_ERR_EID, CFE_EVS_EventType_ERROR, "Failed to create pipe. RC = %d", Status);
	}
	/*
	** Subscribe to Housekeeping request commands
	*/
	if (Status == CFE_SUCCESS)
	{

Expected behavior
Combine into an if/else - no need to do 2 evaluations.

Reporter Info
Avi Weiss @thnkslprpt

Fill in missing requirements rationale

There's a handful of missing requirements rationale. Add.

Imported from GSFCCFS-2019

Add fsw/src to app target

Checklist (Please check before submitting)

• I reviewed the Contributing Guide.
• I performed a cursory search to see if the bug report is relevant, not redundant, nor in conflict with other tickets.

Describe the bug
Cannot build cert_testbed. target_include_directories(xx PUBLIC fsw/src) is needed to build tables, etc. Revise CMakeLists.txt

To Reproduce
Build in cert_testbed

Expected behavior
Error-free build

Code snips
If applicable, add references to the software.

System observed on:

• Ubuntu 20.04

Additional context
N/A

Reporter Info
Justin Figueroa, Vantage Systems

MD is unable to dwell on application-private symbols

Checklist (Please check before submitting)

• [ x] I reviewed the Contributing Guide.
• [x ] I reviewed the README file to see if the feature is in the major future work.
• [x ] I performed a cursory search to see if the feature request is relevant, not redundant, nor in conflict with other tickets.

Is your feature request related to a problem? Please describe.
MD is unable to get application symbols, due to changes in cFE to make application symbols private: nasa/cFE#952

Describe the solution you'd like
Using OS_ModuleSymbolLookup should be an option to peek/telemeter app-private symbols

Describe alternatives you've considered
Leave as-is; implementation of OS_ModuleSymbolLookup is the same as OS_SymbolLookup on vxWorks anyways, so it would appear this would only affect Linux.

Additional context

MD/fsw/src/md_utils.c

Line 216 in 408ff72

OS_Status = OS_SymbolLookup(ResolvedAddr, SymAddr->SymName);

Requester Info
John Pham, Northrop Grumman

Code Coverage not 100% when MD_SIGNATURE_OPTION set to 0

Checklist (Please check before submitting)

• [ x] I reviewed the Contributing Guide.
• [x ] I performed a cursory search to see if the bug report is relevant, not redundant, nor in conflict with other tickets.

Describe the bug
There are a checks to ensure the dwell address is properly aligned for a specified dwell length that do not get exercised if MD_SIGNATURE_OPTION is set to 0.

To Reproduce
Steps to reproduce the behavior:

1. Set MD_SIGNATURE_OPTION to 0 and view lcov code coverage report.

Expected behavior
100% code coverage

Reporter Info
Dan Knutsen
NASA/Goddard

MD Dwell Table Tests String Error

Checklist (Please check before submitting)

• I reviewed the Contributing Guide.
• I performed a cursory search to see if the bug report is relevant, not redundant, nor in conflict with other tickets.

Describe the bug
While compiling the latest version of MD with unit tests enabled, my build environment gave me the following error:

error: 'MD_UpdateTableSignature' accessing 32 bytes in a region of size 13 [-Werror=stringop-overflow=]

Code snips
The bug relates to this line and a few others with the same variable used for testing MD signatures. It seems as though the compiler does not like that newsignature is implicitly a 13 byte string as opposed to a 32 byte string, which is what the function MD_UpdateTableSignature(uint16 TableIndex, char NewSignature[MD_SIGNATURE_FIELD_LENGTH]) expects

MD/unit-test/md_dwell_tbl_tests.c

Line 1117 in 87e0c1f

char newsignature[] = "newsignature";

For now, simply explicitly using the size of the array in the variable definition seems to work successfully.

char   newsignature[MD_SIGNATURE_FIELD_LENGTH] = "newsignature";

After changing to this locally wherever it appeared, my build works fine.

Update CLA Information

Checklist (Please check before submitting)

• I reviewed the Contributing Guide.
• I reviewed the cFS README.md file to see if the feature is in the major future work.
• I performed a cursory search to see if the feature request is relevant, not redundant, nor in conflict with other tickets.

Is your feature request related to a problem? Please describe.
Have new CLAs given the change in nasa/cFS#491 with the combined CLA,

Describe the solution you'd like

• Update the instructions in each app's Contributing.md
• Delete old CLA pdfs
• Update PR and Issue templates as needed

Describe alternatives you've considered

None

Additional context
None

Requester Info
Gerardo E. Cruz-Ortiz

Redundant comments (/* end of function */, /* end if */ etc.) and clean up empty lines.

Checklist

• I reviewed the Contributing Guide.
• I performed a cursory search to see if the bug report is relevant, not redundant, nor in conflict with other tickets.

Describe the bug
Copy of nasa/to_lab#68 and nasa/sample_app#111
There are quite a few redundant comments in the code, such as:

• /* end of function */-type comments
• /* end if */-type comments
• function header comments which include the function name

Another minor issue has to do with empty lines:
a) unnecessary empty lines (e.g. first line after the opening brace of a function/struct, or the last line before the closing brace - the latter apparently sometimes triggers the CI format checks).
b) missing empty lines between functions (i.e. closing brace of last function, then next function beginning on the immediately next line without an empty line in between)

The unnecessary empty lines (at the beginning or end of a function, for example) represent a low single-digit percentage of the cases (the vast majority of functions/structs do not have these extra empty lines), so there is an argument to remove them purely for consistency, not just due to them being redundant and triggering the CI format checks.

Expected behavior
Remove redundant comments to reduce clutter and inconsistency in the code, and improve readability.

Reporter Info
@thnkslprpt

Identical assert repeated twice (unintentionally)

Checklist

• I reviewed the Contributing Guide.
• I performed a cursory search to see if the bug report is relevant, not redundant, nor in conflict with other tickets.

Describe the bug
Assert of (call_count_CFE_EVS_SendEvent == 0... seems to have been pasted twice by mistake.

Code snips

MD/unit-test/md_app_tests.c

Lines 460 to 475 in 87e0c1f

	/* Verify results */
	UtAssert_True(Result == -1, "Result == -1");
	call_count_CFE_EVS_SendEvent = UT_GetStubCount(UT_KEY(CFE_EVS_SendEvent));
	UtAssert_True(call_count_CFE_EVS_SendEvent == 0, "CFE_EVS_SendEvent was called %u time(s), expected 0",
	call_count_CFE_EVS_SendEvent);
	strCmpResult = strncmp(ExpectedSysLogString, context_CFE_ES_WriteToSysLog.Spec, CFE_MISSION_EVS_MAX_MESSAGE_LENGTH);
	UtAssert_True(strCmpResult == 0, "Sys Log string matched expected result, '%s'", context_CFE_ES_WriteToSysLog.Spec);
	call_count_CFE_EVS_SendEvent = UT_GetStubCount(UT_KEY(CFE_EVS_SendEvent));
	UtAssert_True(call_count_CFE_EVS_SendEvent == 0, "CFE_EVS_SendEvent was called %u time(s), expected 0",
	call_count_CFE_EVS_SendEvent);

Expected behavior
Removing unintentionally repeated test will make cleaner test code.

Reporter Info
Avi Weiss @thnkslprpt

Remove CFE_PSP_MemSet use for addresses in RAM

Checklist (Please check before submitting)

• I reviewed the Contributing Guide.
• I reviewed the README file to see if the feature is in the major future work.
• I performed a cursory search to see if the feature request is relevant, not redundant, nor in conflict with other tickets.

Is your feature request related to a problem? Please describe.
Should just use memset/memcpy for addresses in RAM. The PSP functions serve no use in this context.

Describe the solution you'd like
Replace with memset/memcpy.

Describe alternatives you've considered
None

Additional context
None

Requester Info
Jacob Hageman - NASA/GSFC

All CMD/TLM messages should put content in a "Payload" sub-structure

Checklist (Please check before submitting)

• I reviewed the Contributing Guide.
• I reviewed the README file to see if the feature is in the major future work.
• I performed a cursory search to see if the feature request is relevant, not redundant, nor in conflict with other tickets.

Is your feature request related to a problem? Please describe.
To match the patterns used in CFE and other modules, all CMD/TLM message definitions should put the content (non-header) parts into a separate struct called "Payload".

Describe the solution you'd like
Separate message content into a sub structure called "Payload".

Additional context
This is benefit to tooling that can use the presence of this field to identify where the actual content starts (e.g. something like offsetof(MsgType, Payload) would work and be correct, as opposed to checking sizeof(CFE_MSG_CommandHeader_t) which may not actually reflect where the content starts due to possible compiler-added padding between them).

Requester Info
Haven Carlson - NASA

Dwell Table instantiated on stack, but not used

Checklist (Please check before submitting)

• I reviewed the Contributing Guide.
• I performed a cursory search to see if the bug report is relevant, not redundant, nor in conflict with other tickets.

Describe the bug
During init, the MD app instantiates a dwell table on the stack, and memset's it to 0:

MD/fsw/src/md_app.c

Line 331 in b0ae64d

MD_DwellTableLoad_t InitMemDwellTable;

However this is not anywhere for any purpose. It may be a remnant that was never cleaned up.

As a result, its using several kB of stack space unnecessarily.

Expected behavior
Should not allocate objects that are not necessary.

System observed on:
Debian

Additional context
This was discovered by analyzing the stack usage and finding that MD sometimes overran its allocated stack. Although there were other issues as well (see nasa/osal#1429) ... it was noted that this unneeded object was a significant contributor for why the problem showed up in MD and not other apps.

Reporter Info
Joseph Hickey, Vantage Systems, Inc.

Several printf spec string format conversions are incorrect

Checklist (Please check before submitting)

• I reviewed the Contributing Guide.
• I performed a cursory search to see if the bug report is relevant, not redundant, nor in conflict with other tickets.

Describe the bug
Several printf format conversions in MD are incorrect

To Reproduce
Build on system with different type mapping for int32, etc.

Expected behavior
Build should succeed

System observed on:
RTEMS 4.11

Reporter Info
Joseph Hickey, Vantage Systems, Inc.

Static analysis issues JSC 2.1

Checklist (Please check before submitting)

• I reviewed the Contributing Guide.
• I performed a cursory search to see if the bug report is relevant, not redundant, nor in conflict with other tickets.

Describe the bug
Static analysis issue. This report records the findings from the static analysis to facilitate their tracking.

Source Folder	Source Filename	Source Line	Source Object	Disposition
Off by One
\apps\md\fsw\src	md_dwell_tbl.c	395	SymName	Will Not Fix. SymName’s last element is accessed on this line by reference to its max size, greatly reducing an off by one risk.

To Reproduce
N/A. These issues were communicated by JSC.

Expected behavior
Need to resolve these. Should resolve and/or disposition the higher ranked ones at minimum.

Code snips
N/A

System observed on:
N/A

Additional context
N/A

Reporter Info
Imported from JSC 2.1 static analysis

Revisit coverage, update to 100% code/branch or write issues where unreachable

Failure: Coverage md lines 98.4% functions 100.0% branches 96.7%

Other coverage failures:
Failure: Coverage cs lines 99.9% functions 100.0% branches 99.1%
Failure: Coverage ds lines 99.6% functions 100.0% branches 97.7%
Failure: Coverage fm lines 93.8% functions 94.0% branches 89.1%
Failure: Coverage hs lines 100.0% functions 100.0% branches 98.1%
Failure: Coverage lc lines 99.6% functions 100.0% branches 94.3%
Failure: Coverage sc lines 99.9% functions 100.0% branches 99.0%

Fix where possible, elsewise Issues should document all uncovered lines/branches and disposition (why it's ok as-is)

Imported from GSFCCFS-1935

Multiple unnecessary `status`/`result` variables can be combined

Checklist

• I reviewed the Contributing Guide.
• I performed a cursory search to see if the bug report is relevant, not redundant, nor in conflict with other tickets.

Describe the bug
A few functions in md_dwell_tbl.c use multiple status/result variables which can be combined into one.

Code snips
Example:

MD/fsw/src/md_dwell_tbl.c

Lines 335 to 362 in 116d298

	int32 MD_UpdateTableEnabledField(uint16 TableIndex, uint16 FieldValue)
	{
	int32 Status = CFE_SUCCESS;
	MD_DwellTableLoad_t *MD_LoadTablePtr = NULL;
	int32 GetAddressResult;
	GetAddressResult = CFE_TBL_GetAddress((void *)&MD_LoadTablePtr, MD_AppData.MD_TableHandle[TableIndex]);
	if ((GetAddressResult != CFE_SUCCESS) && (GetAddressResult != CFE_TBL_INFO_UPDATED))
	{
	CFE_EVS_SendEvent(MD_UPDATE_TBL_EN_ERR_EID, CFE_EVS_EventType_ERROR,
	"MD_UpdateTableEnabledField, TableIndex %d: CFE_TBL_GetAddress Returned 0x%08x", TableIndex,
	GetAddressResult);
	Status = GetAddressResult;
	}
	else
	{
	MD_LoadTablePtr->Enabled = FieldValue;
	CFE_TBL_Modified(MD_AppData.MD_TableHandle[TableIndex]);
	CFE_TBL_ReleaseAddress(MD_AppData.MD_TableHandle[TableIndex]);
	Status = CFE_SUCCESS;
	}
	return Status;
	}

The result of GetAddressResult is just assigned to Status anyway, so they can be combined without any change to the functional behavior.

Expected behavior
Simplify code by removing unnecessary status/result variables.

Reporter Info
Avi Weiss @thnkslprpt

Resolve issues building users guide with Ubuntu 20.04/Doxygen 1.8.17

Checklist (Please check before submitting)

• I reviewed the Contributing Guide.
• I reviewed the CF README.md file to see if the feature is in the major future work.
• I performed a cursory search to see if the feature request is relevant, not redundant, nor in conflict with other tickets.

Is your feature request related to a problem? Please describe.
Doxygen warnings for multiple @param documentation settings

Describe the solution you'd like
Resove

Describe alternatives you've considered
None

Additional context
None

Requester Info
Jacob Hageman - NASA/GSFC