mirror of
https://github.com/NawfalMotii79/PLFM_RADAR.git
synced 2026-05-21 23:31:57 +00:00
59f3c82fbb
`radar_receiver_final.v:246` had `assign adc_pwdn = 1'b0;` -- the AD9484
PWDN pin was hard-tied LOW with no path for the host or MCU to assert
it. Combined with AUDIT-C13 (CSB hard-tied HIGH on the production board,
no SPI access to the AD9484), the ADC was fully un-recoverable from a
stuck state without dropping main power -- which also drops the
VBAT-backed BKPSRAM persistence (MCU-A4 OCXO warmup, MCU-A7 emergency
flag) and forces a 180 s warmup soak.
Opcode 0x32 was reserved during the AUDIT-C3 fix (commit 24ef5e7) for
exactly this purpose. Wire it through:
- `radar_system_top.v` adds `reg host_adc_pwdn` next to `host_adc_format`,
resets to 1'b0 (matches historical hard-tied state -- preserves
bringup behavior), latches `usb_cmd_value[0]` on opcode 0x32, drives
the new receiver input port.
- `radar_receiver_final.v` adds `input wire host_adc_pwdn`, replaces the
hard-coded `assign adc_pwdn = 1'b0` with `assign adc_pwdn = host_adc_pwdn`.
- No CDC: `host_adc_pwdn` is a stable single-bit level driven from the
clk_100m register straight to the I/O pad. AD9484 PWDN is asynchronous
w.r.t. the ADC clock; the chip re-acquires its DLL on PWDN deassert.
XDC pin assignments were already in place from AUDIT-C15 (50T:T5,
200T:P20, both LVCMOS25 driving the AD9484 PWDN net via the R36/R37
divider on the Main Board).
Verification:
- new tb/tb_adc_pwdn_opcode.v, 15/15 PASS:
T1 reset -> host_adc_pwdn=0, adc_pwdn pin=0 (ADC powered up)
T2 opcode 0x32 val=1 -> host_adc_pwdn=1, pin=1 (PWDN asserted)
T3 opcode 0x32 val=0 -> cleared
T4 only bit[0] consumed (upper bits ignored)
T5 unrelated opcodes (0x33, 0x01) don't disturb host_adc_pwdn
T6 cmd_valid_100m gating works
- Quick regression 33/33 PASS (was 32/32; +1 new test, 0 regressions)
- Lint: 0 errors