Running F prime GDS with custon Ref app in a Docker container

[secureshadow]

Hello!

I have ported successfully the Ref app to the SAMV7 board. I am running F prime inside a Docker container using the Dev container tool for VSCode, same as done by the Melbourne Space Program in their feat/osal branch.

I want now to run the Ref app with fprime-gds tool for this specific board, and this is the command I execute inside the Ref/ folder:

fprime-gds -d /workspaces/fprime/Ref/build-artifacts/FreeRTOS-samv --app /workspaces/fprime/Ref/build-artifacts/FreeRTOS-samv/bin/Ref --dictionary /workspaces/fprime/Ref/build-artifacts/FreeRTOS-samv/dict/RefTopologyAppDictionary.xml --ip-address 127.0.0.1 --ip-port 50002 --gui html --gui-addr 127.0.0.1 --gui-port 5000 --logs /workspaces/fprime/Ref/logs --log-to-stdout

And this is the error message I get:

[2024-06-10 18:32:33,751] [INFO] root: Logging system initialized!
[INFO] Ensuring comm[ip] Application is stable for at least 1 seconds
[INFO] Running Application: /tmp/fprime-venv/bin/python3
[2024-06-10 18:32:33,874] [INFO] root: Logging system initialized!
[2024-06-10 18:32:33,875] [INFO] comm: Starting uplinker/downlinker connecting to FSW using ip with fprime
[2024-06-10 18:32:33,875] [INFO] udp_handler: Server connected to 127.0.0.1:50002
[2024-06-10 18:32:33,876] [INFO] transport: Incoming binding to: ipc:///tmp/fprime-server-in
[2024-06-10 18:32:34,376] [INFO] transport: Outgoing binding to: ipc:///tmp/fprime-server-out
[INFO] Ensuring Ref Application is stable for at least 1 seconds
[INFO] Running Application: /workspaces/fprime/Ref/build-artifacts/FreeRTOS-samv/bin/Ref
[INFO] Log File: /workspaces/fprime/Ref/logs/2024_06_10-18_32_33/Ref.log
[ERROR] Failed to run application: /workspaces/fprime/Ref/build-artifacts/FreeRTOS-samv/bin/Ref -p 50002 -a 127.0.0.1. Error: /workspaces/fprime/Ref/build-artifacts/FreeRTOS-samv/bin/Ref stopped with code -4 sooner than 1 seconds.
[INFO] Shutting down F prime due to error. Failed to run Ref Application
[2024-06-10 18:32:36,880] [WARNING] tcp_handler: Failed to open socket at 127.0.0.1:50002, retrying: OSError: [Errno 22] Invalid argument

The Ref.log file is empty, and the comm.py.log file throws me this:

[2024-06-10 18:32:33,874] [INFO] root: Logging system initialized!
[2024-06-10 18:32:33,875] [INFO] comm: Starting uplinker/downlinker connecting to FSW using ip with fprime
[2024-06-10 18:32:33,875] [INFO] udp_handler: Server connected to 127.0.0.1:50002
[2024-06-10 18:32:33,876] [INFO] transport: Incoming binding to: ipc:///tmp/fprime-server-in
[2024-06-10 18:32:34,376] [INFO] transport: Outgoing binding to: ipc:///tmp/fprime-server-out
[2024-06-10 18:32:36,880] [WARNING] tcp_handler: Failed to open socket at 127.0.0.1:50002, retrying: OSError: [Errno 22] Invalid argument

I don't know if it is because my Ref app is not correct or because there is some problems when exposing the ports in the dev container in VSCode.
When I run the --no-app command and point to the custom dictionary path, I get the HTML GUI opened up, but I get a Red Cross meaning there is no connection (note that I am running fprime inside the dev container and accessing the HTML from my computer - outside of the dev container).

Find attached the devcontainer.json file I am using. If needed, I can probably upload the code to a repo.

Thanks in advance!
devcontainer.json

[LeStarch]

My guess from looking at this (and because Ref log is empty) is that your Ref application is not formatted right for the container you are running in. What happens if you run it directly:

/workspaces/fprime/Ref/build-artifacts/FreeRTOS-samv/bin/Ref -p 50002 -a 127.0.0.1

I'd expect there is some form of executable format error. In that case what does the following command return:

file /workspaces/fprime/Ref/build-artifacts/FreeRTOS-samv/bin/Ref

[secureshadow]

I cannot run the first command directly in the dev container, but I can the second one and this is the output I get from the file format I have:

/workspaces/fprime/Ref/build-artifacts/FreeRTOS-samv/bin/Ref: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, with debug_info, not stripped

This is an executable file for an ARM Cortex-M7 board (the ATSAMV71Q21) that will be used for a CubeSat. Can I run fprime-gds directly on this file or do I have to run the executable inside the board and connect the board via IP address to the GDS? I don't have this clear.

Also even if I run this command (the --no-app version of gds), using the path of the custom dictionary:

[/workspaces/fprime/Ref:devel:fprime-venv"][st3llar-dev🛰️ ] fprime-gds -n --dictionary /workspaces/fprime/Ref/build-artifacts/FreeRTOS-samv/dict/RefTopologyAppDictionary.xml 

I get the gds framework running:

[INFO] Ensuring comm[ip] Application is stable for at least 1 seconds
[INFO] Running Application: /tmp/fprime-venv/bin/python3
[INFO] Ensuring HTML GUI is stable for at least 2 seconds
[INFO] Running Application: /tmp/fprime-venv/bin/python3
Serving Flask app 'fprime_gds.flask.app'
Debug mode: off
[INFO] Launched UI at: http://127.0.0.1:5000/
[INFO] F prime is now running. CTRL-C to shutdown all components.

But if I go to the HTML GUI, it marks a red X as it cannot establish connection:

Note in the image that is is establishing the connection in the --gui-addr 127.0.0.1:5001 which is in port 5001, and my container is forwarding that to port 5000 (which is the one gds listening to):

So I don't know if it is a problem of being incorrectly forwarded or a problem that the Ref app is not being executed while using the GDS.

[LeStarch]

I think you are on the right track! The file cannot be run in the container, but must be run on the board. Therefore, you need to run the GDS as you said:

fprime-gds -n --dictionary /workspaces/fprime/Ref/build-artifacts/FreeRTOS-samv/dict/RefTopologyAppDictionary.xml 

Then run the file on the board and have it connect back to the GDS. Note: if you cannot supply command line arguments to the app when running on the board, then you likely need to hard code the address of the GDS and the port.

You also need to make sure there is a forward for port 50000 of the GDS as the board needs to connect to that port.

The RED X means the GDS is running and waiting for your connection from the board. Thus you need to make sure you have an Ethernet connection from the board to the computer, make sure the computer's firewall allows incoming connection, and that a port is forwarded into the container.

[LeStarch]

Also note: when working with network connections to hardware, we typically run with a "TcpServer" on the hardware, and connect the GDS as a client because this mitigates firewall and port-forwarding problems.

This can be seen in our LED blinker tutorial:

https://github.com/fprime-community/fprime-workshop-led-blinker

[secureshadow]

Okay thank you! Makes sense the binary cannot run inside the Docker since the executable if for a 32-bit ARM MCU and the container is running Ubuntu.
The confusion to me was due because GDS allows to specify a different build directory and app file other than the native one generated for Linux, but I guess this is if you are running in Posix instead of Linux or some other way.
It could be nice to add to GDS an ARM emulator (maybe an integration with QEMU) to be able to run the executable in a Docker container, the GDS in another and then try the connection without relying in having the hardware (for test purposes).
Thank you so much for the help!

[thomas-bc]

Note that you can run GDS in a container and FSW in another without emulation, you just need the correct binary format in the FSW container, the Python dependencies in the GDS one, and exposing the needed ports between the 2

[secureshadow]

Even if the executable file is for an ARM device? My question is how do I run the app I built for my specific MCU and be able to send commands to it using the GDS without having to buy the hardware. In that case, how do I run the app (the Ref binary)? Which command can I use to run it?
My ideas was to run GDS in a Docker container, the Ref app in another container and connect them using ports, but I don't know if I can run a 32-bit ARM executable in a Docker container, and if I do, what is the command to do so?
I don't know if I explain myself correctly.

[thomas-bc]

Oh I see. I know that there are ways to run QEMU within Docker, you'd have to look into if you can get your architecture in there. And then how to run a binary on there will really be a QEMU question, not F´ specific.

The GDS doesn't need to be modified, it only communicates through TCP/UART/etc. to FSW.
How FSW is ran, that is up to the user (QEMU et al. in your case)

Or did I miss your question?

[secureshadow]

No, that is right!

I was confused because the F prime GDS allows for specifying a path to a custom build folder and also a custom Ref app, that is why I thought it could run any binary file, but I think that option was if you have your Ref application for Linux/Posix is in another build directory or something.
The problem with QEMU and emulation is that my board is not supported and even if it is, it is not the same as running in the board, but it could serve as a preliminary analysis to run the GDS framework with my specific board and app.

[thomas-bc]

Understood! And yes you are correct, GDS is able to launch a native application only (e.g. Linux if on Linux, Darwin if on Mac etc.). The options are just here to help locate the binary if it's elsewhere on the filesystem.