Fix: Move AntennaDeployer file system initialization from constructor to init()

[Copilot]

File system operations in AntennaDeployer's constructor ran before the file system was ready on RP2350, causing unstable behavior at boot.

Description

Root cause: AntennaDeployer::AntennaDeployer() was calling Os::FileSystem::createDirectory and Os::File::open directly. On Zephyr/RP2350, constructors execute before the file system is mounted.

Fix: Moved all file system operations into a new init() method, consistent with the pattern already used by ModeManager and Authenticate.

// Before — file ops in constructor (unsafe)
AntennaDeployer::AntennaDeployer(const char* compName)
    : AntennaDeployerComponentBase(compName) {
    Os::FileSystem::createDirectory(ANTENNA_DIR_PATH, false);  // FS may not be ready
    // ... file open/write ...
}

// After — constructor is clean, file ops deferred to init()
AntennaDeployer::AntennaDeployer(const char* compName)
    : AntennaDeployerComponentBase(compName) {}

void AntennaDeployer::init(FwEnumStoreType instance) {
    AntennaDeployerComponentBase::init(instance);
    Os::FileSystem::createDirectory(ANTENNA_DIR_PATH, false);  // FS is ready here
    // ... file open/write ...
}

Related Issues/Tickets

How Has This Been Tested?

• Unit tests
• Integration tests
• Z Tests
• Manual testing (describe steps)

Verified the constructor no longer performs any file system calls. Boot-time behavior should be equivalent to ModeManager and Authenticate, which use the same init() deferral pattern.

Screenshots / Recordings (if applicable)

Checklist

• Written detailed sdd with requirements, channels, ports, commands, telemetry defined and correctly formatted and spelled
• Have written relevant integration tests and have documented them in the sdd
• Have done a code review with
• Have tested this PR on every supported board with correct board definitions

Further Notes / Considerations

Only AntennaDeployer was found to have file system calls in its constructor. ModeManager, Authenticate, and StartupManager all already defer file access to init() or handler methods.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• astral.sh
  • Triggering command: /usr/bin/curl curl -LsSf REDACTED (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

Original prompt

---

This section details on the original issue you should resolve

<issue_title>[BUG] Making files in constructor</issue_title>
<issue_description>### Short summary

Making files in constructor

Steps to reproduce

Making files in constructor makes files b4 file systems is ready

Expected behavior

dont

Actual behavior

remove it pls

Logs / crash output

No response

Target board

RP2350 (Pico 2)</issue_description>

<agent_instructions>Hey copilot! Please analyze our codebase and identify if there are any components that are creating files in their constructors. This can cause unstable behavior and we should plan to refactor that functionality if it exists. </agent_instructions>

Comments on the Issue (you are @copilot in this section)

• Fixes [BUG] Making files in constructor #289

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[ineskhou]

Yep! Exactly what I expect, following the example of the mode manager.

Shows the file writes still work as well