Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
15 commits
Select commit Hold shift + click to select a range
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions Svc/Ccsds/CcsdsSdlsFramer/CcsdsSdlsFramer.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -7,11 +7,15 @@
#include "Svc/Ccsds/CcsdsSdlsFramer/CcsdsSdlsFramer.hpp"

#include <Fw/Prm/ParamValid.hpp>
#include "Svc/Ccsds/Types/FppConstantsAc.hpp"

namespace Svc {

namespace Ccsds {

static_assert(sizeof(decltype(ComCfg::FrameContext().get_saIndex())) == SdlsSaIndexSize,
"Svc.Ccsds.SdlsSaIndexSize must match the prepended SA index");

// ----------------------------------------------------------------------
// Component construction and destruction
// ----------------------------------------------------------------------
Expand Down
2 changes: 1 addition & 1 deletion Svc/Ccsds/SpacePacketFramer/docs/sdd.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ The `Svc::Ccsds::SpacePacketFramer` is an implementation of the [FramerInterface

It receives user data on its input port and constructs a CCSDS Space Packet. Please refer to the CCSDS [Space Packet Protocol specification (CCSDS 133.0-B-2)](https://ccsds.org/Pubs/133x0b2e2.pdf) for details on the packet format.

The `Svc::Ccsds::SpacePacketFramer` is typically used upstream of a component that adds transfer frame headers, such as the `Svc::Ccsds::TmFramer`. It encapsulates user data into a Space Packet, adding the necessary header fields.
The `Svc::Ccsds::SpacePacketFramer` is typically used upstream of `Svc::ComAggregator`, which packs Space Packets into fixed-size, idle-filled aggregates for a component that adds transfer frame headers, such as the `Svc::Ccsds::TmFramer`. It encapsulates user data into a Space Packet, adding the necessary header fields.

## Configuration
The `Svc::Ccsds::SpacePacketFramer` requires an Application Process Identifier (APID) for the Space Packets it generates. This APID is typically provided during instantiation or configuration. It also uses a sequence count, which is managed per APID via the `getApidSeqCount` port.
Expand Down
26 changes: 2 additions & 24 deletions Svc/Ccsds/TmFramer/TmFramer.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,6 @@

#include "Svc/Ccsds/TmFramer/TmFramer.hpp"
#include "Svc/Ccsds/Utils/CRC16.hpp"
#include "Svc/Ccsds/Utils/IdlePacket.hpp"
#include "config/FppConstantsAc.hpp"

namespace Svc {
Expand All @@ -27,10 +26,8 @@ TmFramer ::~TmFramer() {}
// ----------------------------------------------------------------------

void TmFramer ::dataIn_handler(FwIndexType portNum, Fw::Buffer& data, const ComCfg::FrameContext& context) {
FW_ASSERT(data.getSize() <= TmPayloadCapacity, static_cast<FwAssertArgType>(data.getSize()));
// The data must either fill the data field exactly or leave room for a minimum idle packet (4.2.2.5)
const FwSizeType residual = TmPayloadCapacity - data.getSize();
FW_ASSERT(residual == 0 || residual >= Utils::IdlePacket::MIN_SIZE, static_cast<FwAssertArgType>(residual));
// The data must fill the data field exactly: idle filling (Standard 4.2.2.5) is done upstream by Svc::ComAggregator
FW_ASSERT(data.getSize() == TmPayloadCapacity, static_cast<FwAssertArgType>(data.getSize()));

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[Security] could fix ground-reachable-assert (narrowed tolerance). This assert now requires an exact size where the previous check accepted any size leaving 0 or >= IdlePacket::MIN_SIZE residual. In the ComCcsdsSdls path data.getSize() is the encryptor output plus the SA index, and the encryptor is selected by SdlsSaRouter from the SA index, which CcsdsSdlsFramer takes from the ground-settable SA_INDEX parameter when the context leaves it unset. A deployment with more than one SA whose encryptors differ in per-frame overhead (e.g. clear-text vs. AES-GCM +28) turns a SA_INDEX parameter update into a guaranteed assert on the next frame, where the smaller-overhead direction was previously tolerated. The constraint is only documented in the SDLS sdd, not enforced. Consider dropping the frame with an event (returning data and signalling comStatusOut) instead of asserting, or validating the size where the SA is resolved.

cc @LeStarch @thomas-bc @bitWarrior — low-confidence finding, please confirm.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[Design] Concur — also in scope for design intent: the PR states invalid sizing fails at compile time or in configComponents, but with any encryptor that adds per-frame overhead the ComCcsdsSdls static_assert (<=) cannot establish the exact fit, so this runtime assert on the first frame is the only enforcement; consider having the SDLS layer expose its overhead so the fit is checked at configuration.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[Operational] Concur — also in scope for configuration extremes: in the plain ComCcsds TM stack any Aggregator.aggregationSize below 1016 (e.g. an SDLS value of 1014/986 carried into a non-SDLS build) passes the <= static_assert and aborts the FSW here on the first frame, where the previous framer tolerated any residual of 0 or >= 7; the ComCcsdsConfig.Aggregator.aggregationSize comment should state "must equal Svc.Ccsds.TmDataFieldSize exactly unless a layer between aggregator and TmFramer adds bytes".

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Confirmed and intentionally kept as an assert for now. On a fixed-size TM frame, a stack whose SAs map to encryptors with different per-frame overhead cannot produce valid frames for both SAs whatever the aggregator does; before this PR the shorter case "worked" only because TmFramer appended an unauthenticated plaintext idle packet after the ciphertext (#5779). Documented in 97cad9b (ComCcsdsSdls SDD, ComCcsdsConfig): all encryptors behind SdlsSaRouter must share one overhead. If maintainers prefer a graceful drop (return + comStatusOut + event) over the assert I can change it in this PR; otherwise padding inside the SDLS layer is the proper fix for mixed-overhead SAs and belongs in a follow-up.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[Security] Disagreement — escalating. I still flag this on 028da83; the contributor's response above indicates we disagree.

Re-checked the full TmFramer.cpp and the SDLS path on this head: the exact-size FW_ASSERT is unchanged and SA_INDEX is still a ground-settable parameter, so a mixed-overhead SA set turns a parameter update into an FSW abort. I accept that mixed-overhead SAs cannot produce valid fixed-size frames either way, and that this is now documented; my concern is only that the failure mode for a ground-reachable input is an assert rather than a dropped frame with an event.

cc @LeStarch @thomas-bc @bitWarrior — needs human adjudication.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[Design] Disagreement — escalating. I still flag this on 028da83; the contributor's response above indicates we disagree.

Re-checked on this head: ComCcsds.fpp and ComCcsdsSdls.fpp both bound aggregationSize with <=, so nothing in the build establishes the exact fit the framer requires; a mis-sized deployment still only fails as a runtime assert on the first frame. The documented "all encryptors behind SdlsSaRouter share one overhead" rule is sound and I accept the mixed-SA padding deferral — whether the remaining enforcement should stay an assert, become a graceful drop, or move to a configuration-time check once the SDLS layer exposes its overhead, is a design-owner call.

cc @LeStarch @thomas-bc — needs human adjudication.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[Operational] Fixed in 028da83.

FW_ASSERT(context.get_firstHeaderPointer() <= TMSubfields::fhpMask,
static_cast<FwAssertArgType>(context.get_firstHeaderPointer()));
FW_ASSERT(this->m_bufferState == BufferOwnershipState::OWNED, static_cast<FwAssertArgType>(this->m_bufferState));
Expand Down Expand Up @@ -74,12 +71,6 @@ void TmFramer ::dataIn_handler(FwIndexType portNum, Fw::Buffer& data, const ComC
status = frameSerializer.serializeFrom(data.getData(), data.getSize(), Fw::Serialization::OMIT_LENGTH);
FW_ASSERT(status == Fw::FW_SERIALIZE_OK, status);

// As per TM Standard 4.2.2.5, fill the rest of the data field with an Idle Packet.
// A full data field (e.g. delivered by a spanning aggregator) requires no fill.
if (residual > 0) {
this->fill_with_idle_packet(frameSerializer);
}

// -------------------------------------------------
// Trailer (CRC)
// -------------------------------------------------
Expand Down Expand Up @@ -114,18 +105,5 @@ void TmFramer ::dataReturnIn_handler(FwIndexType portNum,
FW_ASSERT(frameBuffer.getData() < &this->m_frameBuffer[0] + sizeof(this->m_frameBuffer));
this->m_bufferState = BufferOwnershipState::OWNED;
}

void TmFramer ::fill_with_idle_packet(Fw::SerialBufferBase& serializer) {
constexpr FwSizeType endIndex = ComCfg::TmFrameFixedSize - TMTrailer::SERIALIZED_SIZE;
const FwSizeType startIndex = serializer.getSize();
FW_ASSERT(startIndex <= endIndex, static_cast<FwAssertArgType>(startIndex));
const FwSizeType idlePacketSize = endIndex - startIndex;

FW_ASSERT(idlePacketSize >= Utils::IdlePacket::MIN_SIZE, static_cast<FwAssertArgType>(idlePacketSize));
FW_ASSERT(idlePacketSize <= ComCfg::TmFrameFixedSize, static_cast<FwAssertArgType>(idlePacketSize));

const Fw::SerializeStatus status = Utils::IdlePacket::serialize(serializer, idlePacketSize);
FW_ASSERT(status == Fw::FW_SERIALIZE_OK, status);
}
} // namespace Ccsds
} // namespace Svc
36 changes: 9 additions & 27 deletions Svc/Ccsds/TmFramer/TmFramer.hpp
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,6 @@

#include "Svc/Ccsds/TmFramer/TmFramerComponentAc.hpp"
#include "Svc/Ccsds/Types/FppConstantsAc.hpp"
#include "Svc/Ccsds/Types/SpacePacketHeaderSerializableAc.hpp"
#include "Svc/Ccsds/Types/TMHeaderSerializableAc.hpp"
#include "Svc/Ccsds/Types/TMTrailerSerializableAc.hpp"

Expand All @@ -23,21 +22,13 @@ class TmFramer final : public TmFramerComponentBase {
static_assert(ComCfg::TmFrameFixedSize > TMHeader::SERIALIZED_SIZE + TMTrailer::SERIALIZED_SIZE,
"TM Frame Fixed Size must be at least large enough to hold header, trailer and data");

static constexpr FwSizeType TmPayloadCapacity =
ComCfg::TmFrameFixedSize - (TMHeader::SERIALIZED_SIZE + TMTrailer::SERIALIZED_SIZE);
static constexpr FwSizeType SppOverhead = (2 * SpacePacketHeader::SERIALIZED_SIZE) + 1;
static_assert(static_cast<FwSizeType>(TMHeader::SERIALIZED_SIZE) == static_cast<FwSizeType>(TmHeaderSize),
"Svc.Ccsds.TmHeaderSize must match TMHeader");
static_assert(static_cast<FwSizeType>(TMTrailer::SERIALIZED_SIZE) == static_cast<FwSizeType>(TmTrailerSize),
"Svc.Ccsds.TmTrailerSize must match TMTrailer");

// These are to ensure the frame can hold the packet buffer, its SP header and an idle packet of 1 byte
// This is because TM specifies a frame to be padded with an idle packet of at least 1 byte of idle data
static_assert(TmPayloadCapacity >= FW_COM_BUFFER_MAX_SIZE + SppOverhead,
"TM Frame Fixed Size must be at least large enough to hold Tm Header + Footer, a full com buffer, 2 "
"SP headers, and 1 idle byte");
static_assert(TmPayloadCapacity >= FW_FILE_BUFFER_MAX_SIZE + SppOverhead,
"TM Frame Fixed Size must be at least large enough to hold Tm Header + Footer, a full file buffer, 2 "
"SP headers, and 1 idle byte");

static_assert(static_cast<FwSizeType>(ComCfg::AggregationSize) <= TmPayloadCapacity,
"ComCfg::AggregationSize must fit in the TM data field");
//! Size of the frame data field: every dataIn payload must be exactly this size
static constexpr FwSizeType TmPayloadCapacity = static_cast<FwSizeType>(TmDataFieldSize);

enum class BufferOwnershipState {
NOT_OWNED, //!< The buffer is currently not owned by the TmFramer
Expand Down Expand Up @@ -71,9 +62,9 @@ class TmFramer final : public TmFramerComponentBase {

//! Handler implementation for dataIn
//!
//! Port to receive data to frame, in a Fw::Buffer with optional context.
//! This is essentially the CCSDS TM VCP.request Service Primitive, with
//! Packet=data and GVCID implicitly passed in context (TM Protocol 3.3.3.2)
//! Port to receive a complete frame data field to frame, in a Fw::Buffer with optional context.
//! The buffer must be exactly TmPayloadCapacity bytes (idle-filled upstream, e.g. by Svc::ComAggregator);
//! any other size asserts. GVCID and the First Header Pointer are passed in the context.
//!
void dataIn_handler(FwIndexType portNum, //!< The port number
Fw::Buffer& data,
Expand All @@ -86,15 +77,6 @@ class TmFramer final : public TmFramerComponentBase {
Fw::Buffer& data,
const ComCfg::FrameContext& context) override;

// ----------------------------------------------------------------------
// Helpers
// ----------------------------------------------------------------------
private:
//! Fill the frame buffer with an Idle Packet to complete the frame data field
//! as per CCSDS TM Protocol paragraph 4.2.2.5. Idle packet is inserted at the
//! start_index index of the frame buffer, and fills it up to the end minus CRC
void fill_with_idle_packet(Fw::SerialBufferBase& serializer);

// ----------------------------------------------------------------------
// Members
// ----------------------------------------------------------------------
Expand Down
17 changes: 7 additions & 10 deletions Svc/Ccsds/TmFramer/docs/sdd.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,24 +2,21 @@

The `Svc::Ccsds::TmFramer` is an implementation of the [FramerInterface](../../../Interfaces/docs/sdd.md) for the CCSDS [TM Space Data Link Protocol](https://ccsds.org/Pubs/132x0b3.pdf).

It receives payload data (such as a Space Packet or a VCA_SDU) on input and produces a TM frame on its output port as a result. Please refer to the CCSDS [TM specification (CCSDS 132.0-B-3)](https://ccsds.org/Pubs/132x0b3.pdf) for details on the frame format and protocol.
It receives a complete TM Transfer Frame Data Field (`Svc.Ccsds.TmDataFieldSize` bytes, produced by an upstream [`Svc::ComAggregator`](../../../ComAggregator/docs/sdd.md)) on input and produces a TM frame on its output port as a result. Please refer to the CCSDS [TM specification (CCSDS 132.0-B-3)](https://ccsds.org/Pubs/132x0b3.pdf) for details on the frame format and protocol.

The `Svc::Ccsds::TmFramer` is designed to work in the common F Prime telemetry stack, receiving data from an upstream [`Svc::ComQueue`](../../../ComQueue/docs/sdd.md) and passing frames to a [Communications Adapter](../../../Interfaces/docs/sdd.md), such as a Radio manager component or [`Svc::ComStub`](../../../ComStub/docs/sdd.md), for transmission on the wire. It is commonly coupled with the [`Svc::Ccsds::SpacePacketFramer`](../../SpacePacketFramer/docs/sdd.md) to wrap CCSDS Space Packets into TM frames.
The `Svc::Ccsds::TmFramer` is designed to work in the common F Prime telemetry stack, receiving complete, idle-filled data fields from an upstream [`Svc::ComAggregator`](../../../ComAggregator/docs/sdd.md) and passing frames to a [Communications Adapter](../../../Interfaces/docs/sdd.md), such as a Radio manager component or [`Svc::ComStub`](../../../ComStub/docs/sdd.md), for transmission on the wire. It is commonly coupled with the [`Svc::Ccsds::SpacePacketFramer`](../../SpacePacketFramer/docs/sdd.md) to wrap CCSDS Space Packets into TM frames.

## Internals

The TM protocol specifies a fixed frame size. This can be configured in the `config/ComCfg.fpp` file.

The `Svc::Ccsds::TmFramer` uses an internal (member) buffer to hold the fixed size frame. The buffer **must** be returned to the TmFramer via the `dataReturnIn` port once it has been used or consumed. When the buffer returns to the TmFramer it will reuse the buffer for the next frame. Should a component want to use the frame data past the time it is returned to the TmFramer, data should be copied before the original buffer is returned to the TmFramer via the `dataReturnIn` port.

The static sizing checks enforce that `ComCfg::AggregationSize` fits in the TM data field. The residual rule is
enforced at runtime in `dataIn_handler`, deterministically on the first frame if the configuration is misconfigured.

The data received on `dataIn` must either fill the frame data field exactly (e.g. when delivered by `Svc::ComAggregator` with packet spanning enabled) or leave at least 7 bytes (a Space Packet header plus one byte of idle data) so that the remainder can be filled with an Idle Packet as required by the protocol (4.2.2.5). Any other size is rejected by assertion. `ComCfg::AggregationSize` is the full TM data field available to `Svc::ComAggregator`; with spanning disabled, the maximum aggregate is `ComCfg::AggregationSize - 7`, while spanning-enabled aggregates fill the field exactly. Any intermediate layer that adds bytes (e.g. the 2-byte SA index of `Svc::Ccsds::CcsdsSdlsFramer`) must be subtracted from `ComCfg::AggregationSize` by the project.
The `Svc::Ccsds::TmFramer` is a pure frame layer: the data received on `dataIn` must fill the frame data field exactly (`Svc.Ccsds.TmDataFieldSize`, i.e. `ComCfg.TmFrameFixedSize` minus the 6-byte primary header and 2-byte trailer) and is copied into the frame unchanged. Any other size is rejected by assertion, deterministically on the first frame when the upstream stack is misconfigured. Idle filling of the data field (protocol 4.2.2.5) is the responsibility of the upstream [`Svc::ComAggregator`](../../../ComAggregator/docs/sdd.md), which emits aggregates of exactly its configured size; this keeps idle data upstream of any layer inserted between the aggregator and the framer, such as `Svc::Ccsds::CcsdsSdlsFramer`, whose added bytes (`Svc.Ccsds.SdlsSaIndexSize`) the project subtracts from the aggregation size.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[Documentation] could fix Intro (line 7) still describes TmFramer as "receiving data from an upstream Svc::ComQueue"

(Anchored below the offending line; the diff does not include line 7.)

With this PR dataIn_handler asserts unless the payload is exactly Svc.Ccsds.TmDataFieldSize, so a ComQueue/SpacePacketFramerTmFramer stack as described in the intro now asserts on the first frame; only Svc::ComAggregator (or an equivalent idle-filling stage) can feed dataIn. Suggest rewording line 7 to "receiving fixed-size aggregates from an upstream Svc::ComAggregator" so the intro agrees with the Internals paragraph.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in 97cad9b.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[Documentation] Fixed in 028da83.


## Usage Examples

The `Svc::Ccsds::TmFramer` component, as well as the rest of the CCSDS communications stack, is used in the [`Ref/`](https://github.com/nasa/fprime/tree/devel/Ref) example application. It is also generated by the `fprime-util new --deployment` command.
The `Svc::Ccsds::TmFramer` component, as well as the rest of the CCSDS communications stack, is used in the [`Ref/`](https://github.com/nasa/fprime/tree/devel/TestDeploymentsProject/Ref) example application. It is also generated by the `fprime-util new --deployment` command.

## CCSDS Header Fields

Expand Down Expand Up @@ -57,7 +54,7 @@ For each frame generated, the `Svc::Ccsds::TmFramer` will populate the CCSDS TM
| SVC-Ccsds-TM-FRAMER-001 | The TmFramer shall implement the `Svc.FramerInterface`. | Inspection, Unit Test |
| SVC-Ccsds-TM-FRAMER-002 | The TmFramer shall construct CCSDS Telemetry (TM) Transfer Frames compliant with the CCSDS 132.0-B-3 standard. | Unit Test, Inspection |
| SVC-Ccsds-TM-FRAMER-002 | The TmFramer shall use a fixed frame size that is configurable by the project. | Unit Test, Inspection |
| SVC-Ccsds-TM-FRAMER-003 | The TmFramer shall accept payload data (Space Packets or VCA_SDU) to be framed via its `dataIn` port. | Unit Test |
| SVC-Ccsds-TM-FRAMER-003 | The TmFramer shall accept a complete frame data field of exactly `Svc.Ccsds.TmDataFieldSize` bytes to be framed via its `dataIn` port, and shall assert on any other size. | Unit Test |
| SVC-Ccsds-TM-FRAMER-004 | The TmFramer shall output the constructed TM Transfer Frame via its `dataOut` port. | Unit Test |
| SVC-Ccsds-TM-FRAMER-005 | The TmFramer shall return ownership of the input buffer via the `dataReturnOut` port after the framing process is complete. | Unit Test |
| SVC-Ccsds-TM-FRAMER-006 | The TmFramer shall accept returned buffers (previously sent via `dataOut`) through the `dataReturnIn` port for deallocation or reuse. | Unit Test |
Expand All @@ -67,6 +64,6 @@ For each frame generated, the `Svc::Ccsds::TmFramer` will populate the CCSDS TM
| SVC-Ccsds-TM-FRAMER-010 | The TmFramer shall be configurable with a Spacecraft Identifier. | Inspection, Unit Test |
| SVC-Ccsds-TM-FRAMER-011 | The TmFramer shall use the Virtual Channel Identifier passed in the `context` object on `dataIn`. | Unit Test |
| SVC-Ccsds-TM-FRAMER-012 | The TmFramer shall manage Master Channel Frame Count and Virtual Channel Frame Count. | Unit Test |
| SVC-Ccsds-TM-FRAMER-013 | The TmFramer shall fill the data field of the TM Transfer Frame with the payload data received on `dataIn`, and fill up the rest of the fixed-size frame with a single Idle Packet as defined by the protocol. When the payload data fills the data field exactly, no Idle Packet shall be inserted. | Unit Test |
| SVC-Ccsds-TM-FRAMER-014 | The TmFramer shall assert that payload data received on `dataIn` either fills the data field exactly or leaves room for a minimum Idle Packet (header plus one byte). | Unit Test |
| SVC-Ccsds-TM-FRAMER-013 | The TmFramer shall fill the data field of the TM Transfer Frame with the payload data received on `dataIn`, unchanged. | Unit Test |
| SVC-Ccsds-TM-FRAMER-014 | The TmFramer shall assert that payload data received on `dataIn` fills the data field exactly. | Unit Test |
| SVC-Ccsds-TM-FRAMER-015 | The TmFramer shall assert that the First Header Pointer received in the `dataIn` context fits within the 11-bit First Header Pointer field. | Unit Test |
9 changes: 2 additions & 7 deletions Svc/Ccsds/TmFramer/test/ut/TmFramerTestMain.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -41,14 +41,9 @@ TEST(TmFramer, testFirstHeaderPointerFromContext) {
tester.testFirstHeaderPointerFromContext();
}

TEST(TmFramer, testResidualTooSmallForIdlePacket) {
TEST(TmFramer, testPartialDataFieldAsserts) {
Svc::Ccsds::TmFramerTester tester;
tester.testResidualTooSmallForIdlePacket();
}

TEST(TmFramer, testFullDataFieldNoIdleFill) {
Svc::Ccsds::TmFramerTester tester;
tester.testFullDataFieldNoIdleFill();
tester.testPartialDataFieldAsserts();
}

int main(int argc, char** argv) {
Expand Down
Loading
Loading