From 6dd5e34445384cb4ec50a17ad2959cecf8298b23 Mon Sep 17 00:00:00 2001 From: MCKero Date: Fri, 28 Aug 2026 16:56:08 +0100 Subject: [PATCH] Record the squelch interrupt attempt, and why it was backed out Scanning does work now that RSSI reports a real level -- long-press * and the frequency steps, 6 distinct frames over 7 seconds. The S-meter still does not appear, because ui/main.c:2370 draws it only when FUNCTION_IsRx(), which needs the chip to report a squelch opening rather than merely a healthy RSSI. I implemented that interrupt and backed it out. The guest kept running, but REG_0C bit 0 remained set afterwards, meaning the firmware never collected the interrupt. That leaves a hang armed: app/app.c:910 and :1417 spin on that bit with no timeout, so any path reaching them with it stuck never returns. A missing S-meter is a cosmetic gap; a latent hang is not, and shipping the second to fix the first is a bad trade. Documented with the mechanism (REG_0C pending bit, REG_02 acknowledge-then-read, sqlFound at bit 3), the reason it failed, and the check that says a retry is correct: REG_0C reading 0 afterwards, which tools/test_bk4819.py already asserts. The next person should find out why the flag was not collected rather than raise it at a different moment and hope. --- AGENTS.md | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/AGENTS.md b/AGENTS.md index 9f676c0..a39e0c3 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -459,6 +459,29 @@ Two constraints are not negotiable, both from untimed spin loops in the firmware measuring. Not hypothetical: the first test run decoded 48 registers correctly and still reported RSSI as 0 for precisely this reason. +### The squelch interrupt: attempted, backed out + +Scanning works — long-press `*` and the frequency really does step, 6 distinct frames +over 7 seconds — but the S-meter never appears, because `ui/main.c:2370` only draws it +when `FUNCTION_IsRx()`, and that needs `gCurrentFunction` to be in a receiving state. +Reaching it means the chip reporting a squelch opening, not just a healthy RSSI. + +The mechanism is clear enough: `REG_0C` bit 0 says an interrupt is pending, the +firmware writes `REG_02` to acknowledge and reads it back for the flags, and +`sqlFound` is bit 3 (the bitfield is spelled out at `app/app.c:915`). + +I implemented it — raise `sqlFound` once when the firmware enables interrupts — and +**backed it out**. The guest kept running, but `REG_0C` bit 0 was still set afterwards: +the firmware had not collected the interrupt. That is a latent hang, because +`app/app.c:910` and `:1417` spin on that bit with no timeout, so any path that reaches +them with the bit stuck never returns. Shipping a model that leaves a hang armed is +worse than shipping one without an S-meter. + +Anyone retrying should first work out *why* the flag was not collected — a gate +upstream of the interrupt loop, or ordering against the receive state machine — rather +than raising it at a different moment and hoping. The signal that it is right is +`REG_0C` reading 0 afterwards, which `tools/test_bk4819.py` already asserts. + **Where it stops.** This models the register interface, not the radio. It reproduces what the firmware *commanded* — frequency, power step, carrier keying in time — never the analogue result: keying envelopes, spurious emissions, sensitivity.