fix(nrf52): run app loop on dedicated FreeRTOS task to avoid stack overflow

[disq]

Problem

nRF52 (Adafruit_nRF52_Arduino) repeaters crash / go silent after admin or session activity — reproducible on dev_plus with MESH_PACKET_LOGGING + MESH_DEBUG enabled on a RAK3401 repeater. It is a stack overflow on the framework's Arduino loop_task:

• The framework runs Arduino loop() on loop_task with a 4KB stack — #define LOOP_STACK_SZ (256*4) in cores/nRF5/main.cpp. It's an unconditional #define, so -DLOOP_STACK_SZ=... from platformio.ini cannot override it (it just emits -Wmacro-redefined and is discarded).
• the_mesh.loop() → ClientACL::saveSessionKeys → Adafruit_LittleFS::open("/s_sess_keys") allocates large lfs_dir / lfs_info structs on the stack. Measured peak usage is ~4.7KB, overrunning the 4KB chunk by a few hundred bytes and scribbling on whatever heap object sits directly below the stack — observed in a crash dump as the RadioLib Module*, whose smashed hal pointer then caused a hardfault/lockup on the next radio call.

Why dev_plus and not dev — the LittleFS upgrade is the trigger

dev_plus pins the LittleFS v1.7.2 framework (weebl2000/Adafruit_nRF52_Arduino meshcore-patches / tag 1.10700.1, which is the head commit 724e00a of meshcore-dev/Adafruit_nRF52_Arduino PR #1). dev pins that same fork's master (d541301), which does not include PR #1 and still runs LittleFS v1.6.

The v1.6 → v1.7.2 upgrade enlarged the stack footprint of the file-open path (lfs_dir_find / lfs_stat) enough to push the saveSessionKeys call from under 4KB to ~4.7KB — i.e. across the loop_task stack limit. That's why the crash reproduces on dev_plus but not on dev. The small 4KB loop-task stack is the underlying constraint; the LittleFS upgrade is what crossed the line. (Reverting the upgrade is not the goal — it brings real fixes; this PR gives the file-open path enough stack to run safely.)

Fix

Run the application loop on a dedicated FreeRTOS task with an 8KB stack (measured peak ~4.7KB + ~3KB headroom) instead of the framework's 4KB loop_task. No framework edits, no platformio.ini hacks, nRF52-only.

• New header-only src/helpers/MeshWorkerTask.h provides startMeshWorker(body), which xTaskCreates a "mesh" task (2048 words / 8KB) at TASK_PRIO_LOW — matching the framework's own loop task priority — that calls the body in a vTaskDelay(1) loop.
• In each affected example, the existing loop() body is renamed to runMainLoop() (unchanged, including the leading board.loop();) and started on the worker; on nRF52 the Arduino loop() just vTaskDelay(1000)s. Other platforms call runMainLoop() directly — no behavioral change off nRF52.

The entire loop body moves (not just the_mesh.loop()) so simple_repeater's board.sleep() / hasPendingWork() gating stays single-threaded and correctly ordered — it's the same code, just on a bigger stack.

Scope

Applied to the two examples that hit the ClientACL::saveSessionKeys crash path: simple_repeater and simple_room_server. Other nRF52 examples share the same latent 4KB-stack risk but are left out of this PR.

Verification

• ✅ pio run -e RAK_3401_repeater — the exact MESH_PACKET_LOGGING + MESH_DEBUG config that reproduces the crash; clean build
• ✅ pio run -e RAK_4631_room_server — clean build
• No -Wmacro-redefined (we never touch LOOP_STACK_SZ)

On-hardware: flash a RAK3401/RAK4631 repeater and drive the previously-crashing workload (admin sync, neighbour discover, repeated LoRa status requests) for several minutes — expect no LoRa-silence / lockup. Optional gdb check: walk the 0xa5a5a5a5 canary fill from ((TCB_t*)_meshTaskHandle)->pxStack upward — expect peak ~4.7KB used of 8KB, ~3KB free.

Note for reviewers

An alternative/complementary fix is a one-line #ifndef LOOP_STACK_SZ guard in the pinned Adafruit_nRF52_Arduino framework fork so -DLOOP_STACK_SZ works from platformio.ini — that would cover all nRF52 builds at once. Since dev_plus already pins a MeshCore framework fork, that change is readily available, but it's left as a separate, independent change.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Moves the Arduino loop() body onto a dedicated FreeRTOS task with an 8KB stack on NRF52 platforms, to avoid stack overflows caused by heavy LittleFS work running on the framework's 4KB loop_task stack.

Changes:

• Adds a new MeshWorkerTask.h helper that creates a FreeRTOS task running a supplied loop body.
• Wires the helper into simple_room_server and simple_repeater examples, splitting loop() into a worker-task body and a thin idle loop().
• Guards all new logic behind NRF52_PLATFORM.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 5 comments.

File	Description
src/helpers/MeshWorkerTask.h	New header defining startMeshWorker() and a FreeRTOS task that calls the registered loop body.
examples/simple_room_server/main.cpp	Refactors loop() into runMainLoop() started on the mesh worker task for NRF52.
examples/simple_repeater/main.cpp	Same refactor as above for the repeater example.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 4 comments.

[disq]

Seems this is also affecting other nRF such as companion BLE, so I'm going to open another PR on Adafruit_nRF52_Arduino to relax the LOOP_STACK_SZ defn.

[disq]

Superseded by #41, which fixes the same nRF52 loop_task stack overflow at the framework level (enlarging LOOP_STACK_SZ via build flag) instead of per-example worker tasks — covering all nRF52 builds, BLE companion included, with no per-example boilerplate.