F Prime TCP Communication between 2 PI 5's: BufferSend Assertion Crash

[Mooze34]

Issue Summary

I am building a ground station to satellite simulation with two Raspberry Pi 5s using F Prime. I keep getting a consistent BufferSendPortAc.cpp:154 assertion that crashes the satellite deployment immediately when TCP connection is established.

System Architecture

┌─────────────┐    TCP     ┌──────────────┐
│ Ground      │◄──────────►│ Satellite    │
│ Station Pi  │            │ Pi           │
│             │            │              │
│ • GDS       │            │ • LED Blink  │
│ • TcpClient │            │ • TcpServer  │
└─────────────┘            └──────────────┘
       ▲
       │ HTTP
       ▼
┌─────────────┐
│ Laptop      │
│ Browser     │
└─────────────┘

The Problem

Expected: Commands flow from laptop → ground station → satellite → LED blinks
Actual: Satellite crashes with assertion the moment TCP connects

# Satellite Output:
Listening for single client at 0.0.0.0:50002
Accepted client at 0.0.0.0:50002
Assert: "BufferSendPortAc.cpp:154"
Assertion `0' failed.
Aborted

What I've Tried

• ✅ TCP connection works (Ground Station connects successfully)
• ✅ Commented out LED trigger code (assertion still happens)
• ✅ Used different ports (same issue)
• ✅ Verified all standard F Prime ports are connected
• ❌ Still crashes immediately on TCP connect

Component Overview

GroundStationManager

active component GroundStationManager {
    async command SEND_CUSTOM_COMMAND(customCommand: string size 80)
    
    # SUSPECTED ISSUE: These ports are defined but NOT connected
    output port satelliteOut: Fw.BufferSend
    async input port satelliteIn: Fw.BufferSend
}

SatelliteManager

active component SatelliteManager {
    async command GROUND_COMMAND(groundCmd: string size 80)
    output port ledBlink: Fw.Cmd  # Connected to LED component
}

LED Component

active component Led {
    async command BLINK_LED()
    async input port ledTrigger: Fw.Cmd  # Receives from SatelliteManager
    output port gpioSet: Drv.GpioWrite   # Connected to GPIO driver
}

Key Topology Connections

SatelliteDeployment (TcpServer)

connections Uplink {
    comm.$recv -> uplink.framedIn
    uplink.comOut -> cmdDisp.seqCmdBuff
    cmdDisp.seqCmdStatus -> uplink.cmdResponseIn
}

connections SatelliteConnections {
    satelliteManager.ledBlink -> led.ledTrigger  # Connected
    led.gpioSet -> gpioDriver.gpioWrite          # Connected
}

GroundStationDeployment (TcpClient)

connections SatelliteComm {
    downlink.framedOut -> comm.$send
    comm.$recv -> uplink.framedIn
    uplink.comOut -> cmdDisp.seqCmdBuff
}

# MISSING: No connections for groundStationManager.satelliteOut/In

Specific Questions

1. Root Cause: What triggers a BufferSend assertion during TCP connection establishment?

2. Port Pattern: Should GroundStationManager.satelliteOut/In be:

   • Connected to the TCP stack? (How?)
   • Removed entirely? (Component doesn't use them)
   • Left unconnected? (Current state causing crash?)

3. Command Flow: What's the correct F Prime pattern for:

   GDS Command → TCP → Remote Component Command
   

4. Debugging: How to identify which specific port triggers BufferSendPortAc.cpp:154?

Error Timeline

1. SatelliteDeployment starts  ✅
2. GroundStationDeployment starts  ✅  
3. TCP connection established  ✅
4. BufferSend assertion  ❌ CRASH

Environment

• F Prime: 3.6.3
• Hardware: Raspberry Pi 5 (both units)
• Network: WiFi
• Build: fprime-util build (native Linux)

Repository

Source Code: https://github.com/TeraLink-1/TeraLink-Link/tree/Mustafa

Components/
├── GroundStationManager/    # Has unconnected Fw.BufferSend ports
├── SatelliteManager/        # Uses Fw.Cmd ports (working)
└── Led/                     # Uses Fw.Cmd ports (working)

GroundStationDeployment/Top/
├── topology.fpp            # TcpClient configuration
└── instances.fpp

SatelliteDeployment/Top/
├── topology.fpp            # TcpServer configuration  
└── instances.fpp

Looking For

• Guidance on F Prime TCP communication patterns between two PIs
• How to properly handle custom component communication over TCP
• Whether unconnected Fw.BufferSend ports can cause assertions
• Best practices for pi-to-pi F Prime deployments

Any help debugging this BufferSend assertion would be hugely appreciated!

[thomas-bc]

Can you open BufferSendPortAc.cpp:154 (should be under build-fprime.../F-Prime/...) and look at the specific code/assertion that triggers this? It's sometimes telling. If not, I'd run a debugger and look at the call stack when the assertion occurs.

[Mooze34]

Here are the contents of BufferSendPortAc.cpp:

// ======================================================================
// \title  BufferSendPortAc.cpp
// \author Generated by fpp-to-cpp
// \brief  cpp file for BufferSend port
// ======================================================================

#include "F-Prime/Fw/Buffer/BufferSendPortAc.hpp"
#include "Fw/Types/Assert.hpp"
#include "Fw/Types/ExternalString.hpp"

namespace Fw {

  namespace {

    // ----------------------------------------------------------------------
    // Port buffer class
    // ----------------------------------------------------------------------

    class BufferSendPortBuffer : public Fw::SerializeBufferBase {

      public:

        Fw::Serializable::SizeType getBuffCapacity() const {
          return InputBufferSendPort::SERIALIZED_SIZE;
        }

        U8* getBuffAddr() {
          return m_buff;
        }

        const U8* getBuffAddr() const {
          return m_buff;
        }

      private:

        U8 m_buff[InputBufferSendPort::SERIALIZED_SIZE];

    };

  }

  // ----------------------------------------------------------------------
  // Input Port Member functions
  // ----------------------------------------------------------------------

  InputBufferSendPort ::
    InputBufferSendPort() :
      Fw::InputPortBase(),
      m_func(nullptr)
  {

  }

  void InputBufferSendPort ::
    init()
  {
    Fw::InputPortBase::init();
  }

  void InputBufferSendPort ::
    addCallComp(
        Fw::PassiveComponentBase* callComp,
        CompFuncPtr funcPtr
    )
  {
    FW_ASSERT(callComp != nullptr);
    FW_ASSERT(funcPtr != nullptr);

    this->m_comp = callComp;
    this->m_func = funcPtr;
    this->m_connObj = callComp;
  }

  void InputBufferSendPort ::
    invoke(Fw::Buffer& fwBuffer)
  {
#if FW_PORT_TRACING == 1
    this->trace();
#endif

    FW_ASSERT(this->m_comp != nullptr);
    FW_ASSERT(this->m_func != nullptr);

    return this->m_func(this->m_comp, this->m_portNum, fwBuffer);
  }

#if FW_PORT_SERIALIZATION == 1

  Fw::SerializeStatus InputBufferSendPort ::
    invokeSerial(Fw::SerializeBufferBase& _buffer)
  {
    Fw::SerializeStatus _status;

#if FW_PORT_TRACING == 1
    this->trace();
#endif

    FW_ASSERT(this->m_comp != nullptr);
    FW_ASSERT(this->m_func != nullptr);

    Fw::Buffer fwBuffer;
    _status = _buffer.deserialize(fwBuffer);
    if (_status != Fw::FW_SERIALIZE_OK) {
      return _status;
    }

    this->m_func(this->m_comp, this->m_portNum, fwBuffer);

    return Fw::FW_SERIALIZE_OK;
  }

#endif

  // ----------------------------------------------------------------------
  // Output Port Member functions
  // ----------------------------------------------------------------------

  OutputBufferSendPort ::
    OutputBufferSendPort() :
      Fw::OutputPortBase(),
      m_port(nullptr)
  {

  }

  void OutputBufferSendPort ::
    init()
  {
    Fw::OutputPortBase::init();
  }

  void OutputBufferSendPort ::
    addCallPort(InputBufferSendPort* callPort)
  {
    FW_ASSERT(callPort != nullptr);

    this->m_port = callPort;
    this->m_connObj = callPort;

#if FW_PORT_SERIALIZATION == 1
    this->m_serPort = nullptr;
#endif
  }

  void OutputBufferSendPort ::
    invoke(Fw::Buffer& fwBuffer) const
  {
#if FW_PORT_TRACING == 1
    this->trace();
#endif

#if FW_PORT_SERIALIZATION
    FW_ASSERT((this->m_port != nullptr) || (this->m_serPort != nullptr));

    if (this->m_port != nullptr) {
      this->m_port->invoke(fwBuffer);
    }
    else {
      Fw::SerializeStatus _status;
      BufferSendPortBuffer _buffer;

      _status = _buffer.serialize(fwBuffer);
      FW_ASSERT(_status == Fw::FW_SERIALIZE_OK, static_cast(_status));

      _status = this->m_serPort->invokeSerial(_buffer);
      FW_ASSERT(_status == Fw::FW_SERIALIZE_OK, static_cast(_status));
    }
#else
    FW_ASSERT(this->m_port != nullptr);
    this->m_port->invoke(fwBuffer);
#endif
  }

}

I've never dealt with manipulating the auto generated cpp files fprime generates, so any assistance would be greatly appreciated

[thomas-bc]

The issue as you've mentioned seems to be that you have unconnected ports that are being invoked. You need to either connect them or prevent them from being invoked.

[Mooze34]

Ground Station Setup: RPi Deployment + GDS Access

TCP handshake was accepted — thank you for the help!
Now I have a new small issue.

Goal

I want the Raspberry Pi (RPi) to:

1. Run the deployment (i.e., start the groundstation-side services), and
2. Open the Ground Data System (GDS) on an open port,
3. So that I can connect from my laptop using the GDS to control the system.

Diagram

Problem

How can I open the GDS and run the deployment on the RPi simultaneously on a specific port, allowing remote access from my laptop?

[thomas-bc]

On Pi2 which has the "ground deployment", you can run fprime-gds --gui-port xyz which will expose the web server on localhost:xyz. Then you may need to figure out the firewall situation so that your laptop can access the webserver on Pi2 at IP_PI2:xyz

But again I must ask, why run the GDS on Pi2 You could run the GDS on your laptop and connect to FSW on Pi2 ?

[Mooze34]

Thank you for the input. I guess my whole point is that I want this demo to be as close to a real satellite ground station setup as possible.

(From what I understand) In actual satellite operations, the ground station computer runs both the ground station FSW and the mission control interface, with operators connecting remotely via web browsers. This provides operational resilience (ground station operates independently of individual operator connections) and multi-operator support. Running fprime-gds on my laptop would be more like a lab setup - fine for F' development, but it doesn't represent how satellite ground stations actually work in practice where the mission control interface is co-located with the ground station equipment.

However I am very new to cubesat development if I am completely wrong please let me know

[thomas-bc]

I am not sure I am following the intent here. I'll let others chime in, maybe I'm misunderstanding something.

A basic cubesat operations scenario would be a RaspberryPi is running a "Flight Software" (FSW) deployment, and it's controlled remotely by a Ground Station (or GDS for Ground Data Systems). The GDS could have lots of different components (UI, databases, etc), but no FSW there (maybe in a simulation engine but I don't think that's what you mean).

When the F´ GDS starts up Flight software (when running fprime-gds), it's a mere shortcut for testing FSW on your laptop. If you were to ever use fprime-gds for operations (not recommended, it's meant to be a testing tool), you'd run fprime-gds -n which prevents it from starting up FSW, and you're expected to start up FSW on your own on the satellite, for example on a RaspberryPi.

The LedBlinker tutorial is a good overview of that scenario https://fprime.jpl.nasa.gov/latest/tutorials-led-blinker/docs/led-blinker/