TO_LAB App only receiving NOOP commands

[nasa]

TO_LAB App only receiving NOOP commands

[atk5025]

Non-functional version is self reporting the following base configurations.

EVS Port1 42/1/CFE_ES 3: No-op command. Versions:cFE 6.7.12.0, OSAL 5.0.11.0, PSP 1.4.8.0

Also, it looks like in my environment, all applications are only responding with NOOPS. So the problem is probably outside TO_LAB and either CI_LAB or other core components on this build/target.

[jphickey]

please confirm that you have done a git submodule update after pulling the cFS repo. This is a possible symptom of changing the endianness of the secondary header if you cross versions between CFE and cmdutil/ground system

[jphickey]

Also important to note that the integration-candidate branch is not necessarily stable as it is the think being tested - please always use master unless you are intending to check the integration of the latest changes.

[atk5025]

@jphickey Thanks for your suggestions. Did command code endianness change in the last month somewhere? I was guessing this would be a stable parameter and only changing for different processor types.

Seems the crossing version endianness may be the root here. I seem to have ended up with differing combinations of endianness between a couple different builds I've done recently. Running the GroundSystem.py seems to send out out BE when it looks like now I'm expecting to receive the command code in LE.

When I go use the to-enable-tlm.sh script, it's sending the command code in LE so that's working.

Regarding integration-candidate, from what I can see in the update/pull I did previously, I'm pulling master for all repositories. I do see numerous references to the integration-candidate, but I thought that was just saying that while I'm on master, it was also pulling down the latest information for that branch but I could be misinterpreting that.

allen@akum-home-lt:/repos/cFS/missionxyz$ git submodule update
allen@akum-home-lt:/repos/cFS/missionxyz$ git pull
Already up to date.
allen@akum-home-lt:/repos/cFS/missionxyz$ git submodule update
allen@akum-home-lt:/repos/cFS/missionxyz$ git submodule upitdate --recursive
allen@akum-home-lt:~/repos/cFS/missionxyz$

[jphickey]

Yes, the definition of the secondary header did change recently. GSFC does not actually define this field as a uint16, it defines it as an 8-bit command code and 8-bit checksum, and the structure in the code was recently updated according to this definition.

Just double check to be sure you are running a matching commit in all submodules, and run a "make distclean" (or just fully remove your build dir) to be absolutely sure you aren't running an old binary somehow.

[skliper]

Probably still using the old cmdUtil executable. Note that cFS-GroundSystem looks for the compiled version of cmdUtil in cFS-GroundSystem/Subsystems/cmdUtil, so you need to rebuild it there.

[skliper]

Ticket nasa/cFS-GroundSystem#61 is open to remove the dependency of the python ground system on cmdUtil.

Edit - more descriptive

[atk5025]

I have confirmed this came from mismatched cmdUtil. I have been successful after deleting the build folder and rebuilding.