TC(17,1) leaves the Python validation process, but the expected TM(17,2) does not return from the bare-metal Cortex-A53 in Renode. Follow the packet in both directions: Python encoder, host TCP stack, Renode socket endpoint, target ingress path, PUS-C service dispatch, telemetry encoder, and the same transport in reverse.
Where does the TC(17,1) request stop?
Start by assigning one observable to every hop. A successful TCP connection proves only that the client reached a listener. It does not prove that Renode transferred the bytes to the modeled target interface, that the flight software recognized a complete frame, or that Service 17 executed.
| Hop | Reading to take | Pass condition | Next check on failure |
|---|---|---|---|
| Python validation process | Encoded byte count and transmit timestamp | One complete type-prefixed request is submitted | Inspect the encoder and socket write result |
| Host TCP connection | Destination address, destination port, and connection state | The client connects to the intended Renode listener | Check listener configuration and process state |
| Renode endpoint | Received byte count | The count advances when Python transmits | Compare client and listener address/port settings |
| Target ingress | Receive-buffer or ingress-handler count | The target observes the same ordered byte sequence | Inspect the Renode-to-target interface mapping |
| PUS-C dispatch | Service and subtype selected by the decoder |
TC(17,1) reaches its handler |
Check framing, type selection, and dispatch logic |
| Return path | Generated and transmitted telemetry counts |
TM(17,2) reaches Python |
Trace the response from the first missing count |
Can the Python client reach the Renode listener?
Layer one first. For a virtual TCP path, the equivalent of a physical-layer check is confirming that both processes are running, the listener exists, and both ends use the same address and port. Read the configured values from the Python connection setup and the Renode configuration; no fixed address or port is inherent to TC(17,1).
| Setting | Python side | Renode side | Failure signature |
|---|---|---|---|
| Address | Connection destination | Listener bind address | Refused connection, timeout, or connection to the wrong endpoint |
| Port | Destination port | Listening port | No session reaches the intended listener |
| Connection lifecycle | Open, write, read, close sequence | Accept and disconnect events | Immediate close, stale session, or retry loop |
| Timing | Transmit and receive timestamps | Ingress and egress timestamps | A configured validation timeout expires before the reply arrives |
If the connection never opens, stay at this layer. If it opens and Renode's received-byte count advances, move to framing. A packet capture can separate connection failure from application failure: completed TCP exchange with application bytes shifts the fault boundary past the host network stack.
Do the TCP bytes form one complete protocol message?
TCP is an ordered byte stream; it does not preserve application-message boundaries. One socket write may arrive through several reads, and several writes may be returned by one read. A type-prefixed protocol therefore needs an explicit rule that tells the receiver when a complete message is available. The exact prefix layout and frame-length rule must match the encoder and decoder implemented by these repositories.
- Log the full encoded request length before the Python socket write.
- Record every write return value. Continue writing until the requested bytes have been accepted or report the transport failure.
- At the Renode endpoint and target ingress, record each received chunk length and the cumulative buffered length.
- Run the decoder only after its completion rule is satisfied. Retain an incomplete suffix for the next read.
- Compare the transmitted and received bytes exactly, including the type prefix and the fields that select
TC(17,1).
If the bytes differ, the failure is in transport adaptation or interface mapping. If they match but no message is dispatched, inspect the completion rule, prefix interpretation, and byte-order conversions used by the actual wire format. Unit tests of a direct encode-decode round trip do not test TCP fragmentation; add cases that feed the same frame one byte at a time and in multiple concatenated frames.
Does the target accept and dispatch TC(17,1)?
Place counters or trace points at the target's ingress callback, frame decoder, command classifier, service dispatcher, Service 17 handler, and telemetry queue. Use monotonic sequence numbers in the test log so repeated attempts cannot be mistaken for one another.
| Observed transition | Meaning | Next action |
|---|---|---|
| Ingress count does not change | Renode received data but did not deliver it to the target-visible interface | Check the modeled interface connection and target initialization |
| Ingress changes; decoder count does not | The receiver has incomplete or rejected framing | Compare raw bytes and decoder completion state |
| Decoder changes; dispatch does not | The decoded type, service, or subtype does not select the handler | Log decoded identifiers beside the transmitted identifiers |
| Handler enters; telemetry is not queued | The request reached Service 17, but response construction or queue submission failed | Inspect the handler exit path and queue result |
Keep transport status separate from protocol status. A connected socket can carry a malformed application frame, while a valid command can execute even if its response later becomes blocked on the return path.
Is TM(17,2) generated but lost on the return path?
Once the Service 17 handler runs, reverse the trace direction. Compare four readings: telemetry constructed, telemetry queued, bytes handed to the target transport, and bytes read by Python. The first counter that does not advance identifies the failing boundary.
If telemetry is queued but not transmitted, inspect scheduling, queue consumption, and the target transport's readiness state. If Renode transmits bytes but Python reports no message, record the client's raw receive chunks before decoding. Apply the same stream reassembly rule in both directions; a single recv call is not a message parser.
Measure timestamps at request submission, target ingress, handler entry, response queueing, and Python receipt. Compare the measured end-to-end interval with the timeout configured by the validation procedure. Increase a timeout only after proving that a valid response arrives late; a longer wait does not repair a missing listener, rejected frame, idle telemetry queue, or incomplete client-side reassembly.
How do you correct the failing branch and verify the path?
- Align the Python destination address and port with the active Renode listener.
- Confirm that the Renode endpoint is connected to the interface consumed by the bare-metal flight binary.
- Make both receivers accumulate TCP bytes until the type-prefixed wire protocol's actual completion rule is met.
- Handle partial socket writes and retain incomplete receive data between calls.
- Verify that the decoded service and subtype select
TC(17,1), then confirm that the handler queuesTM(17,2). - Trace the telemetry bytes through Renode and decode them in Python using the same framing discipline.
- Run repeated pings plus fragmented-input and concatenated-frame tests. Record per-hop counts, timestamps, procedure verdicts, and requirement-traceability results after the campaign.
FAQ
How do I tell whether TC(17,1) failed in TCP or flight software?
Compare the Python write count, Renode receive count, target ingress count, and Service 17 handler count. The first counter that fails to advance marks the boundary to inspect.
How do I choose the TCP address and port for Renode?
Read the listener bind address and listening port from the Renode configuration, then use those exact values as the Python destination. TC(17,1) does not define a TCP address or port.
How do I handle a TC frame split across TCP reads?
Append each received chunk to a persistent buffer and invoke the decoder only when the implemented frame-completion rule reports a full message. Preserve any incomplete bytes for the next read.
How do I verify the TC(17,1) ping/pong fix?
Run the Python procedure repeatedly and confirm one matching TM(17,2) reaches Python for each dispatched TC(17,1). Repeat with the request fragmented across reads and with multiple frames concatenated, then record passing per-hop counts, timestamps, procedure verdicts, and requirement-traceability results.