Files
PLFM_RADAR/9_Firmware
Jason 582476fa0d fix(adar1000): correct 1-based channel indexing in setters (issue #90)
The four channel-indexed ADAR1000 setters (adarSetRxPhase, adarSetTxPhase,
adarSetRxVgaGain, adarSetTxVgaGain) computed their register offset as
`(channel & 0x03) * stride`, which silently aliased CH4 (channel=4 ->
mask=0) onto CH1 and shifted CH1..CH3 by one. The API contract (1-based
CH1..CH4) is documented in ADAR1000_AGC.cpp:76 and matches the ADI
datasheet; every existing caller already passes `ch + 1`.

Fix: subtract 1 before masking -- `((channel - 1) & 0x03) * stride` --
and reject `channel < 1 || channel > 4` early with a DIAG message so a
future stale 0-based caller fails loudly instead of writing to CH4.

Adds TestTier1Adar1000ChannelRegisterRoundTrip (9 tests) which closes
the loop independently of the driver:
  - parses the ADI register map directly from ADAR1000_Manager.h,
  - verifies the datasheet stride invariants (gain=1, phase=2),
  - auto-discovers every C++ TU under MCU_LIB_DIR / MCU_CODE_DIR so a
    new caller cannot silently escape the round-trip check,
  - asserts every caller's channel argument evaluates to {1,2,3,4} for
    ch in {0,1,2,3} (catches bare 0-based or literal-0 callers at CI
    time before the runtime bounds-check would silently drop them),
  - round-trips each (caller, ch) through the helper arithmetic and
    checks the final address equals REG_CH{ch+1}_*.

Adversarially validated: reverting any one helper, all four helpers,
corrupting the parsed register map, injecting a bare-ch caller, and
auto-discovering a literal-0 caller in a fresh TU each cause the
expected (and only the expected) test to fail.

Stacked on fix/adar1000-vm-tables (PR #107).
2026-04-18 06:39:07 +05:45
..