F Prime on arm926ej-s with FreeRTOS and OSAL implementation

[ginoscott]

F´ Version	v3.1.1 and v3.5.0
Affected Component	Cross-compiled Deployment with custom OSAL implementation

---

Problem Description

Hello F' team!
I'm currently working on implementing an OSAL for a version of FreeRTOS that has been provided to our team by the providers of the flight computer we've used in the past. Some past discussions on this topic and the Melbourne Space repo has been especially helpful with moving forward. I was able to use that repo as a starting point, replacing their FreeRTOS implementation with calls to my own FreeRTOS functions. I got it to compile and deployed it to the flight computer, which ran up to a point -- it got stuck at:

// myDeployment/Main.cpp
int main(int argc, char* argv[]) {
    ...
    myDeployment::setupTopology(inputs);
    ...
}
// ↓
// myDeployment/Top/myDeploymentTopology.cpp
void setupTopology(const TopologyState& state) {
    initComponents(state);
    ...
}
// ↓
// myDeploymentTopologyAc.cpp
void initComponents(const TopologyState& state) {
    myDeployment::blockDrv.init(QueueSizes::myDeployment_blockDrv, InstanceIds::myDeployment_blockDrv);
    ...
}
// ↓
// BlockDriverComponentAc.cpp
void BlockDriverComponentBase ::
    init(
        FwSizeType queueDepth,
        FwEnumStoreType instance
    )
    {
        ...
        this->m_BufferIn_InputPort[port].init(); // Gets stuck here. Doesn't seem to call init()?
        ...
    }
}

I've also tried to follow the examples in the F' repo with the new v3.5.0 way of implementing the OSAL. In the version using Melbourne's version above, I had replaced all the calls they used in that repo with my own FreeRTOS calls in the InterruptLock, IntervalTimer, Mutex, Queue, Task, and TaskId files. In this v3.5.0 version of my attempt, I'm using basically all of the stubs at the moment. However, I got stuck at the same location mentioned above. Also, it seems to be getting stuck at the port init() step of any of the components in the initComponents() function, not just the blockDrv's.

Compiling the deployment for native Linux does work with no problems, however.
I expect there's a lot I still need to tinker with to get right, but I'm not sure if I'd expect to face problems here.

Any ideas?

Context / Environment

Compiler: arm-none-eabi 10.3-2021.10
Target: arm926ej-s

Operating System: Linux
CPU Architecture: x86_64
Platform: Linux-6.8.0-47-generic-x86_64-with-glibc2.35
Python version: 3.10.12
CMake version: 3.22.1
Pip version: 24.3.1
Pip packages:
fprime-tools==3.5.0
fprime-gds==3.5.0
fprime-fpp-*==2.2.0`

[ginoscott]

Some additional insight, running:

readelf -s --wide myDeployment | c++filt | less

on the native Linux version shows:

847: 000000000002b87a    31 FUNC    GLOBAL DEFAULT   16 Drv::InputDataBufferPort::init()

while running the same command on the cross-compiled version doesn't seem to contain the Drv::InputDataBufferPort::init() function.
Turned out some compiler/linker flags in my toolchain was optimizing it out, so removing those did make Drv::InputDataBufferPort::init() show up in the output, but still appears to be stuck.
Will continue to look in to this.