From f7ee88299da2eb67d005a51ae0419267320b91a6 Mon Sep 17 00:00:00 2001 From: Michael Pham <61564344+Mikefly123@users.noreply.github.com> Date: Mon, 3 Aug 2026 19:00:22 -0700 Subject: [PATCH 1/2] fix(comms): ComQueue could permanently wedge in WAITING -- make comStatusIn blocking (#494) Bumps the fprime pin to pick up fix/comqueue-blocking-comstatus-main (03c645123, one FPP change in Svc/ComQueue/ComQueue.fpp): async input port comStatusIn: Fw.SuccessCondition block The com-status arming protocol is one-shot: the single SUCCESS emitted at startup (ComAggregator preamble) shares ComQueue's IPC message queue with the boot event burst on comPacketQueueIn. If that queue is momentarily full, the generated handlerBase FW_ASSERTs -- which on this deployment reports to a disabled console and continues -- and the arming message is silently lost. ComQueue then stays in WAITING forever: no telemetry, no events, no command acks, on every boot of that binary (the race is deterministic per-build). Both the UART and LoRa com stacks wedge identically. GDB-traced end to end on bench hardware and verified on two V5e units: pre-fix binary fails every boot (comQueue.m_state == WAITING, enqueue -> PriorityQueue FULL -> assert hook), fixed binary passes every boot including cold reset, with full GET_SEQ_NUM round-trips and flowing telemetry. Blocking the low-rate status sender until a queue slot frees guarantees delivery at zero memory cost. Deepening the queue instead is not viable: depth >=48 exhausts the malloc arena at boot (BufferManager's ~27KB contiguous allocation fails). Fixes #494 Co-Authored-By: Claude Fable 5 Claude-Session: https://claude.ai/code/session_01WpBURCutAx8281i59nj6fo --- lib/fprime | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/fprime b/lib/fprime index 8a62e455..03c64512 160000 --- a/lib/fprime +++ b/lib/fprime @@ -1 +1 @@ -Subproject commit 8a62e455a90b6d4f498c332d45d65a2a819988d8 +Subproject commit 03c645123ba8933e33e4c621bafd433d5c1a56de From 8b81a2c64ad9dde95b604e6191c22d0fb51987cb Mon Sep 17 00:00:00 2001 From: Michael Pham <61564344+Mikefly123@users.noreply.github.com> Date: Tue, 4 Aug 2026 23:11:58 -0700 Subject: [PATCH 2/2] =?UTF-8?q?fix(submodule):=20correct=20lib/fprime=20pi?= =?UTF-8?q?n=20to=2003c6451237d4=20=E2=80=94=20pinned=20SHA=20didn't=20exi?= =?UTF-8?q?st?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The previous gitlink (03c645123ba8933e33e4c621bafd433d5c1a56de) shares only its first 9 hex chars with the real commit and exists in no repo — it looks like an abbreviated SHA that was expanded incorrectly. The actual ComQueue blocking-comStatusIn fix is the tip of the fork branch fix/comqueue-blocking-comstatus-main: 03c6451237d4442248703947693c1985a1948e88. Co-Authored-By: Claude Fable 5 --- lib/fprime | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/fprime b/lib/fprime index 03c64512..03c64512 160000 --- a/lib/fprime +++ b/lib/fprime @@ -1 +1 @@ -Subproject commit 03c645123ba8933e33e4c621bafd433d5c1a56de +Subproject commit 03c6451237d4442248703947693c1985a1948e88