how can a cFS app verify the contents of a table with a CRC

[PeanutTheDog]

On the ground, tblCRCTool can generate a CRC for the contents of a table, and on the satellite, Table Services can generate a (hopefully matching) CRC. However, the ground CRC isn't passed along with the table. How can I have my app automatically verify that the contents of a table in memory match the contents of the table as created on the ground? Having the Ground personnel do it "manually" by inspecting telemetry seems awkward. What am I missing?

[avan989]

I don't know of a built-in way to do this but why don't you just send a cmd with what the new CRC should be and then automatically validate the table against that.

[PeanutTheDog]

Thanks avan989, it seems that an approach with a manual step like you suggest is the only option at this time. Ideally, a file would be self-validating. I.e., include a CRC inside the file, so that an app can validate the contents at startup or when the table gets updated. I assume the CRC would need to be added by elf2cfetbl at file creation, since the compiler can't generate a self-referential CRC at compile time.

[avan989]

Why don’t you just add a checksum as an entries to the table itself that validate the contents. Then in your validation function, recalculate the checksum from the content and make sure it matches that checksum.

This doesn’t mean the content in the tables has been updated but it does ensure the table content is correct, which I think is what you want? Because adding an CRC doesn’t mean cfs knows it been updated either, it just mean the table hasn’t been corrupted.

[PeanutTheDog]

Why don’t you just add a checksum as an entries to the table itself that validate the contents.

Thanks avan989, this sentence in your reply contains the problem. How to calculate and add a CRC to the table itself? It's a cart-before-the-horse issue. The compiler can't do it, and elf2cfetbl doesn't do it. Apparently elf2cfetbl would need to be customized, but I was hoping that cFS had some method for accomplishing this that I just couldn't find. The need for this seems self-evident, but maybe I don't know enough yet about satellite operations.

[avan989]

If you take a step back and look at the packet level instead of the table, then a checksum is already included when u cfdp the table to the spacecraft.

[PeanutTheDog]

Thanks avan989, that's a good point, CFDP probably guarantees the file was received correctly, and maybe that's all that's needed. Ideally, however, the file contents would be self-verifying, so that whenever an app happens to read an updated file, its contents can be guaranteed to match what was generated on the ground. No cosmic ray bitflips, edge case escapes, copy errors before/after transmission, etc. Maybe I'm getting wrapped around the axle, but it seems intuitive.

[skliper]

@PeanutTheDog - I have poked a checksum into compiled objects in the past using the compiler toolchain. Basically defined a location for it in the code and set it to zero, got the location using nm, broke things apart w/ objcopy (might not need this for just tables/data, but I had different checksums on .text/.data/.confg), calculated and poked in w/ srec_cat, then recombined w/ srec_cat. All outside cFS. When I wanted to verify externally I verified each section checksummed to zero (when including the checksum).

[PeanutTheDog]

Thanks skliper, I was thinking something similar, in that the checksum + data could combine as zero; I've seen that done somewhere before. I'm thinking if we decide to pursue this, we'll have to do some sort of "outside cFS" custom workflow.